浏览器自动化最脆弱的是登录态，不是选择器

做发布自动化的时候，我一直盯着选择器和等待时机，觉得难点在页面。结果真正让项目停摆的是另一件事。

发生了什么

测试阶段产生了几个临时浏览器身份（profile），我想着”干净一点”，把整个用户目录清了一遍。 里面有测试用的，也有已经登录好、正在用的那个。

清完之后：每次启动都要求重新登录 → 自动化第一步就断 → 再也没能完成一次完整验证。

教训

登录态是这类项目里最贵的东西，应该在第一天就做成本隔离：

profiles/
├── test/      随便造、随便删
└── work/      只在人工确认后创建，绝不清空

原则就两条：

• 测试身份和正式身份物理隔离，不同用户目录，不同启动参数
• 正式身份不做自动清理，要重来必须人工点一次”我确认”

另外一个反直觉的点

自动化里”模拟登录”通常不是好选择。新设备、新指纹、异地 IP 登录，风控基本会拦。 复用真实浏览器的已登录状态更稳——代价就是上面说的：这个状态很脆弱，要当数据一样保护。

顺带

• 操作节奏太快也会触发平台风控，waitForTimeout 有时候不是”写得丑”，是必要成本
• 能不做发布就不做：把内容准备好、复制到剪贴板，人点两下粘贴，比全自动稳定得多，风险也小