那次验收网页时，我遇到一个很容易让人下错结论的场景：列表里的数据已经出现了，浏览器却还在等共享脚本，导航也偶尔因为请求延迟而超时。页面看起来像是“已经有内容”，但我真正需要判断的功能还没有进入稳定状态。
我当时差点就按下截图。因为从最直观的角度看，数据已经在页面上，继续等待似乎只是浪费时间。后来一次 375 宽度的截图把问题暴露出来：演员数据确实已经到达，但页面框架还没有完成初始化，样式绑定和交互准备都没有结束。那张图如果被当成验收证据，加载中的空白、错位或未绑定样式，很可能就会被误判成产品缺陷。
这件事让我重新意识到，异步页面里的“出现”不是一个单一状态。数据到了，不代表页面能稳定展示；页面能展示，也不代表关键控件已经可以操作。截图本身只是一个观察动作，不能替代对页面状态的判断。
数据到了，页面却还没有准备好
这次问题表面上是截图时机不对，实际上是把不同的就绪状态混成了一个信号。页面请求、共享脚本和业务数据并不是同时完成的。只要某个数据节点先返回，DOM 里就可能出现文字或卡片；但负责布局、筛选、键盘和抽屉的初始化代码，仍然可能在等待另一个请求。
如果这时立即截图，看到的画面会混合两类信息：一部分是产品的真实结果，另一部分是加载过程的临时状态。验收者很难再分辨，眼前的空白究竟是设计如此、功能失败，还是初始化尚未结束。如果不处理这个状态差异，会导致加载中的临时画面被当成产品缺陷，后续修复也会失去依据。异步页面的第一个可见结果，只能证明数据曾经到达，不能证明页面已经完成。
导航超时也需要单独看待。共享脚本加载慢，会让浏览器报告超时；这说明等待链路有问题，却不自动说明页面功能失败。相反，如果把超时直接记成产品缺陷，就会把环境或资源延迟和真实交互错误混在一起。后面的排查会因此走错方向：反复修改页面，却没有处理真正拖慢初始化的部分。
我一开始采用的捷径为什么不可靠
最容易误判的错误捷径是：只要 DOM 里出现目标数据，就立即截图或判定通过。它看起来很节省时间，也很容易写成自动化规则，例如查找列表数量大于 0，或者确认某个演员名称已经出现。
但这个规则只回答了“数据有没有被读到”，没有回答“页面能不能被使用”。这次 375 截图就是具体反例。数据存在并没有阻止页面处于半初始化状态，视觉结果因此不可信。若不处理这个区别，后果不只是多一张难看的截图，而是可能把加载阶段提交给设计和开发，让他们围绕一个尚未完成的状态修复不存在的问题。
我也没有选择简单地把等待时间再加长。因为固定等待 5 秒或 10 秒，只是把不确定性藏起来：网络快时浪费时间，网络慢时仍然提前结束，真正的初始化失败则可能被无限拖延。等待时长不是就绪证据，明确的状态信号才是。
把验收拆成 3 道门
我选择把页面验收拆成 3 道门，是因为每道门回答的问题不同，而且失败后的处理方式也不同。
第1道门是数据可读。列表、筛选项或详情里的目标数据已经从请求结果进入页面，能被脚本稳定读取。这一步只证明内容来源正常，不能替代后面两步。
第2道门是页面框架初始化。共享脚本已经执行，页面完成必要的状态绑定，骨架不再处于临时加载状态，布局相关的初始化也已经结束。这里要检查的不是某一个文字，而是页面是否已经从“正在组装”进入“可以被操作的界面”。这正是那次过早截图缺失的门槛。
第3道门是关键控件可操作。筛选、详情打开、关闭、键盘移动、失败重试等动作都要能完成，并且结果符合预期。只有到了这里，截图才有视觉验收价值，因为截图记录的是用户可见且可复现的最终状态，而不是某个请求先返回的瞬间。
我把截图放在第3道门之后，是因为视觉判断依赖前两道门的结果。否则，截图里一个没有样式的按钮，可能只是脚本尚未执行；一个暂时空白的区域，可能只是数据和布局还没有汇合。先判断状态，再判断外观，顺序不能倒过来。
超时和失败必须分开记
这次还有一个容易被忽略的判断：导航超时与功能失败不是同一件事。页面请求和共享脚本加载曾出现 60–75 秒的延迟，导致导航等待超时。这个现象值得记录，但它不能直接覆盖后续的功能结果。
我后来把记录拆成两条线。一条记录页面是否完成加载，以及在哪个阶段超时；另一条记录当页面就绪后，功能是否按预期工作。这样，即使第一次导航没有按时完成，也可以在请求结束后继续确认数据、框架和控件的真实状态。超时记录的是等待链路，功能失败记录的是可操作结果，二者不能用同一个结论代替。
这种拆分也让重跑更有意义。如果失败发生在框架门之前，就先检查共享脚本、请求和初始化信号；如果框架已经就绪但控件动作失败，再去看交互逻辑；如果操作都通过而截图异常，才进入视觉布局检查。每一种失败都有自己的下一步，而不是统统归类为“页面坏了”。
从单张截图到完整回归
补上框架就绪检查后，我重新跑了验收，而不是只替换那张 375 截图。最终 3 个尺寸都验证了布局、深链、键盘和失败重试。这个顺序很重要，因为响应式页面在不同宽度下可能走不同的初始化或交互分支，单一尺寸通过不能推出其他尺寸也稳定。
之后的分页专项又补了刷新、异常页码和输入框焦点规则。它让我看到，页面“看起来稳定”和页面“状态能够持续”也是两回事。刷新后能否还原页码，异常页码是否回到合理范围，输入框获得焦点时左右键是否仍按输入行为处理，这些都不是一张静态图能证明的。
因此，我现在会把截图看成回归链条中的一个节点，而不是验收的终点。先等到框架就绪，再让控件完成一轮真实动作，最后截取稳定状态；涉及分页、深链或刷新时，还要把状态恢复纳入检查。这样做稍微慢一点，却能减少“截图通过、用户操作失败”的假阳性。
这套规则可以怎样复用
遇到任何异步页面，我会先问 3 个问题：数据现在能不能读，框架现在有没有初始化完成，关键控件现在能不能操作。对应地，验收脚本也应当有 3 个独立检查，而不是只找一个“页面已加载”的总开关。
方法上，可以把数据节点作为内容门，把框架初始化信号作为结构门，把用户动作作为交互门。内容门失败，检查请求和数据映射；结构门失败，检查共享脚本和初始化过程；交互门失败，检查状态绑定和事件处理。只有 3 道门都通过，才进入截图和视觉判断。
这套流程还有一个边界：不要把所有等待都变成无限等待。每道门都要有清晰的超时记录和失败阶段，知道是“数据未到”“框架未好”还是“控件不可用”。如果只写一个总超时，最后仍然无法判断该修页面、修环境，还是重新发起请求。
表面上我是在解决一次截图过早的问题，其实我是在给“页面完成”重新定义。一个流程成熟的标志，不是它能在网络顺畅时跑通一次，而是遇到延迟、刷新和异常输入时，仍然能说明自己到底卡在哪一层。
下次我会怎么做
下次开始网页验收时，我会先把就绪状态写进检查顺序：先确认数据可读，再确认页面框架已经初始化，接着验证关键控件可操作，最后才截图。任何一步没有通过，都不把当前画面当成最终页面。
如果出现导航超时，我会保留超时阶段，等待或重试只针对具体门槛，不把它直接记成产品功能失败。等页面真正进入可操作状态后，再做尺寸、深链、键盘、重试、分页和刷新回归。
我更愿意把它看成一种工作习惯，而不是一个技巧。浏览器里最先出现的东西，往往只是最先完成的东西；真正值得验收的，是所有影响用户判断的部分已经汇合。先确认页面已经成为页面，再确认它长得对不对、用起来好不好。