页面一改，任务就断：选择器漂移怎么排查

01先确认失败在哪一层

只有先排除前四层，才能判断是不是选择器问题。很多“选择器失效”其实是登录过期、页面没加载完或权限不足。

• 导航层：页面是否打开了正确的 URL，是否被重定向到登录页。
• 会话层：账号是否仍然登录，是否出现验证码或权限提示。
• 加载层：目标区域是否已经渲染，是否还在骨架屏或加载状态。
• 元素层：元素是否存在、可见、可点击，是否被弹窗遮挡。
• 业务层：按钮存在但操作被平台拒绝，可能是权限或状态不满足。

02四类常见漂移

第一类是结构变化：新增包裹层、调整列表顺序、把元素移到弹窗或 iframe 中。第二类是属性变化：class 名带构建哈希、id 每次渲染都不同。第三类是文案变化：按钮从“提交”改成“确认发布”，按文本定位就失效。第四类是动态渲染：页面根据实验分组或加载顺序渲染不同结构。

这些变化不一定意味着页面“坏了”。自动化需要接受页面会演进，定位策略应尽量依赖稳定的语义和结构，而不是某次截图里的偶然细节。

03更稳的定位策略

定位策略没有永远正确的答案。稳定性和可读性要平衡：过于宽泛的定位可能点错元素，过于精确的定位又容易随页面变化失效。

• 优先使用可访问性角色、标签、名称等语义定位。
• 在目标元素附近找稳定锚点，再按相对关系定位。
• 避免使用随机 class、绝对路径和过深的 nth-child。
• 等待元素可见、可用或特定文本出现，而不是固定睡眠。
• 对关键页面保留结构快照或失败截图，便于对比。

04修复后怎么验证

用最初失败的样本复测，而不是只跑一个新页面。增加状态断言：操作前确认页面处于预期状态，操作后确认目标结果出现。对关键写入，读回页面或记录状态，确认动作真的生效。

如果同一页面频繁变化，考虑把定位集中管理、增加可观测性，或把不稳定步骤交给人工。不要用不断增加 sleep 和重试来掩盖结构问题。

05什么时候停止自动化

停止自动化不是失败，而是把风险放回可控位置。一个能明确报告“这步需要人处理”的任务，比一个不断猜测、重复提交的任务更可靠。

• 页面频繁改版，没有稳定语义锚点。
• 关键操作依赖验证码、人工审批或动态权限。
• 失败后无法判断是否已经产生结果。
• 平台规则明确限制自动化操作。
• 维护成本已经高于人工处理成本。