火车头采集规则：何时继续优化何时调整方向 - 用观察和判断做决策
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /99439707f6bc.html
📄
火车头采集规则：何时继续优化何时调整方向 - 用观察和判断做决策
判断火车头采集规则该继续优化还是调整方向，核心看一个信号：当前问题是否还集中在“可调参数”层面。如果失败原因主要是分页、字段截取、编码、去重这些规则内部可修复的环节，继续优化更划算；如果目标站点已改成动态渲染、登录校验或接口加密，规则层面怎么调都难以稳定，就该调整方向，改用接口、浏览器渲染或更换数据来源。
先观察：规则失败集中在哪一层
不要一看到采集失败就改规则。先做一次小规模试跑，比如只采一页或一个列表，记录失败表现。常见现象可以归为两类：
- 规则层问题：列表页能打开，但只采到第一页；标题能取到，正文为空；数字字段带上了多余符号；同一内容重复入库；编码乱码。
- 方向层问题：页面源码里根本没有目标数据；数据由 JavaScript 渲染后才出现；请求返回登录页或验证页；接口需要签名、时间戳或令牌；站点结构频繁整体改版。
规则层问题通常有明确的修改点，方向层问题则意味着你依赖的采集路径已经失效。判断结果不同，后续动作完全不同。
判断：继续优化与调整方向的适用条件
可以用下面这组条件做对比。满足左侧越多，越应该继续优化；满足右侧越多，越应该调整方向。
- 继续优化：目标数据在 HTML 源码中可见；失败只发生在部分页面；改动选择器、翻页参数、编码设置后成功率提升；站点没有强制登录；改版频率低。
- 调整方向：目标数据不在初始源码中；全站请求都返回验证或登录；接口参数加密且经常变化；规则修好后几天内再次失效；采集量远低于人工整理成本。
这里的关键不是“规则写得不够好”，而是数据获取路径是否还成立。路径成立，优化有上限但可持续；路径不成立，优化只是拖延。
处理：两种方案的具体动作
继续优化时，按以下顺序排查，每改一项就单独试跑一次，避免同时改多处无法定位原因：
- 检查列表页翻页链接是页码参数还是动态加载，确认翻页规则是否匹配。
- 用浏览器开发者工具定位目标字段的标签、类名或属性，替换失效的选择器。
- 检查编码设置，确认页面声明编码与实际返回编码一致。
- 检查去重字段是否选对，避免用会变化的字段做唯一标识。
- 设置合理的请求间隔，减少被限制的概率。
调整方向时，可考虑：改用站点提供的接口或数据导出；使用能执行 JavaScript 的采集方式；更换数据来源；或对少量关键页面改为人工整理加半自动校验。选择依据是稳定性与成本的比较，而不是哪种方式更“高级”。
假设一个例子：某列表页前 10 页能正常采集，第 11 页起返回空白。检查后发现是分页参数上限导致，这属于规则层问题，继续优化翻页逻辑即可。若检查后发现所有页面源码中都没有目标字段，数据由脚本加载，则属于方向层问题，应调整采集方式。
复查：改完之后怎么确认决定是否正确
无论选择哪种方案，都要用同一批测试页面复查。复查项包括：字段是否完整、数量是否与预期一致、是否出现重复或乱码、连续运行两次结果是否稳定。如果继续优化后成功率明显回升且能保持，说明判断正确；如果修好后很快再次失效，或始终无法突破验证与渲染限制，就应停止在规则上投入，转向调整方向。
下一步建议：挑一个当前失败最多的采集任务，按上面的观察清单记录失败表现，先判断它属于规则层还是方向层，再决定是改选择器和翻页参数，还是更换采集路径。
