Playwright 实战：五个让 Web 自动化从「能跑」到「稳定」的细节

写自动化脚本最挫败的时刻，不是写不出来，而是"昨天还好好的，今天全挂了"。过去一段时间我用 Playwright 把一批重复的网页操作固化成了脚本，从最初的三次跑两次错，到现在基本可以无人值守，踩的坑集中在五个地方。这篇把它们整理出来。

一、模态框会吞掉你所有的点击

最容易误判的一类问题：脚本明明点到了正确坐标，元素却没反应。原因往往是有个浮层盖在上面——权限提示、公告弹窗、引导气泡。它们不影响坐标计算，但会吃掉 mousedown。

我的做法是抽一个 kill_modal()，在每次动作前扫一遍页面上文案为「确定 / 知道了 / 关闭」且可见的按钮，点掉再继续。看起来粗暴，但比在每个步骤里单独处理要可靠得多。

二、坐标点击在滚动之后并不可靠

先用 getBoundingClientRect() 取中心点再 mouse.click()，是很多人（包括我）的第一选择。但只要页面在取坐标和点击之间发生了滚动、展开、动画位移，点就会落偏。

对于单选、复选、开关这类语义明确的控件，直接对 label 调用 click() 反而更稳：不依赖几何位置，也不受视口影响。我有一轮排查了半天的"选项全选错"，根因就是坐标在滚动后失效。

三、别用固定 sleep 等状态

sleep(3) 是本地的确定性，网络的非确定性。稳妥的做法是轮询"期望状态出现"，并给一个上限。比如等待跳转就轮询 URL 关键字，等待渲染完就轮询目标元素是否可点。写起来多几行，但成功率差别很大。

四、每一步都要有可验证的结果

脚本最容易骗自己的地方，是"我以为它成功了"。所以每个关键步骤我都加一条断言：点击签到后积分是否 +10，提交表单后 URL 是否变成成功页，选择选项后选中态是否与预期集合完全一致。

断言不一致时不盲目重试——先把当时的 DOM 快照和截图存下来。事后定位问题，靠的就是这份现场。

五、登录态要按"跨进程可用"设计

很多站点的会话 cookie 是会话级的（没有过期时间），关掉浏览器就没了，指望它留在浏览器用户目录里是不现实的。可行的方案是登录成功后立刻导出 storage_state（包含 cookie 与 localStorage），后续每次启动用 new_context(storage_state=...) 复用。

这样脚本可以拆成多个独立进程，谁都不依赖"上一个进程没关浏览器"。

最后一点体会

自动化的成本大头不在写，而在维护。把"为什么这么写"记在注释和文档里，比把代码写得漂亮重要得多——因为三个月后回来改脚本的人，大概率是你自己。