浏览器自动化失败时，很多人的第一反应是改选择器、加等待、加重试。
这些当然重要，但在多账号任务里，脚本不稳定不一定是代码本身的问题。很多时候，真正出问题的是执行环境：Profile 不一致、登录态失效、代理变化、环境字段漂移，或者任务上下文没有被记录下来。
尤其是多账号任务，一段代码能不能稳定执行，不只取决于选择器、等待和重试，还取决于它运行在哪个 Profile、哪个账号、哪条代理、什么登录状态下。
所以这篇文章不写框架入门，也不讨论某个工具更好，而是给一个排查顺序：
先确认账号环境，再检查登录态和环境字段，最后再回到代码层。
一、浏览器自动化失败，不一定先改选择器
做 browser automation 时，经常会遇到这些现象：
-
脚本在本地可以跑，换一台机器就不稳定；
-
单账号可以跑，换成多账号任务就失败；
-
手动打开页面正常，自动化执行时却掉登录；
-
页面突然跳到验证页；
-
任务执行时跑到了错误账号；
-
同一段脚本在不同 Profile 下表现不一样。
这类问题如果直接归因到代码，很容易越改越复杂。
选择器改了，等待加了，重试也做了，但问题仍然反复出现。原因是浏览器自动化不是只在执行一段脚本，它是在某个具体账号、具体 Profile、具体代理和具体登录状态下执行任务。
环境不一致时，脚本再稳定，也会表现得不稳定。
二、第一层：确认是不是同一个 Profile
Profile 是多账号浏览器自动化里最容易被低估的一层。
同一个页面、同一段脚本，在不同 Profile 下看到的状态可能完全不同：
-
登录态不同；
-
账号权限不同；
-
页面语言不同；
-
缓存状态不同；
-
历史操作记录不同；
-
本地存储状态不同。
所以排查时，应该先问几个问题：
-
这次任务是不是在预期 Profile 下执行？
-
Profile 有没有被复制、重建或误用？
-
这个 Profile 是否长期对应同一个账号？
-
自动化任务启动时，是否读取了正确 Profile？
-
Profile 和账号之间有没有明确绑定关系？
如果 Profile 和账号关系不稳定，后面的 Cookie、Session、代理排查都会变得很混乱。
一个典型问题是：脚本逻辑没有变，但它这次跑在了另一个 Profile 下。页面状态、账号权限和本地存储都变了，脚本自然会表现出“不稳定”。
三、第二层：检查 Cookie、Session 和本地存储
很多人看到掉登录，就直接清 Cookie 或重新登录。
但登录态通常不只由 Cookie 决定。
Cookie 可能保存部分登录凭证，Session 往往在服务端维护账号会话，LocalStorage 或 IndexedDB 还可能保存前端应用状态、页面配置和临时数据。
所以排查时不要只问“Cookie 在不在”，而要按顺序看：
| Cookie | 是否存在、是否过期、是否被覆盖 | Cookie 还在，但登录态不完整 |
| Session | 服务端会话是否仍然有效 | 页面跳登录页或要求重新验证 |
| LocalStorage | 前端账号状态是否匹配 | 页面显示状态和当前账号不一致 |
| IndexedDB | 应用缓存和本地数据是否完整 | 部分页面能打开，部分功能异常 |
| Profile | 当前存储状态是否属于当前账号 | 一个 Profile 被多个账号混用 |
如果脚本在错误 Profile 下执行，或者同一个 Profile 被多个账号混用，就可能出现 Cookie 还在但页面状态不对的情况。
这时候继续加等待、改选择器，通常解决不了根本问题。
四、第三层：检查代理、时区、语言和 UA 等环境字段
浏览器自动化在多账号场景里，不只是页面操作，还涉及环境一致性。
代理变化、时区变化、语言变化、UA 变化，都可能让页面返回不同内容，触发额外验证，或者让账号状态发生变化。
排查时不要只看代理是否可用，还要看这些问题：
-
这条代理是否应该属于这个账号？
-
代理是否和 Profile 长期绑定？
-
任务执行前后代理是否发生过变化？
-
IP 地区和浏览器时区是否一致？
-
页面语言是否和预期一致？
-
UA 是否和之前环境保持稳定？
-
自动化执行时是否和手动打开时使用同一套环境？
如果网络出口和浏览器环境经常变化，自动化脚本会面对不断变化的页面状态，稳定性自然会下降。
有些脚本看起来是“偶发失败”，实际是每次运行时页面都不完全一样。
五、第四层：再看代码问题
只有在确认账号环境一致之后，才适合深入看代码层面的问题。
代码层面常见问题包括：
-
选择器依赖脆弱；
-
等待条件不准确；
-
页面跳转时机没有处理；
-
异步加载状态误判；
-
错误重试没有上下文判断；
-
异常捕获只记录报错，不记录环境状态；
-
任务日志没有记录 Profile、账号和代理。
但要注意，代码排查不能脱离环境。
同一个选择器，在不同账号权限下可能对应不同页面。 同一个按钮，在不同语言或 A/B 版本下可能文本不同。 同一个流程，在不同登录状态下可能走到不同页面。
因此，代码排查必须和环境排查一起看，不能孤立看脚本。
六、建议的排查顺序
可以按这个顺序排查浏览器自动化失败：
确认任务使用的是不是预期账号和预期 Profile。
检查 Cookie、Session、LocalStorage、IndexedDB 是否和当前账号状态一致。
检查代理、时区、语言、UA 等环境字段是否发生变化。
检查页面是否因为权限、验证、语言或版本变化进入了不同流程。
再检查选择器、等待、重试、异常捕获和任务日志。
这个顺序的好处是先排除环境变量，再处理代码变量。
否则很容易把环境问题误修成代码问题：脚本越改越复杂，但失败原因并没有被真正定位。
七、一个简单的排查表
下面这张表可以作为浏览器自动化失败时的快速定位入口。
| 脚本本地能跑，换账号失败 | Profile 是否正确、账号权限是否一致 |
| 页面跳到登录页 | Cookie 是否过期、Session 是否失效、代理是否变化 |
| 点击到了错误页面 | 账号权限、语言、页面版本和选择器稳定性 |
| 任务执行到了错误账号 | Profile 与账号是否一一对应、任务启动时是否读取了正确环境 |
| 手动正常，自动化异常 | 自动化启动时是否使用了同一 Profile、同一代理和同一登录态 |
| 同一脚本偶发失败 | 页面状态、网络出口、语言版本或异步加载是否发生变化 |
| 失败后无法复盘 | 任务日志是否记录账号、Profile、代理、步骤和页面状态 |
这张表不是为了替代代码调试，而是为了避免一开始就把所有问题都归因到代码。
八、建议记录的任务上下文字段
为了让失败可复盘，建议每次自动化任务至少记录这些字段。
| task_id | 本次任务的唯一编号 |
| account_id | 业务账号或内部账号标识，不要在日志里写明文密码 |
| profile_id | 本次执行使用的浏览器 Profile |
| proxy_id | 本次执行使用的代理标识，记录标识即可，不要暴露敏感凭证 |
| login_state | 任务开始前的登录状态，例如 valid、expired、unknown |
| entry_url | 任务入口页面 |
| step_name | 当前执行步骤 |
| failure_reason | 失败原因分类，例如 selector_timeout、session_expired、proxy_changed、permission_denied |
| screenshot_ref | 失败截图或页面快照位置 |
有了这些字段，排查时就不会只剩一句“脚本失败了”。
例如，看到 selector_timeout 时，不应该马上认定是选择器坏了，还要结合 profile_id、login_state、entry_url 和 screenshot_ref 判断：脚本是不是进入了另一个页面状态。
如果 failure_reason 是 session_expired，那优先要看 Session 和登录态，而不是继续加等待。
如果 proxy_id 和预期账号不匹配，那问题可能发生在环境绑定，而不是页面操作。
九、把排查流程落到环境管理里
这类排查最后都会回到一个问题：
团队有没有稳定记录浏览器环境和任务上下文。
如果团队已经在维护多个账号环境，就需要把 Profile、Proxy、Session、账号上下文和任务记录放到同一套环境管理方式里，减少自动化执行时的环境漂移。
这套记录不一定一开始就做成复杂系统。先用表格、日志文件或任务记录都可以，关键是字段固定、责任清楚、失败能回看。
浏览器自动化要稳定，不只是脚本稳定，还要让脚本始终运行在正确账号、正确环境和正确状态下。
具体用什么工具并不是第一步，先把这套排查口径固定下来更重要。
十、结论
browser automation 做多账号任务时，失败原因经常不在代码第一层。
在改选择器、加等待、加重试之前，先确认 Profile、登录态、代理和任务上下文是否一致。
自动化不是把页面点完，而是让任务在正确账号、正确环境、正确状态下执行。
这个顺序理清了，脚本问题才更容易被真正定位。
