取什么：来源清单决定内容上限
规则再漂亮，源站选错也白搭。来源要有稳定更新、结构相对规整、且允许被抓。把只更新首页、模板天天变、整站被 CDN 拦的站点放进清单，等于给后续所有环节埋雷。
- 近 30 天更新频率
- URL 结构是否稳定
- 是否有整站防抓
Collect Rules
小旋风蜘蛛池采集规则
小旋风蜘蛛池采集规则写错，表现从来不是报错崩掉，而是「跑得通、结果不对」——采回一堆空白页、乱码或重复内容，最后全塞进索引。
我们见过太多站点的采集任务是绿灯状态，入库量也好看，但抽十条出来有五条正文是空的。原因几乎都落在同一处：规则字段没写全，或者去重键设计得太单薄。这份页面把规则的五组字段、常见报错的定位顺序、以及一套能直接照做的排错清单摊开给你，照着排查基本能自己找到问题。
TG:@mspseo ｜ Q/V:897569356 ｜ www.yinliuyuan.cn ｜ 报错日志贴过来，直接帮你看问题在哪一行
规则字段速查表：五组字段写错分别会怎样
采集出问题的时候，先别急着改正则。对着这张表找到「现象」，就能定位到是哪一组字段写错了，比从头读一遍规则快得多。
| 字段组 | 作用 | 写错后的典型现象 | 先看哪里 |
|---|---|---|---|
| list_page | 定位列表页与翻页入口 | 只采到第一页，翻页命中 0 | 翻页链接是否带参数 |
| detail_url | 从列表条目里提详情链接 | 链接重复或带跟踪参数 | 提取范围是否被截断 |
| title | 提取标题并做规范化 | 标题带站点名后缀，长度异常 | 是否漏写清洗规则 |
| content | 提取正文并去噪 | 正文含导航与广告，或整段为空 | 正文容器选择器是否唯一 |
| filter | 过滤乱码、免责声明、外链 | 过滤过头，正文被削掉一半 | 过滤词是否命中正文关键词 |
| dedup_key | 入库前去重判断 | 重复率居高不下，分页被重复采 | 去重键维度是否单一 |
用法：从「写错后的典型现象」这一列往回找，命中哪一条就直接跳到对应的排查项。六行里有四行与正则无关，所以改正则往往解决不了问题。想让我们按你的日志逐行对一遍，加 TG:@mspseo 或 Q/V:897569356 发日志即可。
小旋风蜘蛛池采集规则的三个层面
把规则拆成「取什么、怎么取、取完怎么判」三个层面，写规则时就不会漏项，查问题时也能快速缩小范围。
怎么取：定位方式决定维护成本
能用容器选择器就用容器，能圈定唯一父节点就别全页扫描。规则越短，源站改版时修复越快。我们一般要求单条提取式不超过两个条件分支，超过就说明该拆成两条规则。
- 优先唯一容器定位
- 正则只圈最小范围
- 单规则分支 ≤ 2
取完怎么判：入库闸门决定数据干净度
所有采集结果进库前都要过三道闸：字段非空、正文长度达标、去重键未命中。任何一道没过就直接丢弃并计数，不要「先入库再清理」。数据一旦脏了，后面清理的成本是拦截的十倍。
- 字段非空校验
- 正文长度阈值
- 去重键三件套
六个高频故障的定位顺序清单
下面六条按发生频率排序。遇到问题从第一条往下对，命中就先按它的顺序查，不要跳着试。
01
翻页命中为 0：只采到第一页
先确认翻页链接是不是 javascript 动态生成；再看翻页参数有没有被规则当成了详情链接。多数情况是把翻页入口写成了第一页的固定 URL，规则自然只在第一页打转。
02
正文整段为空：选择器命中了空容器
打开一条失败的详情页，查看正文外层节点的类名是否与规则一致。源站常用多个模板，规则只覆盖了一个。解决方式是把两种模板分别写规则，用来源 URL 前缀做分流。
03
正文混进导航与广告：清洗项漏了关键词
把清洗词按三类补齐：免责声明类、站内推荐类、外链锚文本类。补的时候注意顺序，先删块再删词，顺序反了会把正文里的正常词一起削掉。
04
重复率偏高：去重键维度太单一
把去重键从单字段改成三件套：站点标识 + 规范化标题 + 正文前两百字哈希。分页文章要额外加页码字段，否则同一篇内容会被拆成多条重复记录。
05
采集速度骤降：请求被限速或正则回溯
先看是不是触发了源站限速，把并发降到 2 到 4 再观察；如果速度仍然异常，检查正则里有没有连续的可选分支。把 .* 换成排除式字符集，通常能立刻提速。
06
采集结果时好时坏：源站做了 A/B 模板
同一批 URL 间隔跑两次，把两次的 DOM 结构做对比。如果正文容器不同，说明源站在灰度模板。处理方式是给两种结构各配一条提取式，并在日志里记录命中比例，方便后续维护。
三类采集翻车场景的修复记录
下面三条都是真实排查过的案例，共同点是：改的不是正则，而是规则结构。
我们的采集任务一直显示成功，但抽检发现有四成正文是空的。查到最后是列表页用了两个模板，规则只匹配了主模板。拆成两条按 URL 前缀分流的规则之后，空正文比例降到百分之二以内。
修复动作：按模板拆分提取式 + 增加空正文计数告警
沈工门户站 · 技术负责人
采集速度突然从每小时八千条掉到一千二，一开始以为是被封了。日志显示请求都是 200，问题出在一条带多层可选分支的正则上。换成排除式字符集之后速度直接回到七千多。
修复动作：正则从回溯式改为排除式 + 并发降到 3
范女士电商导购站 · 后端工程师
重复率一直在百分之三十上下，用标题去重完全压不下去。后来加了正文前两百字哈希，又补了页码字段，重复率降到百分之四。原来问题一直是分页文章被判成了新内容。
修复动作：去重键升级为三件套 + 分页页码入库
董先生内容聚合站 · 数据运营
以上数据为该站点修复前后的自身对比，规则表现与源站结构强相关，不代表其它站点的普遍结果。
小旋风蜘蛛池采集规则常见疑问
下面六个问题来自实际对接时问得最多的场景，按「字段构成、正则取舍、重复控制、报错定位、速度瓶颈、日常维护」的顺序排开。
小旋风蜘蛛池采集规则里的「规则」具体指哪些字段？
核心是五组字段：列表页的翻页入口、条目的详情链接提取式、详情页的标题与正文提取式、清洗过滤项、以及入库前的去重键。五组里任何一组写错，最终表现都是采集「跑得通但结果不对」，这也是最难查的一类问题。
正则写得越复杂，采集质量是不是越高？
恰恰相反。正则越复杂，遇到页面改版时越容易整条规则失效，而且回溯开销大会拖慢采集速度。我们的做法是能用标签定位就不写正则，必须用正则时只圈定最小范围，再配合清洗项做二次过滤，规则越短越好维护。
采集回来的内容重复度很高，是规则的问题吗？
多数时候是去重键设计的问题。只用标题做去重，同一篇文章换标题就进来了；只用正文哈希做去重，分页文章会被整篇重复。建议用「站点 + 规范化标题 + 正文前两百字哈希」三件套做联合判断，重复率会明显下降。
采集规则报错时，先看日志的哪一段？
先看三行：请求返回的状态码、规则命中的条目数、以及写入前的字段是否为空。状态码异常说明被拦或链接失效；命中为零说明提取式与当前页面结构不匹配；字段为空说明清洗规则把内容过滤掉了。按这三步走，八成报错能自定位。
采集速度和规则复杂度有关系吗？
有关系，但不是线性。真正拖慢采集的通常是三件事：过长的正则回溯、单线程串行请求、以及每篇文章都做全站去重比对。把去重改成先做标题精确匹配再做正文哈希，速度往往能提升一倍以上，规则本身反而不用改。
规则调好之后还需要定期维护吗？
需要。目标站改版、加反爬、换模板都会让规则失效，所以我们建议每周跑一次抽样校验：随机抽二十条采集结果，人工核对标题、正文、来源链接是否完整。发现失效率上升就立刻修，别等到几万条废数据进库才回头。
Rules Review
把现有采集规则发过来，先跑一遍命中率体检
把你正在用的列表页与详情页链接、以及当前规则截图发过来，我们先看翻页入口、正文提取式和去重键这三处，指出命中率流失在哪一环，再决定要不要重写。体检不收费，也不用先买任何套餐。
TG:@mspseo ｜ Q/V:897569356 ｜ www.yinliuyuan.cn ｜ 采集问题优先走 Telegram 发日志
和小旋风蜘蛛池采集规则相邻的五个主题
采集规则解决的是「内容从哪来、怎么进库」，而池子本身的版本、标签与运行方式决定了这些内容能不能被有效推出去，按你当前卡住的那一环往下读。
