网页自动化昨天还能运行，今天却找不到按钮，原因不一定是页面改版。会话失效、账号切换或数据尚未加载，都可能让同一定位规则失效。排查应先确认脚本实际看到了什么，再决定修改等待条件还是元素定位。
保留失败时的页面截图、当前页面标识与最近一步动作，通常比立即重跑更有用。预期应进入订单列表，实际却停留在登录页，修改订单按钮的定位没有意义。若页面出现验证提示，应按平台正常流程处理，不应通过反复点击或绕过验证继续任务。执行环境恢复之前，后续动作都建立在错误前提上。
登录有效也要核对账户和权限。同一个后台，不同角色看到的按钮可能不同；筛选条件和工作空间变化，也会使目标记录暂时消失。可以先用业务标识确认当前账户、店铺和记录范围，再检查目标元素。脚本若只判断页面中是否存在某段文字，很容易在相似页面上误认为已到达正确位置。
确认业务状态后，再观察页面结构。原来可见的按钮是否被移入菜单，表格是否增加了中间层，按钮名称是否调整，这些变化会影响定位方式。定位应尽量依赖可解释且稳定的语义或业务标识，而不是单纯依靠页面坐标。坐标仍可在特定工具中使用，但窗口尺寸和布局变化时，需要更明确的前置检查。
加载速度变化也会造成偶发失败。等待固定几秒，在快慢不同的网络下都不理想。更合适的等待条件是目标记录出现、加载提示消失或操作按钮具备可用状态。Playwright官方动作检查文档也把可见、稳定和可操作状态作为重要条件。具体工具支持什么检查，需要按所用工具实现，不能假设所有自动化框架行为一致。
排查定位规则时，可以保留目标元素附近的上下文，而不是只保存一个选择器字符串。相同文字可能同时出现在菜单、弹窗和表格行中，新的页面布局会放大这种歧义。通过业务区域与记录标识限定范围，再验证实际点击对象，能够减少脚本不再报错却操作错行的隐性问题。修复后的验收因此必须包含结果核对。
修改之后，应从失败前最近的安全节点恢复。若前一步已经保存或提交，重新执行整个流程可能造成重复记录。先查询目标系统，确认此前动作是否生效，再决定从哪里继续。把“找不到下一按钮”简单处理为“从头开始”，会把页面问题变成数据问题，尤其不适合订单和消息发送等任务。
维护记录应写清此次变化影响了哪个条件。比如登录会话失效、筛选范围不符、元素名称变化或加载时间延长，分别对应不同修复方式。若每次都只记“脚本已修好”，下一次维护仍要重新猜测。保留小范围复现样本和修改前后状态，能够减少定位时间，也便于判断是否需要调整整个流程。
恢复正常后，可以增加一个轻量的运行前检查：确认账户、目标页面和预期记录，再进入写入动作。检查失败时输出具体状态并停止相关操作。这样，下次环境变化会更早暴露，维护人员也能依据清晰的页面证据处理，而不是等到后续步骤连续报错才回头排查。