做UI自动化测试的朋友应该都有过这种体验——本地跑得好好的，一上CI就挂；周一全绿，周二莫名其妙红一片；加了sleep能过，不加就报元素找不到。

如果你也遇到过这些情况，别急着怀疑是自己的代码写得不够好。很多时候问题出在“习惯”上——把Selenium时代的老经验照搬到Playwright里，或者没搞清楚Playwright的底层机制就开始写用例。

下面这8个坑，是我和团队在过去一年里一个一个踩过来的。整理出来，希望能帮你少走点弯路。

坑1：还在用waitForTimeout /sleep 硬等

这是新手最容易犯的错误，没有之一。

很多人习惯了Selenium里那种Thread.sleep(3000) 的写法，到了Playwright还是改不掉。动不动就page.wait_for_timeout(5000)，觉得“等5秒总该加载完了吧”。

问题在哪？ 固定等待时间就像刻舟求剑——网络快的时候浪费5秒，网络慢的时候5秒还不够。测试要么跑得慢，要么时好时坏。

正确的做法：Playwright自带自动等待机制，执行click()、fill() 这些操作之前，它会自动等待元素可见、可操作、稳定。你什么都不用写。

# ❌ 错误示范
page.wait_for_timeout(3000)
page.locator("#submit").click()

# ✅ 正确示范——Playwright自己会等
page.locator("#submit").click()  # 自动等待按钮可点击

如果确实需要等待某个特定条件（比如API返回数据），用wait_for_response 或wait_for_selector，绑定到明确信号上。

什么时候可以用 wait_for_timeout？ 说实话，90%的场景用不上。只有在调试阶段或者等待第三方非交互内容加载时，才把它当作最后手段。

坑2：定位器写得“太聪明”

复杂CSS选择器、依赖文本内容的选择器、XPath——这些东西写的时候觉得很爽，一改版全废。

比如你写了个page.locator('#main-content > div:nth-child(3) > button')，开发同事把页面结构调整了一下，你的测试就挂了。

正确的做法：**优先用data-testid**。让开发在核心UI元素上加上测试专用的属性，这是代码和测试之间的“契约”。

# ❌ 脆弱的选择器
page.locator('#app > div.container > button.btn-primary')

# ✅ 稳定的选择器
page.locator('[data-testid="submit-button"]')

如果项目里暂时没有data-testid，退而求其次可以用get_by_role 或get_by_text，但尽量选择不容易变动的属性。

坑3：自动等待“撞上”组件重渲染

这个坑比较隐蔽，很多人都没意识到。

Playwright的自动等待机制是这样的：它检查元素是否可见、稳定、可操作，检查通过之后立即执行操作。但如果就在“检查通过”和“执行操作”之间的那个瞬间，你的组件正好重新渲染了——按钮被替换成了一个新按钮——点击就会失败，报错Element is not attached to the DOM。

典型场景：点击保存按钮，按钮变成“保存中...”的禁用状态，保存完成后再变回可点击状态。第二次点击就可能撞上重渲染。

解决方案：

# 方案一：用 data-testid 定位到不会重渲染的外层元素
save_button = page.locator('[data-testid="save-container"] button')
save_button.click()

# 方案二：点击前先显式等待一下
save_button.wait_for(state="visible")
save_button.click()

或者更干脆——在测试环境里把动画效果关掉，减少重渲染的触发。

坑4：每个测试都从头登录

一套测试用例几十上百个，每个用例都打开登录页、输用户名密码、点登录——慢不说，万一登录接口挂了，所有测试全崩。

解决方案：用storageState 保存登录态。

# 先跑一次登录，保存登录状态到文件
# 在 playwright.config.py 里配置
use = {
    "storage_state": "auth.json"
}

这样每个测试启动时就已经是登录状态了，又快又稳。

坑5：测试之间“互相传染”

这个坑特别恶心——单个用例跑全过，一起跑就随机挂。问题出在测试之间共享了可变状态。

比如你在模块级别定义了一个page 对象，用例A把它导航到了页面A，用例B以为它还在首页，结果就挂了。

解决方案：**每个测试用独立的page 或context**。Playwright的fixture机制天然支持这一点：

# ✅ 每个测试都有自己的 page，互不干扰
def test_something(page):
    page.goto("/page-a")
    # ...

def test_something_else(page):
    page.goto("/page-b")  # 干净的页面，不受上一个用例影响
    # ...

如果确实需要共享某些只读数据（比如配置），用beforeAll 没问题，但不要共享可变对象。

坑6：滥用networkidle 等待

page.wait_for_load_state("networkidle") 看起来很美——“等所有网络请求都结束了再继续”。但问题在于：单页应用（SPA）里网络请求可能永远停不下来——轮询、WebSocket、长连接，这些东西会让networkidle 一直等下去。

解决方案：不要等“所有请求结束”，等“你关心的那个请求结束”。

# ❌ 可能永远等不完
page.wait_for_load_state("networkidle")

# ✅ 只等数据接口返回
with page.expect_response("**/api/orders") as response_info:
    page.locator("#load-orders").click()
response = response_info.value

这样既精准又高效。

坑7：Trace/视频全程开着

Trace和视频确实好用，出问题的时候能帮你快速定位。但全程开着会严重拖慢测试速度，CI上跑一次多花好几分钟。

解决方案：只在失败时开启。

# playwright.config.py
use = {
    "trace": "on-first-retry",  # 只在重试时录trace
    "video": "on-first-retry",
}

这样大部分通过的测试跑得快，失败的测试也有足够的现场信息供排查。

坑8：盲目加并发

“测试跑得慢？加worker！”——这个思路听起来没毛病，但实际上并发不是越高越好。

并发太高会导致CPU、内存、数据库连接池资源竞争，测试反而更慢，甚至出现莫名其妙的超时失败。

解决方案：先profile再调参。先跑一遍看看瓶颈在哪——是CPU满了？数据库连接不够？还是网络带宽受限？找到真正的瓶颈再决定要不要加worker，加几个。

一张表总结

坑	核心问题	解决方案
硬编码等待	用sleep/固定超时	依赖Playwright自动等待 + web-first断言
脆弱定位器	依赖CSS层级/文本	优先data-testid 或get_by_role
自动等待撞重渲染	组件在操作瞬间被替换	用稳定定位器 + 显式wait_for
重复登录	每个用例都走登录流程	用storageState 复用登录态
测试间状态污染	共享可变对象	每个用例独立page/context
滥用networkidle	SPA里请求停不下来	等特定API响应，不等全部
Trace全程开	拖慢测试速度	只在失败/重试时开启
盲目加并发	资源竞争反而更慢	先找瓶颈再调worker数

最后说两句

上面这些坑，大多数不是Playwright本身的问题，而是使用方式的问题。它提供的工具都是好工具，关键看你怎么用。

如果你刚接触Playwright不久，建议从“坑3”（自动等待撞重渲染）和“坑6”（networkidle）这两个入手重点看一下——这两个是最容易让人困惑、也最不容易自己琢磨明白的。

如果你的测试套件已经有一定规模了，建议优先排查“坑4”（重复登录）和“坑5”（测试间污染），这两个对稳定性和速度的影响最大。

你有什么踩过的坑上面没提到的？欢迎评论区补充，大家一起避雷。