谈论浏览器自动化时，人们往往先想到选择器、脚本和速度。但在实际项目中，真正的挑战常常出现在一个不那么光鲜的角落：会话保真度。最近，我参与处理了一个发布工作流，自动化脚本在纸面上无懈可击：能够打开正确的URL，导航到文章编辑器，检查页面结构，甚至截图。然而前几次运行结果都显示“未登录”，而人类操作员明明正盯着一个完全已认证的编辑器窗口。

这种不一致，成了理解整个问题的突破口。任务本身很简单：打开 dev.to/new，确认编辑器可用，填写标题、标签和正文，然后发布。自动化确实访问了正确的URL，但问题是，它是在一个与用户当前可见窗口完全不同的浏览器上下文中执行的。

于是，两件看似矛盾的事情同时为真：可见的Chrome窗口显示已认证的编辑器，而自动化会话看到的是登录页面。乍一看，这似乎属于工具不稳定。实际上，它是上下文边界问题。

为什么这种情况如此普遍？许多自动化方案的实质，是“另开一个浏览器，并重复相同操作”。公开页面、测试环境和隔离脚本用这种方式自然没问题。但一旦工作流依赖现有登录状态、扩展程序、浏览器专属存储、多用户配置文件，或者用户手动打开的标签页，这种方式就会变得极为脆弱。

在这种情况下，关键并不是浏览器程序本身，而是会话。如果自动化启动的是一个全新的受控浏览器，即使它与用户使用的是同一个可执行文件，依然会丢失cookies、localStorage、扩展存储、配置文件认证，甚至是用户活动窗口中的标签页状态。于是，脚本报“未登录”，用户却说自己“正盯着编辑器”，两者都没有说谎。

解决方案的核心，是让自动化会话与真实用户会话对齐。一个有效做法是复用现有浏览器实例，通过调试端口连接用户正在使用的窗口；另一种思路是完整迁移所有会话状态，但实际操作中容易遗漏。在验证时，我尝试通过CDP（Chrome DevTools Protocol）连接到现有浏览器，自动化立刻读取到了正确的登录态，整个流程一次通过。

所以，下次当你遇到自动化“没有理由”地失败，先别急着怀疑工具或选择器。停下来想想：你的自动化进程，是否真的站在用户所在的上下文中？会话边界，才是那个最隐蔽的陷阱。