自动化脚本里的「假失败」：为什么你的判断条件总是判错

## 三类假失败

写浏览器自动化最费时间的不是写脚本，而是判断"这一步到底成没成"。真实项目里遇到的假失败基本是三类：

1. **接口返回错误码，但服务端其实已经成功**；
2. **页面跳到了成功页，但脚本判断为失败**；
3. **动作执行完了，但业务侧没记账**——因为它要求的不是"做了这件事"，而是"从指定的入口做这件事"。

这三类都源于同一个错误：拿"我以为的成功信号"当判据，而不是拿"业务侧的最终状态"。

## 第一类：错误码是表象

登录一个 SSO 站点，表单提交后 URL 落到 `login.html?errorCode=408`，页面还显示"异常"，脚本立刻判定密码错、或者被风控拦住，转人工。

实际情况是：408 来自那个回调页自身的请求超时，而会话 Cookie 已经下发。此时只要**再走一次带 service 参数的登录入口**，SSO 会直接 302 到业务的 ticket 地址，页面渲染出来就是已登录状态。

判据该怎么写？不要看错误码，看**下游资源的可访问性**。具体到这个场景：

- 打开业务页，抓一个只有登录后才存在的字符串（用户昵称、积分、余额）；
- 拿到就说明会话有效，错误码可以忽略；
- 拿不到再重试一次；两次都拿不到才算失败。

代价是每次判定要多等一次导航，但比"误判失败 → 转人工 → 人工发现其实已经登录"便宜得多。

同理，很多接口的 HTTP 状态和业务状态是两套东西：网关 504 不代表后端没写库，异步任务提交返回 `200 + jobId` 也不代表已经完成。**判据永远取最靠近最终状态的那一层**：数据库里的记录、页面上渲染出的值、下游可观测的结果。

## 第二类：成功页被判成失败

发布文章的脚本，最后一步跳到了 `processcomplete` 这种"流程完成"页，脚本的成功判据是"URL 里出现文章详情 id"，结果判 `FAILED`——但文章其实已经发出去了，草稿箱也清空了。

这类误判的麻烦在于它是**方向相反的危害**：脚本以为失败就会重试，重试就产生重复内容（重复文章、重复回答、重复提交的表单）。

修正原则有两条：

- **成功判据优先取副作用**：发布类动作看"列表里多了一条"、"草稿箱少了一条"、"详情页能打开"，比看跳转 URL 可靠；
- **重试必须幂等**：重试前先查一次"是不是已经有了"，用唯一键（标题、内容摘要、幂等 token）去比对，而不是无脑重发。

顺便说一个常见的反向坑：有些平台的成功页就是会跳回上一个页面的，看起来像"没反应"。判断"点了没反应"之前，先确认那个按钮到底发出了请求没有——用 `fetch`/`XMLHttpRequest` 的 hook 记录一次，比盯页面变化准确得多。我遇到过的最典型情况是前端校验失败：点击后 **0 个请求、0 条报错**，因为草稿箱已经满了（上限 10 篇），前端直接把提交拦掉了。

## 第三类：动作做了，但没记账

这一类最隐蔽。流程从头到尾都是"成功"的：页面打开了、环境起来了、日志里有 `READY`，但积分、订单、任务状态纹丝不动。

原因通常是**业务侧校验的是入口凭证，不是动作本身**：

- 平台把任务入口从"我自己拼一条 URL"改成了"任务中心下发的一次性 token"；
- 用旧参数拼出来的 URL 依然能打开页面（服务端兼容旧链接），但回调里没有对应的任务上下文，于是不记账；
- 表现就是：环境真的起来了，剩余时长也在倒计时，任务卡片仍然停在"去完成"。

这种问题的排查顺序应该是：

1. 别猜 URL。**从任务卡自己的"去完成"按钮点进去**，记录它实际落到的域名与参数——这次就发现域名已经换成新的一套，参数是签名过的 token；
2. 在该页面里继续走**平台提供的下一步按钮**（比如案例卡片上的"前往…实践"），而不是手动跳最终页；
3. 动作完成后**回到任务列表复查状态**，把"卡片是否变已完成 + 明细是否多一条记录"作为判据，而不是"我看到环境起来了"。

一句话总结：**"页面能打开"不等于"任务完成"，"环境起来了"也不等于"业务认可"**。业务认的是它自己的入口链路。

## 一套通用的判据写法

把上面三类收敛成四条规则，写脚本时直接套：

| 场景 | 不要用 | 应该用 |
| --- | --- | --- |
| 登录 | 页面无错误文案 | 登录后专属字段可读 |
| 提交表单 | 出现"提交成功"文案 | 列表新增一条 / 唯一键可查到 |
| 异步任务 | 接口返回 200 | 轮询到终态（成功或失败） |
| 任务/积分 | 页面跳转 | 卡片状态 + 明细记录 |

另外两条工程习惯，能省掉大量返工：

- **每个动作都打一行结构化日志**：动作名、入口 URL、关键副作用、判据结果。事后排查"到底哪一步没记账"时，这行日志比截图有用得多。
- **失败要能区分"没做"和"做了没记"**：前者可以重试，后者重试会重复劳动甚至触发风控。日志里把这两类分开，人工介入时才不会做错决定。

## 小结

自动化脚本的可靠性，八成取决于判据选得对不对，而不是选择器写得漂不漂亮。判据向下游要、向副作用要、向业务状态要；判据选对了，重试才是安全的，脚本才敢无人值守。