网站内容采集：某个步骤无法执行时该保留、改写还是退出
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6f0f8887a783.html
📄
网站内容采集：某个步骤无法执行时该保留、改写还是退出
当采集流程里某个步骤无法执行——比如目标页面需要登录、接口返回结构变了、分页规则失效——不要立刻整站放弃，也不要硬把残缺数据塞进发布流程。先判断这个步骤属于哪一层：是入口获取、字段解析，还是清洗与去重。不同层级的失败，对应保留、改写或退出的不同取舍。
先分清失败发生在哪一层
采集通常可以拆成三段：取得页面或数据、从里面抽出所需字段、把字段整理成可用内容。失败位置决定了替代路径的可行性。
- 入口层失败：页面打不开、需要验证、列表页结构改了。这一层失败往往影响整个批次，替代路径有限。
- 解析层失败：页面拿到了，但某个字段抽不出来，或抽出来的值格式不对。这一层最适合局部改写。
- 清洗层失败：字段有了，但重复、缺失或互相矛盾。这一层通常可以保留原始数据、延后处理。
判断方法很直接：把失败样本单独跑一遍，看它是稳定复现还是偶发。如果同一规则在十个样本里只失败一个，问题多半在解析层；如果整批都失败，问题在入口层。这个区分会直接决定下一步是改写规则还是换来源。
保留的适用前提：数据仍可追溯
保留不等于放着不管，而是把失败样本连同原始响应一起存下来，标记失败原因，先让流程继续跑其余部分。它成立的前提有三个：失败不影响下游发布、原始数据可回溯、失败量在可人工处理的范围内。
一个假设例子：某站采集商品参数，一百个页面里有三个的价格字段为空。如果价格不是发布必需字段，可以把这三条标记为待补，先发布其余九十七条，再人工核对。这里的关键动作是给失败样本打上可检索的标记，否则几天后你无法区分“当时没采到”和“当时采到了但被覆盖”。
如果失败字段恰好是发布必需项，保留就会把问题推到下游，这时应转向改写或退出。
改写的边界：换的是路径，不是换同义词
改写针对的是解析层失败。常见做法包括：换一个稳定的定位方式、从页面里另一处等价信息取值、或改用页面提供的结构化数据。它的适用前提是目标信息在页面上仍然存在，只是你原来的取法失效了。
需要警惕一种伪改写：字段抽不出来，就把相邻字段的值拿来充数，或者把同义表述机械替换后当作新内容。这不会解决采集问题，只会把错误藏进发布结果里。判断标准是：改写后抽出的值，能否和原始页面逐字对应。不能对应的，就不是改写，是编造。
改写完成后，用同一批失败样本重跑，并保留一小批此前成功的样本作为对照。如果新规则让原本成功的样本开始失败，说明改写引入了新的脆弱点，应回退而不是继续叠加规则。
退出的条件：当替代路径的成本高于收益
退出不是失败，而是一种取舍。以下情况适合退出该来源或该字段：
- 入口层持续失败，且没有合规、稳定的替代入口。
- 目标信息在页面上已不存在，只能靠推测补全。
- 为维持采集所需的维护频率，已经超过这些数据带来的实际用途。
退出时可以保留历史数据，但要明确标注截止时间，避免旧值被当作现值继续使用。如果这个来源只是众多来源之一，退出单个来源通常不影响整体；如果它是唯一来源，退出意味着整个内容方向需要重新评估。
把判断固化成可重复的动作
与其每次遇到失败临时决定，不如在流程里加一步：失败样本先进入待判队列，按入口、解析、清洗三层归类，再按上面的前提决定保留、改写或退出。这个动作的结果会影响下一步——保留的样本进入人工核对清单，改写的样本进入规则回归测试，退出的来源进入停用记录。三类记录分开存放，下次同类失败出现时，你就有依据直接复用上次的结论，而不是从头再猜一遍。
