小说CMS自动建站：14种采集规则与断点续采实战解析

简介2024小说CMS自动建站系统是一套专为小说站点设计的完整建站资源面向站长、内容运营者以及希望快速搭建小说平台、且不依赖深度编程技能的个人开发者。压缩包共16个文件包含8个HTML页面模板涵盖首页、排行、分类、搜索、详情等常见栏目、3个JS交互脚本、1个CSS样式文件及4张PNG图片资源整体仅7.78MB结构简洁、部署轻量。系统内置14种采集规则覆盖主流小说网站的数据抓取、按作者/分类筛选、连载定时更新等常见场景可显著降低手动采集与内容维护成本同时兼顾SEO优化与移动端适配默认提供WAP风格界面便于提升搜索引擎收录与手机端阅读体验。资源已有576人学习下载适合需要在短时间内上线小说网站并实现内容自动更新的用户下载后可直接参考现成模板部署站点通过修改配置快速应用采集规则并按需调整页面样式与栏目结构。1. 2024 小说 CMS 自动建站真正值得研究的是那 14 种采集规则拿到 2024 小说 CMS 自动建站系统第一反应往往是打开模板库把栏目和首页生成了就以为建站完成。但这类系统的真正交付物不是界面而是自带的那 14 种采集规则列表页规则负责找书详情页规则负责拿书名和作者分页规则负责把 3000 章逐章抓下来。本文把这套系统的采集部分当作独立二次开发对象先讲内容模型和规则字段再讲命令调度、去重和断点续采最后扩展第 15 条 sitemap 规则。适合准备长期维护小说站的站长也适合想借鉴采集架构的 PHP 工程师。2. 自动建站先落内容模型再谈 14 种采集规则自动建站的“自动”通常体现在安装向导生成栏目、模板和伪静态规则但小说站真正要自动的是内容。小说内容分作品、卷、章节三层采集规则要把这三层分别落到独立表里否则即使 14 种规则都能抓取后期也撑不住几十万章节的检索和续采。我一般会先建规则表、书表、章节表三张核心表再让采集器按表驱动而不是按源站硬编码。2.1 建站时先建三张表书、章节、规则建表 SQL 不用追求极端范式采集数据本身就带冗余重点是唯一键和状态位要提前设计。常见的做法是每张表都保留 source_site 字段这样同一本小说可以同时对比抓取两个源站的数据规则切换时不需要删旧数据。CREATE TABLE collect_rule ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, source_site VARCHAR(255) NOT NULL COMMENT 源站标识, rule_type TINYINT NOT NULL COMMENT 1列表页 2详情页 3分页章 4接口, resource ENUM(book,chapter) NOT NULL DEFAULT book, match_rule VARCHAR(500) NOT NULL COMMENT 正则或XPath表达式, custom_fields TEXT NULL COMMENT JSON格式扩展字段, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_source_type (source_site, rule_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE collect_article ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, source_site VARCHAR(255) NOT NULL, source_url VARCHAR(500) NOT NULL, title VARCHAR(255) NOT NULL, author VARCHAR(100) DEFAULT , status TINYINT DEFAULT 0 COMMENT 0待采集 1采集中 2完成 -1失败, UNIQUE KEY uk_source_url (source_site, source_url) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE collect_chapter ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, article_id INT UNSIGNED NOT NULL, chapter_title VARCHAR(255) NOT NULL, chapter_url VARCHAR(500) NOT NULL, sort_order INT NOT NULL DEFAULT 0, content LONGTEXT, status TINYINT DEFAULT 0, retry_count TINYINT DEFAULT 0, UNIQUE KEY uk_article_sort (article_id, sort_order) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里三个状态位分别控制不同层级collect_rule.status 控制某条规则是否启用collect_article.status 控制书籍是否采集完collect_chapter.status 控制章节是否成功落地。retry_count 用 TINYINT 把失败重试次数限制在 255 次避免某个坏章节无限重试。source_site 和 source_url 组成的唯一键是后续去重和断点续采的基础不建议直接用 source_url 当主键它比自增 ID 长太多会让辅助索引膨胀。2.2 14 种采集规则的构成按页面结构而不是站点数量分类很多人以为 14 种规则就是 14 个网站实际工作中是按页面结构分成四类列表型、详情型、分页型、特殊型。列表型规则负责找书详情型规则负责拿书名、作者、简介分页型规则负责生成章节目录特殊型规则处理接口返回 JSON、防采集跳转、数字区间和离线压缩包。同一类规则换一个源站通常只需要改匹配表达式和 URL 模板不需要动采集器本身。类别规则编号匹配对象典型样例返回结果列表型R01静态列表页/list/1.html书籍 URL 列表列表型R02伪静态列表/book/all/p1/同上带页码列表型R03JS 渲染列表接口返回 JSON由特殊型兜底详情型R04书籍详情页/book/123.html书名、作者、简介详情型R05简介分页/book/123/info/2简介后续段落详情型R06封面地址图片 URL 字段封面下载地址详情型R07作者主页/author/45.html作者简介分页型R08数字区间分页/book/123/1.html章节 URL 集合分页型R09拼音/汉字分页/book/123/diyi.html按汉字排序的章节分页型R10异步章节列表POST 接口章节列表 JSON分页型R11上一章/下一章翻页详情页底部链接单章 URL特殊型R12JSON 接口/api/book返回 JSON结构化字段特殊型R13XML/RSS 列表/rss.xml原文条目特殊型R14sitemap 索引/sitemap.xml书籍 URL 集合这套编号在不同版本 CMS 后台里会有差异真正的唯一标识是 source_site 加 rule_type 的组合键。R03 这类 JS 渲染列表经常抓不到数据判断方式是看 curl 拿到的 HTML 里是否包含书籍链接如果没有就把列表规则改成 R12 或 R10直接请求源码里的 XHR 接口。2.3 规则字段不能只存正则补上编码和 URL 模板采集规则常见的配置误区是只放一个正则。正则只是“怎么从响应里挑内容”URL 拼接规则处理“下一页长什么样”字符编码决定乱码还有 cookie 和 referer 字段决定源站是否给完整内容。下面是一个 PHP 数组表示一条完整的列表页规则$rule [ rule_id 1, source_site m.example.com, rule_type 1, // 1 列表页 url_template https://m.example.com/{page}.html, page_start 1, page_end 5, encoding utf-8, link_pattern #a href(/book/\d\.html)[^]*([^])/a#, next_page_pattern #下一页.*?href([^])#, headers [ user-agent Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X), referer https://m.example.com/, ], ];url_template 参数化生成第一页到第五页适合明确知道页码范围的情形next_page_pattern 用于动态发现下一页适合页面数量不固定的列表。两种方式同时存在时以 next_page_pattern 为准因为它直接反映源站最后一页的真实链接。encoding 不是 meta 标签里的东西而是响应头 charset写错会出现“标题能抓、正文乱码”的经典故障。headers 数组会转换成 curl 的 CURLOPT_HTTPHEADER移动端 UA 在多数小说站里能拿到完整版正文。3. 14 种采集规则落地配置、测试、参数边界规则写进 CMS 后台之后不能直接开跑。我一般推荐三步先用命令行跑单条规则再跑单本书章节最后批量跑列表。直接用后台计划任务第一步就失败的话所有错误都会混在日志里最难定位。下面以 PHP CLI 的采集器入口为例。3.1 从命令行测试小说 CMS 采集规则的最小命令小说 CMS 自带的采集器通常会封装成 artisan 命令手动测试时建议先看 dry-run 输出再决定是否写库。# --dry-run 只打印解析结果不写库 php artisan collect:rule --rule-id1 --dry-run # 指定书籍入口 URL详情页入库 php artisan collect:rule --rule-id2 --bookhttps://m.example.com/book/123.html # 指定书库 ID增量抓取章节 php artisan collect:book --book-id123 --modeincremental第一条命令只打印当前列表页解析到的 URL 和标题适合确认正则有没有配对第二条命令抓详情页并生成章节占位记录第三条命令才是实际入库流程。dry-run 只在 CLI 下生效网页端不提供防止误操作。注意 --book 参数可以直接传 URL这样未建立书库时也可以先抓CMS 采集器内部会自动 INSERT 一条 collect_article 记录。3.2 章节分页的三种 URL 模板写法14 条规则里最容易卡住的是异步章节列表。有的源站直接输/1.html到/999.html有的用/pinyin/目录加章节序号还有的用?id1p2。三种写法对应三种模板配置。// 数字区间页数已知直接循环 $url https://m.example.com/list/{$page}.html; // 拼音定位章节标题首字母需要先由采集脚本拼出路径 // slug 来自详情页提取的 pinyin 字段 $url https://m.example.com/{$slug}/{$chapterSort}.html; // 异步接口POST 返回 JSONchapters 字段是数组 // 请求模板不是 URL 而是 payload $payload [book_id 123, page $page];前两种是静态模板最后一种要把请求方式从 GET 改成 POSTcurl 参数从 URL 换成 CURLOPT_POSTFIELDS。CMS 自带规则通常在后台有一行“请求方式”参数写 text/html 之外的接口时记得改成 application/json。我在实际开发里会额外加一个 before_request 钩子生成签名否则很多新规则会在“列表能开详情全失败”的状态卡住因为详情页接口往往要求携带时间戳或 token。3.3 cms error: 332 与一组排查顺序采集规则常见错误码像 cms error: 332 并不全是 HTTP 状态码它经常是 CMS 采集封装层对响应内容校验失败后给出的错误代号。332 在多数二次开发实现里表示“内容为空但 HTTP 200”意味着源站返回了封锁页、验证页或空列表页。不要直接改正则先按顺序检查。错误表现可能原因调整项cms error: 332HTTP 200 但内容为空检查 UA 和 Cookie打印响应前 500 字节正文乱码charset 与源站不一致改规则 encoding 或 mb_convert_encoding列表只有 5 条分页被防采集截断增加延时改用 next_page_pattern章节只有标题正文选择器失效重新提取正文段 HTML 特征超时源站访问过慢调大 curl 超时并设置重试# 打印规则抓到的原始响应排查 cms error: 332 php artisan collect:rule --rule-id3 --raw-output | head -c 500这是最常用调试命令打印规则抓到的原始响应确认 332 是不是验证页。建议在调试时关掉 Gzip并手动复制响应里的一段文字到搜索框验证关键词是否真实存在。4. 小说 CMS 采集任务的调度、去重、断点续采14 种规则能跑通单本书以后批量才是挑战。小说站是明显“一次全量之后只追更”的内容形态推荐调度策略是凌晨低峰期跑全量列表白天每 30 分钟跑增量追更。增量追更不要扫全站列表而是对已有书籍的详情页重新请求用最后更新时间判断是否有新章节。4.1 小说 CMS 采集任务调度crontab 拆三个计划任务任务拆得越细越容易定位是“新书没入库”还是“老书没追更”。我一般拆成三个 crontab 条目# 每30分钟追更已有书籍章节 */30 * * * * /usr/bin/php /var/www/html/artisan collect:update --modeincremental /var/log/novel_cms.log 21 # 凌晨3点全量重扫列表页发现新书 0 3 * * * /usr/bin/php /var/www/html/artisan collect:rule --rule-id1 --full /var/log/novel_cms.log 21 # 凌晨4点统一重试失败章节最多3次 0 4 * * * /usr/bin/php /var/www/html/artisan collect:retry --times3 /var/log/novel_cms.log 21第一条是追更只处理 collect_article.status2 且 source_url 已存在的书第二条是全量重扫列表页发现新书第三条统一重试失败章节--times3 表示每章最多补抓 3 次超过就标记失败避免日志膨胀。记日志时注意使用追加不要使用覆盖否则第二天查看时只剩最后一次执行的日志。4.2 章节去重用“书 ID 章节序号”不要用标题很多采集器用章节标题去重遇到同一本书不同卷的章节同名就误判。正确做法是 article_id sort_order章节序号在首次生成占位记录时就固定下来。如果源站后续把第 10 章拆成上下两章sort_order 会错位需要额外记录 chapter_url 的哈希值来识别插入。下面是采集器插入章节前的一段判断逻辑$stmt $db-prepare( SELECT id FROM collect_chapter WHERE article_id ? AND sort_order ? ); $stmt-execute([$articleId, $sortOrder]); if ($stmt-fetch()) { // 更新内容不产生新记录 $update $db-prepare( UPDATE collect_chapter SET content ?, status 2, retry_count 0 WHERE article_id ? AND sort_order ? ); $update-execute([$content, $articleId, $sortOrder]); } else { // 新章节插入 $insert $db-prepare( INSERT INTO collect_chapter (article_id, chapter_title, chapter_url, sort_order, content, status) VALUES (?, ?, ?, ?, ?, 2) ); $insert-execute([$articleId, $title, $url, $sortOrder, $content]); }更新分支和插入分支分成两个 SQL避免 UPDATE 影响行数为 0 时误判成失败。更稳妥的做法是先 query 后决定或者把唯一键建在 (article_id, sort_order) 上插入时用 INSERT ... ON DUPLICATE KEY UPDATE。注意这里不要用 md5(url) 作为唯一键虽然能应对章节插入但会让后续“按卷连更”的排序逻辑变得复杂。4.3 断点续采采集日志表里加一个 token 位断点续采不是说采集器崩溃后从头再跑而是记录“最后成功抓取的 URL”和“最后一个成功写入的章节排序号”。我用一张 collect_run_log 表每次任务开始写 start_at、end_at、last_url、last_sort、total_success、total_fail。字段类型含义使用场景run_idint任务 ID定位一次调度rule_idint使用的规则编号定位规则版本last_urlvarchar上次成功 URL断点续采last_sortint上一章 sort_order章节续抓total_successint成功数统计效率statustinyint0运行中 1完成 -1中断判别是否续采# 从 run_id128 断点继续执行 php artisan collect:resume --rule-id3 --run-id128执行时先查询 run_id 对应记录的 last_url如果任务中断就从上一条的下一章重新开始。last_sort 存的是上一章的 sort_order重新请求时直接从下一章开始不重新抓取已经成功的内容。配合 4.1 的 retry 任务一个晚上就可以把 5000 章的中断点补完。5. 扩展第 15 条采集规则用 sitemap 索引补充源站入口14 种规则不够用的时候第 15 条规则通常会从 sitemap 开始写。自动建站系统本身会生成动态 sitemap 给搜索引擎爬源站往往也有 sitemap.xml它提供的是比列表页更干净的 URL 集合通常包含 lastmod 和 priority 字段适合用来做“只抓有更新的书”的增量任务。$xml simplexml_load_string($response); $urls []; foreach ($xml-url as $item) { $urls[] [ source_url (string)$item-loc, priority (string)$item-priority, lastmod (string)$item-lastmod, ]; } // 按优先级排序把 lastmod 最近的排前面 usort($urls, fn($a, $b) strcmp($b[priority], $a[priority]));解析完成后把 source_url 批量写入 collect_article 的待采集队列然后走原有详情页规则抓取书名和章节。和帝国 CMS 生成 sitemap 后交给搜索引擎是两条完全相反的链路那边是输出这边是输入。注意有些 sitemap 是 gzip 压缩需要在请求时带上Accept-Encoding: gzipPHP 用gzdecode()解压后再交给 simplexml否则 cms error: 332 会再次出现。入库前把 lastmod 转成时间戳与 collect_article.updated_at 做比对能直接跳过已抓过的书这一步能让追更任务少发出至少一半请求。本文还有配套的精品资源点击获取