e2e不是缩写，而是用户旅程验证的工程范式

1. “e2e”不是缩写，而是一套完整验证逻辑的代称

很多人第一次看到“e2e”，下意识会去查全称——End-to-End？没错，字面确实是“端到端”，但这个词在工程实践里早已脱离字面束缚，变成一种验证范式的统称。它不特指某一个工具、某一行命令，也不绑定某个语言或框架；它代表的是：从用户真实操作路径出发，以系统对外暴露的完整交互界面为唯一观测点，全程不绕过UI、不打洞、不mock内部状态，只模拟人眼所见、手指所触、键盘所敲的真实行为流。

这恰恰解释了为什么“e2e”能同时出现在 web、mobile apps、CLI 这三类差异巨大的场景中——它们表面形态不同，但都共享同一个验证本质：用户不会关心你后端用了 Spring Boot 还是 Node.js，不会在意数据库是 PostgreSQL 还是 MongoDB，更不会去读你的 service 层代码。用户只做三件事：打开页面/启动 App/输入命令 → 看到界面/收到响应 → 做出下一步动作 → 最终达成目标（下单、查询、导出 PDF、启动模型）。e2e 测试要做的，就是把这整条链路当成黑盒，用自动化方式重走一遍，并断言每一步的结果是否符合预期。

所以当你在热搜词里看到 “e2e profile1”、“web项目”、“CLI”、“zcode cli”、“lm studio cli 启动模型时提示‘model not found’如何解决？”这些看似零散的关键词，其实都在指向同一个底层需求：如何验证一个“可交付产物”在真实运行环境中能否完成它承诺的功能闭环。比如：

• 一个 web 页面点击“导出PDF”按钮，最终生成的 PDF 文件是否包含正确标题、表格数据是否对齐、页眉页脚是否显示；
• 一个 CLI 工具执行codex cli --model llama3 --prompt "hello"，终端是否输出预期文本，而非卡死、报错或返回空字符串；
• 一个 mobile app 在 iOS 上完成登录 → 切换 Tab → 下拉刷新 → 上传图片 → 查看缩略图，整个流程是否无白屏、无崩溃、无网络超时提示。

这些都不是单元测试能覆盖的——单元测试验证函数输入输出，集成测试验证模块间调用，而 e2e 验证的是用户旅程的完整性与稳定性。它天然带有“高保真、低速度、难调试”的特征，也因此常被团队搁置或浅层使用。但真正经历过线上事故的人会明白：90% 的 P0 级故障，根本不是因为某个函数算错了，而是因为前端路由配置漏了一条、API 响应结构变了但 UI 没适配、CLI 参数解析逻辑升级后旧命令失效——这些，只有 e2e 能提前捕获。

我做过 7 个中大型 web 工程的 e2e 体系建设，也给 3 个 CLI 工具搭建过全链路回归验证。最深的体会是：e2e 不是“测试类型”，而是交付前的最后一道质量门禁。它不追求覆盖率数字，而追求“关键用户路径是否稳如磐石”。下面我会从四个维度展开：为什么多数团队的 e2e 是伪落地、如何为 web/moblie/CLI 三类载体设计真正可用的 e2e 架构、e2e 执行环境的真实瓶颈在哪、以及一套可直接抄作业的最小可行验证模板。

2. 大多数团队的 e2e 只是“跑通了”，不是“跑稳了”

我见过太多所谓“已接入 e2e”的项目，CI 流水线里确实挂着npm run test:e2e，但点开报告一看：失败率常年 15%-30%，每次失败都要人工介入排查是环境问题还是功能缺陷；测试用例命名全是should login success、should list items，没有业务语义；执行一次全量 e2e 要 47 分钟，开发改完一行代码不敢本地跑，只能等 nightly job；最离谱的是，有团队把 Cypress 写的浏览器测试和 Jest + Puppeteer 混在一起，用例里既有cy.visit()又有page.goto()，维护者根本分不清哪段走的是 Cypress 引擎、哪段走的是 Puppeteer 引擎。

这不是工具的问题，是对 e2e 验证边界的认知偏差。e2e 的核心约束只有一个：必须复现真实用户路径，且所有断言必须基于用户可感知的状态。这意味着：

• ❌ 不能断言expect(store.getState().user.token).toBe('xxx')—— 用户看不到 token；
• ❌ 不能mock fetch或spyOn axios.post—— 用户不关心你用什么库发请求；
• ❌ 不能cy.get('.hidden-input').type('test')—— 用户不会去操作隐藏域；
• ✅ 必须cy.get('[data-testid="login-button"]').click()→cy.url().should('include', '/dashboard')→cy.contains('Welcome, John').should('be.visible')；
• ✅ 必须page.click('text=Submit')→await page.waitForResponse('/api/order')→await expect(page.locator('text=Order confirmed')).toBeVisible()。

这个原则看似简单，实操中却处处是坑。举个真实案例：我们曾为一个 B 站首页推荐算法的 web 版本做 e2e 验证。需求是“用户登录后，首页 Feed 流应展示个性化推荐内容”。团队最初写的用例是：

// ❌ 伪 e2e：绕过 UI，直取数据 cy.request('/api/v1/recommend/feed?uid=123') .then(res => { expect(res.body.items.length).to.be.greaterThan(0) expect(res.body.items[0].score).to.be.greaterThan(0.8) })

这段代码跑得飞快，但完全无效——它没验证任何用户可见的东西。真实场景中，Feed 流加载依赖多个条件：用户是否完成兴趣标签选择、是否开启个性化开关、服务端 AB 实验分组、CDN 缓存命中率……而cy.request()绕过了所有前端逻辑，等于在验证一个“理想态 API”，而非“用户实际看到的页面”。

后来我们重构为真正的 e2e：

// ✅ 真 e2e：只操作 UI，只断言可见元素 cy.visit('/') cy.get('[data-testid="login-btn"]').click() cy.get('[data-testid="username-input"]').type('testuser') cy.get('[data-testid="password-input"]').type('123456') cy.get('[data-testid="submit-btn"]').click() // 等待首页完全渲染（含懒加载组件） cy.get('[data-testid="feed-container"]').should('be.visible') cy.get('[data-testid="feed-item"]').should('have.length.greaterThan', 5) // 验证首条内容具备个性化特征（非硬编码 ID，而是业务语义） cy.get('[data-testid="feed-item"]').first().within(() => { cy.get('[data-testid="item-title"]').should('contain.text', 'AI') cy.get('[data-testid="item-tag"]').should('contain.text', '推荐') cy.get('[data-testid="item-duration"]').should('match', /分钟前$/) })

这个版本执行慢了 3 倍（平均 8.2s vs 1.3s），但每次失败都能精准定位到真实问题：某次上线后，[data-testid="item-tag"]元素因 CSS 类名变更未渲染，导致断言失败——这正是线上用户会遇到的白屏问题。而之前的伪 e2e 根本无法发现。

提示：判断你的 e2e 是否真实，只需问一个问题：如果我把这段测试代码拿给一个完全不懂技术的产品经理看，他能否理解“用户做了什么、看到了什么、验证了什么”？如果答案是否定的，那它大概率只是披着 e2e 外衣的 API 测试。

另一个常见误区是混淆 e2e 与 smoke test（冒烟测试）。很多团队把 e2e 当成“上线前快速过一遍主流程”的工具，只覆盖 3-5 条路径。这远远不够。e2e 的价值不在“快”，而在“全”。它应该覆盖：

• 核心用户旅程（如注册→登录→下单→支付→确认）；
• 关键异常路径（如支付失败后跳转退款页、网络中断时的 loading 状态、输入非法字符的提示）；
• 多端一致性（同一功能在 Chrome/Firefox/Safari/iOS/Android 上表现是否一致）；
• 第三方依赖场景（如调用微信 JS-SDK 分享、接入支付宝 SDK 支付、使用百度地图 API 定位）。

我坚持一个原则：e2e 用例数不应少于项目核心业务实体数的 3 倍。比如一个电商项目有 5 个核心实体（User、Product、Cart、Order、Payment），e2e 用例至少 15 个，且每个实体需覆盖正常流+异常流+边界流。这不是教条，而是因为——真实世界的用户，永远比我们想象的更会“乱点”。

3. 为 web、mobile、CLI 三类载体设计差异化的 e2e 架构

e2e 的本质是模拟用户，而用户与系统的交互方式，由载体决定。web 用户用鼠标和键盘，mobile 用户用触摸和手势，CLI 用户用命令行和 stdin/stdout。因此，没有银弹框架，只有适配载体的验证架构。强行用同一套工具覆盖三类场景，必然导致维护成本飙升、稳定性下降、反馈延迟拉长。

3.1 Web 项目的 e2e：选型不是比功能，而是比“抗干扰能力”

Web e2e 最大敌人不是代码复杂度，而是环境不确定性：浏览器版本碎片化、网络波动、CDN 缓存、第三方脚本注入、字体加载延迟、CSS 动画未完成……这些都会让cy.get('.btn').click()突然失败。

我对比过主流方案在真实项目中的表现：

工具	启动耗时	稳定性（失败率）	调试体验	适用场景
Cypress	2.1s	8.7%（需合理配置重试）	极佳（时间旅行、截图、视频）	中小型 web 应用，CI 环境可控
Playwright	3.4s	5.2%（原生支持多浏览器）	优秀（trace viewer、network inspector）	多浏览器兼容要求高、需测试 Safari/Edge
Selenium + WebDriverIO	6.8s	14.3%（依赖外部 driver）	一般（日志为主，截图需额外配置）	遗留系统、需深度定制 driver 行为

结论很明确：Playwright 是当前 web e2e 的事实标准。不是因为它功能最多，而是它解决了最痛的痛点——自动等待（auto-waiting）机制。它不依赖cy.wait(2000)这种脆弱的硬编码等待，而是基于 DOM 就绪、元素可见、元素可点击、网络请求完成等 12 个维度综合判断。例如：

// Playwright 自动等待：直到 button 可点击、文本出现、无 pending 请求 await page.getByRole('button', { name: 'Submit' }).click(); await expect(page.getByText('Order confirmed')).toBeVisible();

这段代码在 Cypress 里可能需要加cy.wait(1000)或cy.intercept()，而在 Playwright 中，它天然知道“Submit 按钮点击后，页面要加载新内容，网络请求要完成，新文本要渲染”，无需人工干预。

实操建议：

• 绝不使用page.waitForTimeout()：这是反模式。Playwright 提供page.waitForEvent()、page.waitForSelector()、page.waitForFunction()等精准等待，全部基于可观测状态。
• 用getByRole()代替getByTestId()：前者语义化更强（getByRole('button', {name: 'Login'})），且与无障碍标准对齐，即使 class 名变更也不影响。
• 为 CI 环境单独配置 viewport 和 geolocation：本地开发用1920x1080，CI 用1280x720（节省资源），并固定geolocation: {latitude: 39.9042, longitude: 116.4074}避免地图 API 因位置不同返回不同结果。

注意：Playwright 的trace功能是神器。每次失败自动生成.zip追踪文件，解压后用浏览器打开，能看到完整操作回放、网络请求瀑布图、JS 堆栈、DOM 快照——比翻 100 行日志高效 10 倍。务必在 CI 中开启：--trace=on。

3.2 Mobile Apps 的 e2e：真机 > 模拟器 > 云测平台

Mobile e2e 的核心矛盾是：模拟器太“干净”，真机太“脏”。模拟器里 App 启动秒开、网络 100Mbps、GPS 定位秒出；而真实用户手机可能内存只剩 200MB、WiFi 信号格只有 1 栏、GPS 在地下车库完全失锁。

我们曾为一款医疗影像 App 做 e2e，模拟器上所有用例 100% 通过，上线后用户投诉“打开 DICOM 查看器就闪退”。排查发现：模拟器默认分配 2GB 内存，而低端安卓机（如 Redmi Note 8）运行时仅剩 300MB，App 加载大图时 OOM。这个问题，只有真机才能暴露。

因此，Mobile e2e 架构必须分层：

• 第一层：真机集群（主力）
  采购 5-8 台主流机型（华为 Mate 50、iPhone 14、小米 13、vivo X90），刷入稳定版系统，安装 adb 调试工具，用 Appium 启动。关键配置：

  # 启动时强制限制内存，模拟低端机 adb shell setprop dalvik.vm.heapsize 512m # 关闭开发者选项中的“窗口动画缩放”，避免 e2e 等待超时 adb shell settings put global window_animation_scale 0.0

• 第二层：模拟器（快速验证）
  使用 Android Studio 自带模拟器或 iOS Simulator，仅用于开发阶段快速验证 UI 流程，不计入 CI 通过率。

• 第三层：云测平台（补充覆盖）
  如 Testin、阿里云移动测试，用于覆盖小众机型（如折叠屏、老年机），但仅做“冒烟”验证，不跑全量用例——云测网络不可控，失败率天然偏高。

Appium 是目前最成熟的 mobile e2e 工具，但它有个致命缺陷：XPath 定位极不稳定。//android.widget.Button[@text='Confirm']在不同系统版本下可能完全失效。我们的解决方案是：

• iOS 用 predicate string：'label == "Confirm" && visible == 1'
• Android 用 UI Automator：new UiSelector().text("Confirm").enabled(true)
• 所有定位器统一注入 accessibilityId：在开发阶段要求 RN/Flutter 工程师为关键元素添加testID（React Native）或semanticsLabel（Flutter），e2e 直接用driver.findElement(AppiumBy.accessibilityId("confirm_btn"))

这样，定位器不再依赖 DOM 结构或 text 内容，而是基于开发者主动声明的语义 ID，稳定性提升 70% 以上。

3.3 CLI 工具的 e2e：用“进程黑盒”思维替代“代码白盒”思维

CLI e2e 最容易被忽视，却恰恰是开源工具的生命线。用户不会看你源码里parseArgs()函数写得多优雅，只会看codex cli --model llama3 --prompt "hi"是否输出Hello!。

CLI e2e 的本质是：启动一个独立进程，向 stdin 写入输入，捕获 stdout/stderr 输出，断言退出码和输出内容。它不需要浏览器驱动，不需要 Appium server，只需要一个可靠的进程管理库。

我们为lm studio cli和zcode cli设计的 e2e 框架，核心就三行：

import { spawn } from 'child_process'; // 启动 CLI 进程 const proc = spawn('node', ['dist/cli.js', '--model', 'llama3', '--prompt', 'hi'], { cwd: path.join(__dirname, '..'), env: { ...process.env, NODE_ENV: 'test' } }); // 写入 stdin（如有需要） proc.stdin.write('yes\n'); // 断言 stdout let stdout = ''; proc.stdout.on('data', chunk => stdout += chunk.toString()); proc.on('close', (code) => { expect(code).toBe(0); expect(stdout).toContain('Hello!'); });

这套方案的优势在于：

• 零外部依赖：不依赖 Puppeteer、不依赖 Appium，纯 Node.js 原生 API；
• 精准复现用户场景：用户就是在终端里敲命令，e2e 就该用相同方式启动；
• 可调试性强：console.log(stdout)直接看到用户看到的内容，proc.stderr.on('data')捕获所有报错堆栈。

针对热搜词里高频出现的lm studio cli 启动模型时提示“model not found”问题，我们的 e2e 用例这样写：

it('should fail with clear error when model not found', async () => { const proc = spawn('node', ['dist/cli.js', '--model', 'nonexistent-model'], { cwd: path.join(__dirname, '..') }); let stderr = ''; proc.stderr.on('data', chunk => stderr += chunk.toString()); await new Promise(resolve => proc.on('close', resolve)); expect(proc.exitCode).toBe(1); expect(stderr).toContain('Error: Model "nonexistent-model" not found in models directory'); expect(stderr).toContain('Available models:'); });

这个用例不仅验证了错误码，还验证了错误信息是否对用户友好——这才是 CLI 工具 e2e 的核心价值：让用户少查文档，多靠直觉。

提示：CLI e2e 必须测试--help输出。90% 的 CLI 用户第一件事就是your-cli --help，如果 help 文本格式错乱、参数缺失、示例错误，e2e 就该失败。我们用execSync('your-cli --help', {encoding: 'utf8'})获取 help 文本，用正则校验关键参数是否存在。

4. e2e 执行环境的真实瓶颈：不是 CPU，而是 IO 和状态隔离

很多团队优化 e2e 的方向错了。他们花大力气升级 CI 服务器 CPU、增加并发数、用 Docker Compose 启动更多服务实例……结果发现，e2e 执行时间只缩短了 8%，失败率反而上升了 12%。

真相是：e2e 的最大瓶颈从来不是计算资源，而是 IO 延迟和状态污染。

4.1 IO 延迟：网络、磁盘、DNS 是隐形杀手

• 网络延迟：一个cy.visit('https://example.com')，背后是 DNS 查询（平均 50ms）、TCP 握手（100ms）、TLS 握手（150ms）、HTTP 请求（200ms）、HTML 解析（100ms）……总计 600ms+。如果测试站点部署在海外 CDN，延迟翻倍。
• 磁盘 IO：Playwright 默认每测试用例生成截图和 trace，100 个用例就是 10GB+ 临时文件，SSD 写入速度成为瓶颈。
• DNS 缓存缺失：CI 环境每次都是全新容器，DNS 缓存为空，每个域名首次解析都要 100ms+。

解决方案不是堆硬件，而是精准控制 IO：

• 本地代理拦截第三方请求：用playwright-core的routeAPI，将 Google Analytics、Facebook Pixel 等非核心请求直接route.fulfill({ status: 200 })，节省 300ms+。
• 预热 DNS 缓存：在测试开始前，执行nslookup example.com && nslookup api.example.com，让系统缓存 DNS 记录。
• 禁用截图，按需生成 trace：CI 中关闭screenshot: 'on'，只在失败时用--trace=on-failure生成 trace，磁盘占用降低 90%。

4.2 状态污染：数据库、缓存、本地存储是最大隐患

e2e 用例之间必须绝对隔离。A 用例创建的用户，不能被 B 用例读到；A 用例写入的 localStorage，不能影响 B 用例的登录状态。否则，用例顺序一变，结果就变。

我们曾遇到一个经典问题：test-login.spec.ts和test-payment.spec.ts单独运行都通过，合起来跑就失败。排查发现：test-login用例末尾执行了localStorage.clear()，但test-payment依赖localStorage.getItem('auth_token')，而 Playwright 默认复用浏览器上下文（browser context），导致localStorage被污染。

根治方案是：每个用例使用独立 browser context：

// playwright.config.ts export default defineConfig({ use: { // 每个 test 用例创建新 context，自动隔离 localStorage、cookies、indexedDB storageState: undefined, }, // 并发控制：避免同一浏览器实例被多个 test 共享 workers: 3, });

对于后端服务，我们采用“测试专用数据库 + 每次用例前清库”策略：

• 数据库连接字符串指向test_db_e2e_001、test_db_e2e_002……动态生成；
• 每个用例开始前，执行TRUNCATE TABLE users, orders, products CASCADE;；
• 用pg_dump导出最小必要 schema，CI 中用psql -f schema.sql快速重建。

这样，100 个用例可以并发跑，互不干扰，执行时间从 47 分钟压缩到 9.3 分钟。

注意：不要用DELETE FROM table，要用TRUNCATE。前者逐行删除触发 trigger，后者直接释放数据页，速度快 10 倍以上。

5. 一套可直接抄作业的最小可行 e2e 验证模板

说了这么多原理和架构，最后给你一份开箱即用的最小可行模板。它不追求大而全，只确保：能在 10 分钟内跑通、覆盖 web/moblie/CLI 三类载体、具备生产级稳定性、所有配置都有明确理由。

5.1 项目结构（精简到极致）

e2e/ ├── playwright.config.ts # Playwright 配置（web） ├── mobile.config.ts # Appium 配置（mobile） ├── cli.test.ts # CLI e2e 主文件 ├── fixtures/ │ ├── web/ # web 测试数据（JSON） │ │ └── user.json │ ├── mobile/ # mobile 测试数据 │ └── cli/ # CLI 测试数据（命令行参数组合） ├── tests/ │ ├── web/ # web 用例 │ │ └── login.spec.ts │ ├── mobile/ # mobile 用例 │ │ └── onboarding.spec.ts │ └── cli/ # CLI 用例 │ └── help.spec.ts └── utils/ ├── web.ts # web 工具函数（如 waitForNetworkIdle） ├── mobile.ts # mobile 工具函数（如 waitForToast） └── cli.ts # CLI 工具函数（如 spawnCli）

5.2 Playwright 配置（web）

// playwright.config.ts import { defineConfig, devices } from '@playwright/test'; export default defineConfig({ // 每个 test 用独立 browser context，彻底隔离状态 use: { baseURL: 'http://localhost:3000', headless: true, viewport: { width: 1280, height: 720 }, ignoreHTTPSErrors: true, // 自动等待策略：元素可见、可点击、无 pending 请求 waitForCondition: 'networkidle', }, // 并发控制：3 个 worker，避免资源争抢 workers: 3, // 全局 setup：启动本地 dev server webServer: { command: 'npm run dev', port: 3000, timeout: 120 * 1000, reuseExistingServer: !process.env.CI, }, // 失败时自动生成 trace，便于调试 reporter: [ ['list'], ['html', { outputFolder: 'e2e-report' }], ['blob', { outputDir: '.playwright-trace' }], ], });

5.3 CLI e2e 核心函数（cli.ts）

// utils/cli.ts import { spawn, SpawnOptions } from 'child_process'; import { promisify } from 'util'; import { exec as execCallback } from 'child_process'; const exec = promisify(execCallback); export interface CliResult { stdout: string; stderr: string; exitCode: number; } export async function runCli( args: string[], options: SpawnOptions = {} ): Promise<CliResult> { const proc = spawn('node', ['dist/cli.js', ...args], { cwd: process.cwd(), env: { ...process.env, NODE_ENV: 'test' }, ...options, }); let stdout = ''; let stderr = ''; proc.stdout.on('data', (chunk) => (stdout += chunk.toString())); proc.stderr.on('data', (chunk) => (stderr += chunk.toString())); return new Promise((resolve) => { proc.on('close', (code) => { resolve({ stdout, stderr, exitCode: code ?? -1 }); }); }); } // 便捷断言函数 export function expectCliResult(result: CliResult) { return { toExitCode: (code: number) => { if (result.exitCode !== code) { throw new Error( `Expected exit code ${code}, but got ${result.exitCode}. Stdout: ${result.stdout}. Stderr: ${result.stderr}` ); } }, toContain: (text: string) => { if (!result.stdout.includes(text) && !result.stderr.includes(text)) { throw new Error( `Expected stdout or stderr to contain "${text}", but got stdout: "${result.stdout}", stderr: "${result.stderr}"` ); } }, }; }

5.4 一个真实的 CLI e2e 用例（cli/help.spec.ts）

// tests/cli/help.spec.ts import { test, expect } from '@playwright/test'; import { runCli, expectCliResult } from '../../utils/cli'; test('cli --help should show all commands and options', async () => { const result = await runCli(['--help']); // 验证退出码为 0（help 不应报错） expectCliResult(result).toExitCode(0); // 验证关键命令存在 expectCliResult(result).toContain('Commands:'); expectCliResult(result).toContain(' start'); expectCliResult(result).toContain(' build'); expectCliResult(result).toContain(' serve'); // 验证关键选项存在 expectCliResult(result).toContain('--model'); expectCliResult(result).toContain('--prompt'); expectCliResult(result).toContain('--verbose'); // 验证示例用法正确 expectCliResult(result).toContain('codex cli --model llama3 --prompt "hello world"'); });

5.5 执行命令与 CI 集成

本地运行：

# 安装依赖 npm install -D @playwright/test # 运行所有 e2e npx playwright test # 只运行 CLI 用例 npx playwright test tests/cli/ # 生成 HTML 报告 npx playwright show-report e2e-report

GitHub Actions CI 配置（.github/workflows/e2e.yml）：

name: E2E Tests on: [pull_request] jobs: e2e: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm ci - run: npx playwright install chromium - run: npx playwright test --reporter=list env: CI: 'true'

这个模板的特点是：所有配置都有明确目的，没有一行是“为了配置而配置”。headless: true是为了 CI 环境兼容，workers: 3是基于实测的吞吐最优值，waitForCondition: 'networkidle'是为了应对真实网络波动，spawn('node', [...])是为了 100% 复现用户终端行为。

我在三个不同团队落地这套模板，平均将 e2e 稳定性从 72% 提升到 99.2%，单次全量执行时间从 42 分钟压缩到 8.7 分钟。最关键的是，开发人员开始主动写 e2e 用例——因为他们发现，写一个 CLI help 用例，比查文档写参数说明还快。

6. 我在实际项目中最常被问的三个问题

做完这套 e2e 体系，团队里问得最多的问题，往往不是技术细节，而是关于“值不值得投入”的根本性质疑。这里分享三个最高频问题，以及我基于血泪经验给出的答案。

Q1：e2e 执行太慢，开发等不及，要不要砍掉？
我的回答是：不是砍掉，而是重构执行策略。把 e2e 分成三层：

• 开发阶段：只跑当前修改模块相关的 3-5 个用例（如改了登录页，就只跑login.spec.ts），本地 10 秒内完成；
• PR 阶段：跑所有“核心旅程”用例（约 20 个），CI 中 2 分钟出结果；
• Nightly 阶段：跑全量用例（100+），生成周报，不阻塞发布。
  慢不是 e2e 的原罪，而是我们没设计好它的使用节奏。就像汽车不能只造发动机不配变速箱，e2e 也需要匹配不同场景的“档位”。

Q2：UI 经常改，e2e 用例维护成本太高，怎么办？
这其实是好事——说明产品在快速迭代。解决方案是：用业务语义替代技术 selector。

• 不写cy.get('.header-nav > ul > li:nth-child(2)')，而写cy.get('[data-testid="nav-products"]').click()；
• 不写page.locator('div:nth-child(3) > button')，而写page.getByRole('button', { name: 'Checkout' })；
• 开发时约定：所有可交互元素必须有>