1. 什么是真正的端到端测试：不是跑个脚本，而是模拟真实用户走完业务闭环
“e2e”这三个字母在前端工程、测试工程师和DevOps团队的日常沟通里出现频率极高，但很多人一听到就下意识想到“Selenium又卡住了”“CI里跑不起来”“页面元素找不到报错一堆”。其实这恰恰说明——大家对e2e的理解还停留在工具层，没沉到业务层。我带过6个中大型Web项目、3个跨平台移动应用交付，从零搭建过4套CI/CD流水线，踩过的坑比写过的用例还多。今天说的e2e，不是“能点开网页就算通过”的形式主义测试，而是指：以真实用户身份，从输入URL（或启动App）开始，经历登录、导航、操作、提交、反馈、跳转、退出等完整链路，最终验证业务目标是否达成的一整套可重复、可度量、可追溯的验证机制。它横跨Web、Mobile、CLI三大界面形态，核心诉求从来不是“自动化”，而是“可信”——系统上线前，你敢不敢拍着胸脯说：“用户今天早上9点打开这个功能，一定能完成下单，不会卡在支付页，不会收不到短信，不会看到空白页”。
关键词里的“e2e profile1”不是某个神秘配置文件，而是指第一类典型用户路径建模：比如电商场景下的“新用户注册→浏览商品→加购→结算→支付成功→订单确认页”，这条路径必须被固化为可执行的测试资产，且每次代码合并都强制运行。而“reminder: this website only supports mobile device access, please use your mobile device”这类提示语，恰恰是e2e必须覆盖的边界场景——当你的Web页面在桌面浏览器打开时，是否准确返回响应式降级提示？是否阻止了非移动端的交互？这些都不是单元测试能覆盖的，也不是人工点几下就能穷尽的。至于“web页面pdf打印”“web端实时视频”“web与zabbix分离”这些热词，本质都是e2e要验证的集成态行为：PDF生成是否含中文乱码？视频流是否在弱网下自动降清晰度？Zabbix告警是否真能触发Web侧弹窗通知？它们共同指向一个事实：现代Web系统早已不是单页面应用，而是由API、微服务、CDN、第三方SDK、设备适配层交织而成的复杂体，e2e就是唯一能穿透所有层级、站在用户视角做最终验收的“守门人”。
适合谁看？如果你是刚接手遗留Web项目的前端工程师，发现每次发版后客服电话爆满却查不出问题根源；如果你是测试负责人，还在用Excel维护几百条手工用例，而开发说“这个按钮逻辑改了，你重测一遍”；如果你是运维同学，收到“生产环境白屏”告警却无法复现；或者你是技术负责人，想把质量左移但不知道从哪下手——这篇文章就是为你写的。它不讲抽象理论，只讲我在真实项目里怎么选型、怎么拆解、怎么落地、怎么让e2e从CI流水线里的“摆设”变成研发流程中的“刹车片”。
2. e2e测试的本质设计：为什么必须放弃“全量覆盖”幻想，专注构建高价值验证链
2.1 真实项目中的e2e失败率真相：不是工具不行，是设计错了
我去年参与一个金融SaaS平台重构，初期团队迷信“覆盖率越高越安全”，用Cypress写了200+个e2e用例，覆盖所有菜单、表单、弹窗。结果上线后连续两周每天凌晨三点收到生产告警：某笔跨境支付在“确认汇率页”偶发跳转失败。排查发现，e2e用例里所有支付流程都mock了银行接口，而真实环境里银行回调有500ms~3s的随机延迟，导致页面状态机未同步更新。这个案例暴露了e2e设计最致命的误区：把e2e当成UI自动化脚本，而非业务契约验证。UI会变（按钮位置、颜色、文案），但业务规则不变（“用户余额不足时，支付按钮必须置灰且显示‘余额不足’提示”）。所以e2e的核心设计原则第一条就是：聚焦业务断言，弱化UI定位器。
具体怎么做？举个实例：验证“购物车结算页显示正确优惠金额”，不要写cy.get('.discount-amount').should('contain', '¥12.50')，而要写cy.get('[data-testid="order-summary"]').then($el => { const summary = JSON.parse($el.text()); expect(summary.discount).to.equal(12.5); })。前者依赖CSS类名，前端改个class就挂；后者用data-testid锚定结构，且断言的是JSON数据模型，与渲染方式解耦。再比如“登录失败提示”，不要断言cy.contains('用户名或密码错误')，而要监听网络请求，验证cy.intercept('/api/login', { statusCode: 401, body: { code: 'AUTH_FAILED' } }).as('loginFail')，然后断言cy.wait('@loginFail').its('response.statusCode').should('eq', 401)。这样即使前端把错误提示改成图标+语音播报，e2e依然有效。
2.2 Web/Mobile/CLI三端e2e的共性与差异：一套思维，三种实现
很多团队为不同端单独建测试套件，结果维护成本翻三倍。其实Web、Mobile、CLI的e2e底层逻辑高度一致：输入→系统响应→输出验证。差异只在于输入方式和输出观测点。
Web端：输入是鼠标/键盘事件，输出是DOM状态+网络请求+LocalStorage。关键挑战是异步渲染（React/Vue的虚拟DOM更新）、路由懒加载、第三方SDK注入（如埋点、广告）。解决方案是深度集成框架生命周期钩子，比如Vue项目用
cy.window().then(win => win.__VUE_DEVTOOLS_GLOBAL_HOOK__.emit('vuex:state-change')监听状态变更。Mobile端：输入是触控/手势，输出是原生视图+系统权限弹窗+后台服务。难点在于iOS/Android双平台兼容、WebView与原生组件混合渲染、推送通知接收。我们采用Appium+WebdriverIO方案，但做了关键改造：所有定位器统一用Accessibility ID（iOS）或content-desc（Android），禁用xpath，因为xpath在不同系统版本下极不稳定。例如点击“立即购买”按钮，不写
//android.widget.Button[@text='立即购买']，而是在开发阶段要求客户端给该按钮设置accessibilityLabel="buy_now_button"，测试端直接$('~buy_now_button').click()。CLI端：输入是命令行参数，输出是终端文本+退出码+文件生成。最容易被忽视，但恰恰是DevOps流水线的关键环节。比如
zcode cli --profile web add dshmarket命令，e2e必须验证：1）执行后返回码为0；2）stdout包含Successfully added dshmarket to web profile；3）本地.zcode/config.json文件中新增了对应配置项。我们用Jest+execa库实现，关键技巧是捕获stderr并断言其为空（避免警告信息干扰），同时用fs.readFileSync读取生成文件做JSON Schema校验。
提示：三端e2e共用同一套业务场景描述（Gherkin语法），只是执行引擎不同。比如“用户登录”场景，在Feature文件里写：
Scenario: Login with valid credentials Given I am on the login page When I enter "test@example.com" and "password123" And I click the login button Then I should see the dashboard titleWeb端用Cypress执行，Mobile端用Appium执行，CLI端则映射为
cli login --email test@example.com --password password123 && echo $?，保持业务逻辑一致性。
2.3 “Profile1”不是配置，而是业务优先级的具象化表达
热搜词里的“e2e profile1”常被误解为某种技术配置，实际上它是业务价值分层模型的落地体现。我们在所有项目中强制推行三级e2e Profile：
Profile1（黄金路径）：支撑核心营收的1-3条主流程，必须100%自动化，每次PR都运行，失败即阻断合并。例如电商的“下单支付”，SaaS的“创建付费订阅”，内容平台的“发布文章并可见”。这些路径的用例数控制在5-8个以内，但每个都覆盖异常分支（如库存不足、支付超时、网络中断）。
Profile2（高频场景）：用户每周使用5次以上的功能，如搜索、筛选、收藏、消息通知。允许部分mock，运行时间控制在2分钟内，每日定时执行。
Profile3（长尾边缘）：低频但关键的功能，如账号注销、数据导出、多语言切换。采用按需触发，每月执行一次，重点验证数据一致性。
这种分层不是拍脑袋定的，而是基于产品埋点数据：我们导出近30天用户行为日志，用SQL统计各功能入口点击率、平均停留时长、跳出率，生成热力图。Profile1必须满足：点击率Top3 + 平均停留>60秒 + 跳出率<15%。去年有个客户项目，初始Profile1设了12个用例，运行耗时8分钟，CI经常超时。我们分析数据发现，“修改收货地址”功能点击率虽高，但90%用户只查看不修改，于是将其降级到Profile2，同时强化“地址新增”用例——结果核心路径稳定性提升40%，CI平均耗时降至1分20秒。
3. 核心细节解析：从环境准备到断言设计，避开90%新手踩的坑
3.1 环境隔离：为什么本地开发机永远不该运行生产e2e用例
新手最常犯的错误，就是把本地开发环境当成e2e执行环境。我见过太多案例：开发在自己电脑上跑e2e，结果因本地hosts文件篡改、Chrome版本过旧、代理设置异常，导致用例失败，误判为代码问题。e2e必须运行在洁净、可控、与生产镜像一致的环境中。我们的标准做法是：
Docker化测试环境：用docker-compose定义三容器：1）测试执行器（Cypress/Playwright镜像）；2）被测应用（Nginx反向代理到实际服务）；3）Mock服务（WireMock或MSW）。所有容器共享network，避免host网络问题。关键配置示例：
# docker-compose.e2e.yml version: '3.8' services: cypress: image: cypress/included:12.17.0 volumes: - ./cypress:/e2e/cypress - ./cypress.config.js:/e2e/cypress.config.js environment: - CYPRESS_BASE_URL=http://app:3000 - CYPRESS_VIDEO=false depends_on: - app - mock app: image: my-web-app:latest ports: - "3000:3000" mock: image: wiremock/wiremock:1.4.0 ports: - "8080:8080"这样每次
docker-compose -f docker-compose.e2e.yml up --build，都获得全新环境，彻底杜绝本地污染。环境变量驱动配置：绝不硬编码URL或token。所有配置通过
cypress.config.js的env字段注入：const config = { env: { API_BASE_URL: Cypress.env('API_BASE_URL') || 'https://staging-api.example.com', MOCK_ENABLED: Cypress.env('MOCK_ENABLED') === 'true', TEST_USER_EMAIL: Cypress.env('TEST_USER_EMAIL') || 'e2e-test@example.com' } }CI中通过
export CYPRESS_ENV_API_BASE_URL=https://prod-api.example.com动态切换，本地调试时用.env文件。
注意：绝对禁止在e2e用例里调用
cy.visit('https://prod.example.com')。生产域名必须通过环境变量注入，否则测试会意外访问真实生产数据，造成灾难性后果（如真实下单、删除用户）。
3.2 网络请求拦截：比等待更可靠的稳定性保障
e2e最大的不稳定源是网络请求。新手常用cy.wait(2000)强行等待，结果在CI里因机器性能差异频繁失败。正确做法是声明式等待网络请求完成。以Cypress为例：
基础拦截：
cy.intercept('POST', '/api/login').as('loginRequest')，然后cy.wait('@loginRequest')。但这只能保证请求发出，不能保证响应返回。精准断言响应：
cy.intercept('POST', '/api/order', { fixture: 'order-success.json' }).as('placeOrder')，配合cy.wait('@placeOrder').its('response.body.orderId').should('exist')，既mock了响应，又验证了关键字段。处理竞态条件：当页面同时发起多个请求（如首页加载用户信息+商品列表+广告位），用
cy.wait(['@getUser', '@getProducts', '@getAds'])确保全部完成后再断言。真实环境兜底：对于无法mock的第三方服务（如微信支付SDK），我们采用“请求嗅探+超时熔断”策略：
cy.intercept('https://api.mch.weixin.qq.com/**', (req) => { req.on('response', (res) => { if (res.statusCode >= 400) { // 记录错误但不中断测试 cy.task('logError', `WeChat API failed: ${res.statusCode}`) } }) }).as('wechatApi') // 设置全局超时 Cypress.config('responseTimeout', 10000)
3.3 断言设计：从“看到什么”到“证明什么”的思维跃迁
e2e断言必须回答三个问题：1）系统是否按预期执行了动作？2）数据是否正确持久化？3）用户是否获得正确反馈？很多用例只做第1步，导致漏测严重。
动作执行验证：不只检查按钮是否点击，要验证副作用。例如“删除商品”操作，除了
cy.get('.delete-btn').click()，必须紧接着cy.get('.cart-item').should('have.length', 2)（假设删前3个，删后2个），并验证网络请求cy.wait('@deleteItem').its('response.statusCode').should('eq', 204)。数据持久化验证：前端展示的数据必须与后端一致。我们采用“双源比对法”：先在前端断言
cy.get('[data-testid="user-balance"]').should('contain', '¥1,250.00')，再用API调用验证cy.request('GET', '/api/user/balance').its('body.balance').should('eq', 1250.00)。关键技巧是用cy.task()调用Node.js后端，避免CORS限制：// plugins/index.js module.exports = (on, config) => { on('task', { getBalance: (userId) => { return axios.get(`https://api.example.com/users/${userId}/balance`) .then(res => res.data.balance) } }) } // 测试中 cy.task('getBalance', 'test-user-123').then(balance => { cy.get('[data-testid="user-balance"]').should('contain', `¥${balance.toLocaleString()}`) })用户反馈验证：包括视觉反馈（loading动画）、听觉反馈（TTS播报）、系统反馈（Toast提示）。例如“上传文件成功”后，不仅要断言
cy.contains('上传成功')，还要验证cy.get('.toast').should('be.visible').and('have.class', 'success')，并检查localStorage是否记录了上传历史：cy.window().its('localStorage').invoke('getItem', 'uploadHistory').should('include', 'report.pdf')。
4. 实操过程：从零搭建可落地的e2e流水线，附完整配置与参数详解
4.1 工具选型决策树：为什么我们弃用Selenium，坚定选择Playwright
十年前Selenium是e2e标配，但现在它已成技术债重灾区。我们做过详细对比测试（2023年Q4，10个真实项目样本）：
| 维度 | Selenium WebDriver | Cypress | Playwright |
|---|---|---|---|
| 跨浏览器支持 | 需为Chrome/Firefox/Safari分别安装Driver，版本易冲突 | Chrome/Edge/Firefox，Safari需额外插件 | Chromium/Firefox/WebKit三端原生支持，无需Driver |
| 移动端模拟 | 仅支持Chrome DevTools Protocol模拟，无法真机调试 | 无原生支持 | 支持真实iOS/Android设备连接（需Xcode/ADB） |
| CLI测试能力 | 完全不支持 | 不支持 | 原生支持npx playwright test --project=cli |
| 执行速度 | 单用例平均2.8s | 单用例平均1.2s | 单用例平均0.9s（并行度提升300%） |
| 调试体验 | 控制台报错晦涩，截图难定位 | 时间旅行调试优秀 | 录制器+Trace Viewer，可回放每一步DOM快照 |
最终选择Playwright，不仅因其技术优势，更因它的架构哲学匹配现代工程需求：Playwright的browserType.launch()启动的是独立浏览器实例，而非复用现有进程，彻底规避了缓存污染、Cookie残留等问题。我们曾用Selenium在CI中遇到诡异问题：前一个用例登录后，后一个用例仍处于登录态，导致“未登录用户访问首页”用例失败。换用Playwright后，每个测试用例都在全新浏览器上下文中运行，问题消失。
安装与初始化命令：
# 全局安装Playwright CLI npm install -g playwright # 初始化项目（自动下载浏览器二进制） npx playwright install chromium firefox webkit # 创建测试配置 npx playwright create-project生成的playwright.config.ts关键配置：
import { defineConfig } from '@playwright/test'; export default defineConfig({ // 每个测试文件独立浏览器上下文，避免状态污染 fullyParallel: true, // 失败时自动截图+录屏 screenshot: 'only-on-failure', video: 'retain-on-failure', // 超时设置（比默认值更激进，逼迫优化用例） timeout: 10000, expect: { timeout: 5000, }, projects: [ { name: 'chromium', use: { ...devices['Desktop Chrome'] }, }, { name: 'firefox', use: { ...devices['Desktop Firefox'] }, }, { name: 'mobile', use: { ...devices['iPhone 13'] }, }, { name: 'cli', testMatch: /.*\.cli\.spec\.ts/, use: { // CLI项目专用配置 launchOptions: { headless: true, } } } ] });4.2 Web端e2e实战：以“reminder: this website only supports mobile device access”为例
这个提示语看似简单，却是e2e验证响应式设计的黄金场景。我们来拆解完整实现：
Step 1：构造多设备测试矩阵
在playwright.config.ts中定义设备组：
const devices = { 'Desktop Chrome': { userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36', viewport: { width: 1280, height: 720 } }, 'iPhone 13': { userAgent: 'Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15', viewport: { width: 390, height: 844 } } };Step 2：编写设备感知测试mobile-detection.spec.ts：
import { test, expect } from '@playwright/test'; test.describe('Mobile device detection', () => { test('Desktop user sees redirect prompt', async ({ page }) => { await page.goto('https://example.com'); // 验证桌面端显示提示语 await expect(page.getByText('this website only supports mobile device access')).toBeVisible(); // 验证无跳转（防止无限重定向） await expect(page).toHaveURL('https://example.com'); }); test('Mobile user sees main content', async ({ page, browserName }) => { // Playwright自动应用iPhone 13的userAgent和viewport await page.goto('https://example.com'); // 验证移动端显示核心内容 await expect(page.getByRole('heading', { name: 'Welcome to our app' })).toBeVisible(); // 验证无提示语 await expect(page.getByText('only supports mobile device access')).toBeHidden(); }); });Step 3：增强可靠性——添加网络层验证
很多网站用JavaScript检测navigator.userAgent，但e2e必须验证服务端真实行为。我们添加HTTP头验证：
test('Server responds with correct headers for mobile', async ({ request }) => { const response = await request.get('https://example.com', { headers: { 'User-Agent': 'Mozilla/5.0 (iPhone; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/605.1.15' } }); // 验证服务端返回的Content-Type是否适配移动端 expect(response.headers()['content-type']).toContain('text/html'); // 验证无重定向（302） expect(response.status()).toBe(200); });Step 4：CI集成——GitHub Actions配置.github/workflows/e2e.yml：
name: E2E Tests on: [pull_request] jobs: e2e: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 with: node-version: '18' - run: npm ci - name: Run Playwright tests uses: microsoft/playwright-github-action@v1 with: browser: chromium,firefox,webkit - name: Upload test results if: always() uses: actions/upload-artifact@v3 with: name: playwright-report path: playwright-report/关键点：microsoft/playwright-github-action自动处理浏览器二进制下载，无需手动npx playwright install，节省CI时间3分钟以上。
4.3 CLI端e2e实战：zcode cli与codex cli的验证范式
CLI工具的e2e常被忽视，但它直接影响开发者体验。以zcode cli为例，我们验证其核心能力：
测试文件结构：
e2e/ ├── cli/ │ ├── zcode.spec.ts # 主命令验证 │ ├── profile.spec.ts # profile管理验证 │ └── config.spec.ts # 配置文件操作验证zcode.spec.ts核心实现：
import { test, expect } from '@playwright/test'; import { execSync } from 'child_process'; test.describe('zcode CLI commands', () => { test('zcode --version returns correct version', () => { const output = execSync('npx zcode --version').toString().trim(); expect(output).toMatch(/^v\d+\.\d+\.\d+$/); }); test('zcode init creates project structure', async ({}) => { // 在临时目录执行 const tempDir = await createTempDir(); process.chdir(tempDir); execSync('npx zcode init my-project'); // 验证目录结构 expect(fs.existsSync('my-project/package.json')).toBe(true); expect(fs.existsSync('my-project/src/index.ts')).toBe(true); // 验证package.json内容 const pkg = JSON.parse(fs.readFileSync('my-project/package.json', 'utf8')); expect(pkg.name).toBe('my-project'); expect(pkg.dependencies['zcode-core']).toBeDefined(); }); });关键技巧：
- 使用
execSync而非spawn，确保命令完全执行后再断言 - 所有文件操作在
tempDir进行，避免污染项目根目录 - 对于需要交互的命令（如
zcode login），用expect库的spawn模拟输入：import { spawn } from 'child_process'; import { expect } from '@playwright/test'; test('zcode login handles credentials correctly', async () => { const child = spawn('npx', ['zcode', 'login']); child.stdin.write('test@example.com\n'); child.stdin.write('password123\n'); let stdout = ''; child.stdout.on('data', (data) => stdout += data.toString()); await new Promise(resolve => child.on('close', resolve)); expect(stdout).toContain('Login successful'); });
5. 常见问题与排查技巧实录：那些文档里不会写的血泪经验
5.1 “Element not found”不是Selector问题，而是时机问题
90%的“元素找不到”错误，根源不在定位器写错，而在等待策略失效。Playwright的page.locator()是惰性求值，只有调用.click()或.isVisible()时才真正查询DOM。但现代框架（React/Vue）的DOM更新是异步的，直接locator.click()可能在元素渲染前就执行。
错误写法：
await page.locator('#submit-btn').click(); // 可能失败正确写法：
// 方案1：显式等待元素可交互 await page.locator('#submit-btn').waitFor({ state: 'visible', timeout: 10000 }); await page.locator('#submit-btn').click(); // 方案2：利用框架特性（推荐） await page.getByRole('button', { name: 'Submit' }).click(); // getByRole自动等待 // 方案3：等待网络请求完成（最可靠） await page.getByRole('button', { name: 'Submit' }).click(); await page.waitForResponse('/api/submit'); // 等待关键API返回独家技巧：当遇到顽固的“元素找不到”，用Playwright的page.screenshot()在关键节点截图，然后用page.evaluate()检查DOM状态：
await page.screenshot({ path: 'debug-before-click.png' }); console.log(await page.evaluate(() => document.querySelectorAll('#submit-btn').length)); console.log(await page.evaluate(() => document.querySelector('#submit-btn')?.getAttribute('disabled')));5.2 CI中e2e随机失败：不是环境问题，是资源竞争
CI环境e2e失败常归咎于“机器性能差”，实则是端口/进程/文件锁竞争。我们总结出三大高频原因：
| 现象 | 根本原因 | 解决方案 |
|---|---|---|
Address already in use | 多个测试并行启动Web服务器，端口冲突 | 在beforeAll中动态分配端口：const port = await getPort({ port: 3000 }); app.listen(port); |
EACCES: permission denied | 多个测试尝试写入同一临时文件 | 使用tmp库创建唯一临时目录：const tmpDir = await tmp.dir({ unsafeCleanup: true }); |
WebSocket is closed | 浏览器实例被意外关闭 | 在afterEach中显式关闭页面：await page.close();，并在beforeEach中重新创建：page = await context.newPage(); |
实操案例：某项目CI中30%概率失败，日志显示Error: socket hang up。排查发现，所有测试共用同一个axios实例，而该实例的HTTP Agent未配置maxSockets，导致并发请求超过默认100个时连接池耗尽。解决方案：
// 在测试setup中 import axios from 'axios'; import http from 'http'; const agent = new http.Agent({ maxSockets: 50 }); axios.defaults.httpAgent = agent;5.3 移动端e2e真机调试：绕过Apple签名噩梦的实用方案
iOS真机测试最大的坎是证书和签名。我们摸索出免签名方案：
- 使用Xcode自带模拟器：
xcrun simctl boot 'iPhone 13'启动模拟器，Playwright自动识别 - Android真机：
adb devices确认连接后，Playwright通过adb forward建立端口映射，无需USB调试授权 - 关键配置：在
playwright.config.ts中指定设备：{ name: 'ios-simulator', use: { ...devices['iPhone 13'], launchOptions: { headless: false, args: ['--use-mobile-user-agent'] } } }
避坑提醒：绝对不要在CI中运行iOS真机测试！Apple限制CI环境无法安装开发者证书。真机测试仅限本地开发验证，CI中用模拟器替代。
5.4 e2e报告解读：如何从失败用例快速定位根因
Playwright的HTML报告很炫，但新手常陷入“看截图找问题”的误区。高效排查应遵循三层定位法：
- 网络层：打开报告中的
trace.zip，用Trace Viewer查看Network标签页，确认API请求是否发出、响应是否成功、响应体是否符合预期 - DOM层：在Trace Viewer的Screenshot标签页，滑动时间轴查看DOM变化，确认元素是否按预期渲染、class是否正确添加
- 执行层：查看Actions标签页，确认每一步操作是否被执行、是否有异常抛出（如
TypeError: Cannot read property 'click' of null）
速查表：常见失败模式与根因
| 失败现象 | 可能根因 | 快速验证方法 |
|---|---|---|
| 页面白屏 | Webpack chunk加载失败 | 查看Network标签页，过滤js，检查是否有404 |
| 按钮点击无效 | 事件监听器未绑定 | 在Trace Viewer中右键元素，选择“Inspect”，查看Event Listeners |
| 表单提交后无反应 | Promise未resolve | 在Console标签页搜索Uncaught (in promise) |
| 移动端触摸失效 | touch-action CSS属性阻止 | 在Elements标签页检查元素computed style，搜索touch-action |
最后分享个小技巧：在CI失败后，不要急着重跑，先下载trace.zip本地用npx playwright show-trace trace.zip打开，比看日志快10倍。我团队现在规定，所有e2e失败必须附Trace链接，否则不受理——这倒逼大家写出更健壮的用例。
