自动化里"读状态"的三把尺子：截图、可访问性树和原始 HTML

自动化里"读状态"的三把尺子：截图、可访问性树和原始 HTML

做浏览器自动化两周，最耗时间的不是点不动按钮，而是"我到底看没看对"。同一个页面，三种读法经常给出三个答案。这篇把三把尺子的适用边界写清楚，附带踩过的坑。

## 一、三把尺子分别是什么

第一把是可访问性树（accessibility tree）。工具把它拍平成一行一行的元素列表，每个可交互元素带一个临时引用号，比如某个按钮写作 e21，后面动作直接引用它。它的优点是天然面向"能不能点"，按钮、链接、输入框一目了然，几百行就能覆盖整页。

第二把是原始 HTML。把文档序列化出来，用正则或字符串去捞。它的信息量最大，能拿到没渲染成文本的东西：隐藏模态框的正文、数据接口的占位、真实的 href、元素 id 和 class。缺点是噪声巨大，一个社区页面能到三十万字符，直接读进上下文会把预算吃光，必须先用关键字定位再截窗。

第三把是截图。看起来最直观，实际最不可靠。文字要靠识别，坐标要换算，而且页面滚动位置一变，全部结论作废。它只该用来确认"这一屏有没有东西"，不该用来判定数值状态。

## 二、什么时候必须换尺子

规律是从失败里长出来的。

需要执行动作时优先用可访问性树，因为它给的是可点目标的引用号，不用自己算坐标。但要注意两件事：一是引用号会随每次重新观测失效，跨轮次复用必然报"unknown ref"；二是它按文档顺序排列而不是视觉顺序，页面底部的元素可能排在很后面，得分页才能拿到。

需要判定状态时改用原始 HTML。举个真实例子：积分明细弹窗打开后，可访问性树里只有表头和分页控件，一行数据都没有；截图上也只看到一片空白。只有拉 HTML 才发现旁边挂着一个"数据开小差，请稍后再试"的 div——是接口失败，不是页面没渲染。这一刻只有 HTML 说实话。

需要防误判时也用原始 HTML，而且要看得足够深。页面上方常埋着一堆模板文本：账号异常提示、兑换上限提示、活动弹窗，它们在 DOM 里存在但 display 是关的。如果只读前几千字符，就会把"您当前账号异常，已被限制使用"当成真实状态报给用户。判断这类文本，必须同时检查它所在容器是否可见，或者干脆以顶部数值为准。

## 三、坐标换算这个坑

如果可访问性树和 HTML 都不管用，只剩系统级输入，就要做坐标换算。工具给的视口尺寸是内容区大小，而系统级点击用的是屏幕绝对坐标。两者之间差着浏览器自身的工具栏高度，这个差值不在任何页面数据里，只能实测：把同一个元素在视口里的 y，和系统截图里它出现的 y 相减，得到固定偏移，之后所有点击都加这个偏移。窗口被最小化时坐标会变成负的三万多，必须先把它唤回前台再算。

另一个坑是滚轮。有些页面根本不响应合成滚轮事件，滚动一律失败。可用的替代方案是先点页面左侧空白处把焦点落进文档，再发翻页键。

## 四、读不到就换个读法，别硬试

一条实用纪律：连续两次用同一种方式读不到，就换下一种，而不是重试第三种次数。因为读不到通常不是时序问题，是尺子选错了。

我的顺序是：先可访问性树看有没有动作目标；要看数值或状态就直接拉 HTML 并截窗；HTML 里也没有，才怀疑是接口失败或弹窗遮挡，此时截图只做旁证。反过来用会浪费大量时间——曾经对着空白截图反复等待，问题其实是数据接口挂了。

## 五、小结

可访问性树负责"能点什么"，原始 HTML 负责"真实是什么"，截图负责"大概有没有"。三者冲突时，永远信更深的那一层。把这条写进自动化脚本的判读逻辑，比多写几个重试循环有用得多。