火车头采集器教程：面对互相矛盾的教程怎样比较前提而非站队
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /8cb0f48e830e.html
📄
火车头采集器教程：面对互相矛盾的教程怎样比较前提而非站队
把两份互相矛盾的火车头采集器教程摊开，先别判断谁对谁错，而是分别找出它们各自成立的前提：采集器版本、目标网站结构、是否登录、发布方式、规则复杂度。前提不同，结论相反是正常的。你要做的是把前提转成可核对的条目，再用自己手里的一个页面验证。
先锁定你手里的对象，而不是先选教程
拿一个你真正要采集的列表页或详情页作为唯一对象。打开两份矛盾教程，各问三个问题：它假定采集器处于哪个大版本；它假定目标页面是静态HTML还是需要浏览器渲染；它假定发布到本地文件、数据库还是内容管理系统。把答案写成三行对照，矛盾往往立刻缩小。
如果一份教程说“直接写正则就能取到标题”，另一份说“必须用XPath等待渲染”，先别争论工具强弱。前者成立的条件是标题在初始HTML里；后者成立的条件是标题由脚本注入。用浏览器查看页面源代码，搜索标题文字，能搜到就支持前者，搜不到就支持后者。这一步的动作结果是：你排除了不适用的那份，下一步只需在一个分支上深入。
把分歧拆成可核对的项目清单
互相矛盾的教程常常混着四类内容：软件操作步骤、网站结构判断、发布接口配置、异常处理经验。把它们分开记录，不要合并成“谁更权威”。可以按下面方式各建一行：
- 操作步骤：教程写的按钮名称、菜单路径。核对方式是在自己软件里找对应功能，找不到就标记为版本差异，不标记为错误。
- 结构判断：教程说列表页链接在哪个标签、详情页字段在哪个节点。核对方式是用开发者工具选中元素，看实际路径。
- 发布配置：教程说发布到某类接口需要哪些字段。核对方式是先用一条测试数据手动提交，观察返回信息。
- 异常处理：教程说某类页面要加延时或换编码。核对方式是只改一个变量，看结果变化。
每行都写“前提”和“可观察结果”。例如假设教程A说编码选UTF-8，教程B说选GBK。你的核对项目不是投票，而是打开目标页面的字符集声明，再用一条含中文的测试数据采集，看乱码出现在哪一步。乱码在采集端还是在发布端，决定你下一步改哪里。
用一条最小规则做对照实验
不要一次把整站规则建完。选一个列表页，只取标题和链接两个字段，分别按两份教程各建一条规则。两条规则都跑同一页，记录四项：取到几条、标题是否完整、链接是否可访问、是否有重复。这个短例只用于说明比较方法，不冒充真实项目结果。
假设教程A取到20条但标题带前缀，教程B取到18条但标题干净。此时不要直接选B。先看差的2条是什么：如果是置顶推荐位，说明B的规则漏了某个容器；如果B的标题干净是因为过滤了特定标签，而你的目标页没有那个标签，B的优势就不成立。动作结果是：你知道了每条规则的适用边界，下一步只保留能覆盖你实际页面结构的那条，并补上另一条里有效的过滤条件。
把矛盾转成项目里的待验证项
比较前提之后，仍会有无法当场判断的项。把它们写成待验证项，而不是站队。待验证项要包含：验证对象、验证动作、判断依据、影响范围。例如“详情页正文是否要等渲染”可以写成：对象是某个详情页；动作是关闭脚本后重新加载并查看正文；依据是关闭后正文是否还在；影响范围是采集速度与规则复杂度。
只有当你确认某个前提在你的对象上成立，才把它写进正式规则。若两份教程分别对应不同发布方式，比如一份讲直接入库、一份讲通过接口发布，这不是矛盾，而是两条路径。选择依据是你手头有没有可用的接口文档和测试权限，而不是教程作者的熟练程度。
什么时候需要重新比较，而不是继续修规则
出现下面信号时，回到前提比较，而不是在现有规则上反复打补丁：同一规则昨天能取今天取不到；页面源代码里字段位置整体换了容器；采集数量突然归零。数量归零可能来自页面改版、访问被限制、规则条件写死、发布端过滤，不能单独证明是教程错或软件坏。先各取一条样本分别检查采集端和发布端，再决定改哪边。
如果两份教程都没有说明它假定的软件版本和页面类型，就把它们都降级为参考，不作为操作依据。你需要的不是一份永远正确的教程，而是一组能随对象变化而重新核对的前提。把当前对象、已确认前提、待验证项和下一步动作记在同一页，下一次遇到矛盾教程时，先看这页记录，再决定是否修改规则。
