采集规则编写 - 用访问路径检查采集是否走对页面
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /df500af5817b.html
📄
采集规则编写 - 用访问路径检查采集是否走对页面
检查用户访问路径，核心是模拟一个真实访客从入口到目标页面的完整点击链路，逐步记录每一步的 URL、跳转状态、页面标题和关键内容，再与采集规则里配置的入口、列表页匹配、详情页匹配做对照。如果规则抓到的页面和用户实际到达的页面不一致，说明路径判断有偏差，需要先修路径再改字段。
先明确要交付什么结果
采集规则编写最终交付的是一份能稳定跑通的规则文件：入口地址、翻页方式、列表与详情的识别条件、字段抽取表达式、去重与更新策略。要检查用户访问路径，就得先知道这份规则预期覆盖哪些页面。把预期结果写成一张对照表，至少包含四项：用户从哪进入、经过几层跳转、最终落在哪类详情页、页面上哪些内容是要采的。没有这张表，检查就变成盲目点页面。
两种检查方案及适用条件
第一种是手动走查。用浏览器无痕模式，从规则里填写的入口 URL 开始，只靠页面上的可见链接逐级点击，记录每一跳的地址和跳转类型。适合页面层级少、链接结构清晰、规则刚写完还没上量的阶段。判断结果的方式是：把走查记录和规则中的入口、列表匹配表达式逐条比对，出现规则匹配到走查没经过的地址，或走查经过但规则没匹配的地址，都算路径偏差。
第二种是抓取日志比对。让规则先小范围跑一批，导出实际请求的 URL 列表，再和手动走查得到的路径列表做交集与差集。适合页面量大、存在多种跳转入口、需要确认规则是否漏抓或多抓的场景。判断依据是差集规模：差集集中在列表页说明翻页或列表匹配有问题，差集集中在详情页说明详情链接识别或去重条件有问题。
两种方案不冲突。层级浅、结构稳定时手动走查就够；入口多、有重定向或参数拼接时，日志比对更能暴露问题。条件允许时先手动走查确定基准路径，再用日志比对验证覆盖度。
可执行的检查步骤
- 打开浏览器无痕窗口，输入规则中的入口地址，清空缓存后访问。
- 从入口开始，只点击页面上用户能看到的链接，每跳一次记录：当前 URL、HTTP 状态、页面标题、是否发生重定向。
- 到达目标详情页后，记录该页的稳定特征，例如标题所在标签、正文容器、发布时间位置。
- 回到规则文件，核对入口是否与走查起点一致，列表匹配是否能命中走查经过的中间页，详情匹配是否能命中最终页。
- 小范围运行规则，导出请求 URL 列表，与走查记录求差集，定位漏抓和多抓的具体地址。
记录时注意区分“可能原因”和“已确认原因”。某个详情页没被抓到，可能是链接被脚本动态生成、可能是被去重规则过滤、也可能是详情匹配表达式写错，只有逐一排除后才能下结论，不要看到现象就断定是某一处的问题。
对照规则定位偏差
把走查结果和规则配置放在一起看，常见偏差有三类。入口偏差：规则填的是频道首页，用户实际从栏目页进入，导致列表匹配范围过大。层级偏差：用户路径经过一次站内跳转才到列表，规则却把跳转后的地址当入口，漏掉前置页面。详情偏差：同一内容存在多个 URL 变体，规则只匹配其中一种，另一种被当成新页面重复采集。
处理方式按偏差类型区分：入口偏差改入口地址或收窄列表匹配条件；层级偏差补上中间页匹配或调整翻页起点；详情偏差增加 URL 规范化条件，把带参数的变体归并到同一标识。每次只改一处，改完重跑小批量，观察差集是否缩小，避免多处同改后无法判断哪一处生效。
验收标准与下一步
验收时看三项：走查路径上的每个页面都能被规则命中；规则请求的 URL 都出现在走查路径或可解释的等价路径中；重复运行两次，采集结果条数稳定，没有因路径抖动产生的新增或丢失。三项都满足，路径检查才算完成。
下一步是固定这份走查记录，作为规则变更后的回归基准。之后每次调整入口、翻页或匹配条件，都用同一份记录重跑一次比对，确认路径没有意外偏移。
