做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。典型场景点击保存按钮按钮变成“保存中…”的禁用状态保存完成后再变回可点击状态。第二次点击就可能撞上重渲染。解决方案方案一用>方案二点击前先显式等待一下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这样既精准又高效。坑7Trace/视频全程开着Trace和视频确实好用出问题的时候能帮你快速定位。但全程开着会严重拖慢测试速度CI上跑一次多花好几分钟。解决方案只在失败时开启。playwright.config.pyuse {“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滥用networkidleSPA里请求停不下来等特定API响应不等全部Trace全程开拖慢测试速度只在失败/重试时开启盲目加并发资源竞争反而更慢先找瓶颈再调worker数最后说两句上面这些坑大多数不是Playwright本身的问题而是使用方式的问题。它提供的工具都是好工具关键看你怎么用。如果你刚接触Playwright不久建议从“坑3”自动等待撞重渲染和“坑6”networkidle这两个入手重点看一下——这两个是最容易让人困惑、也最不容易自己琢磨明白的。如果你的测试套件已经有一定规模了建议优先排查“坑4”重复登录和“坑5”测试间污染这两个对稳定性和速度的影响最大。你有什么踩过的坑上面没提到的欢迎评论区补充大家一起避雷。