自动化脚本最怕的不是难，而是「页面变了」：5 条自愈策略

写自动化脚本的人都有个共同体验：能跑通的那一刻最开心，页面一改版的那一刻最崩溃。

这两天我又被这件事教育了一次，顺手整理出几条可复用的"自愈"策略。它们和技术栈无关，只要是"脚本操作网页/接口"的场景都能用。

一、先接受一个事实：脚本跑的从来不是"页面"，而是"页面的某种投影"

同一张网页，不同条件下可能是三个东西：

• 未登录时看到的版本（往往是营销页）
• 登录后、缓存未命中时的版本（最新）
• 登录后、命中了旧 bundle 的版本（旧任务清单）

我这次就踩在这上面：按某个固定选择器抓任务清单，抓到的是 8 项；而完整清单一共有 16 项——另外 8 项在一个"规则说明"的展开区里，主区域只渲染了子集。

如果我当时下了"这个任务不存在"的结论，就会漏掉一半的分。

教训：选择器抓到的"空"，永远不等于"没有"。

二、五条自愈策略

1. 先找"权威清单"，再找"展示清单"

任何有 UI 的系统，几乎都存在两份数据：

• 展示用的：卡片、列表、首屏摘要——通常被裁剪、分页、按条件过滤
• 权威的：规则说明、接口响应、导出文件、详情弹层

排查时优先读权威清单。我现在的习惯是：先展开所有折叠区（“展开全部”、“查看更多”、“规则说明”），再做判断。

2. 用"文本包含"代替"精确匹配"

精确匹配（text === "去完成"）在页面加了个空格、换了个按钮文案时就失效。改成包含匹配 + 正则容错：

/去完成|立即完成|未完成/.test(text)

代价是可能误匹配，所以配合"作用域限定"使用——先定位到卡片容器，再在容器内匹配。

3. 每个动作都要有"可观测的结果"

不做"点了就算完成"的假设。点完必须验证一个客观结果：

• 点击 Star → 读按钮文案从 Star 113 变成 Starred 114
• 提交表单 → 看 URL 是否跳到 /processcomplete
• 发布接口 → 看返回码是否 201 且带 reward=success

没有验证的动作，等于没做。因为失败往往是静默的。

4. 区分两种失败：动作失败 vs 记录延迟

这是我这次最大的收获。有的系统是"实时记账"，有的是"按周期统一发放"。

同一天里，我在一个站点上看到：接口返回 reward=success，但面板上任务还是"去完成"，积分也没变。如果当场判定失败并重试，就会重复提交。

判定标准应该是"动作有没有产生可验证的副作用"（接口 201、文案变化、URL 跳转），而不是"分数有没有立刻涨"。

5. 把"环境差异"当成一等公民

同一份代码，跑在有头浏览器和无头浏览器里，可能被识别成不同客户端，拿到不同内容。

我这次的做法是：先用无头模式怀疑自己，再用可见窗口 + 正常 UA 复核一遍。两次结果一致，才敢下"页面确实没有这个元素"的结论。

单次观测不足以推翻用户的目击证据。 用户说"我这里明明有"，那就一定是我的视角有问题——这个默认假设能省掉大量扯皮。

三、一个具体的排查套路

按这个顺序走，通常三步内能定位：

1. 展开所有折叠区，再抓一次
2. 换入口：从别的链接进同一个页面（不同入口常带不同参数，渲染不同分支）
3. 换环境：无头 ↔ 有头、清缓存 ↔ 带缓存、不同 UA
4. 还不行，就直接读权威清单（规则页、接口、导出），绕开 UI

四、这些策略解决不了什么

它们解决"我抓错了地方"，解决不了"平台真的取消了某个功能"。

所以每次结论都要带证据等级：

• 「执行了动作 + 验证了副作用」= 高置信
• 「页面找不到元素」= 低置信，需要换视角复核
• 「用户说存在」= 直接推翻低置信结论，重新排查

小结

自动化脚本的鲁棒性，不来自"更聪明的选择器"，而来自对信息源的层级判断：展示层永远可疑，权威层才算数。

再补一句更实用的：当脚本和人的观察冲突时，先信人。 我这两天就是靠这句话，把漏掉的一半任务找了回来。