直接回答：金字塔从下到上：大量静态检查与单元测试（纯函数、工具、复杂组件逻辑，毫秒级）、适量组件测试（Testing Library 渲染单组件断言行为）、少量 E2E（Playwright 跑真实浏览器全链路）。E2E 只覆盖“挂了就是事故”的核心链路——登录注册、核心交易/发布流程、关键页面的可达性，十几条量级；不该覆盖边界组合与业务分支（那是单测的职责），也不该追求覆盖率数字。
展开解析：E2E 的最大成本是脆弱性，对抗手段：选择器用 data-testid 而非 class 或文案（重构免疫）；等待用 web-first 断言（expect(locator).toBeVisible() 自带重试）而非 sleep；每个用例独立造数（API 准备数据而非 UI 操作前置）， teardown 清理；并行执行加 trace/video 失败留档，CI 失败重试要配 quarantine 名单管理（反复 flaky 的用例移出主套件限期修复，不许拖垮信任）。组件测试是性价比甜点：jsdom 环境比浏览器快两个量级，又能测交互行为，表单校验、权限渲染、状态流转都放这层。契约测试（MSW mock API 或用 OpenAPI 生成）解决前后端联调漂移。度量上别盯覆盖率，盯“逃逸缺陷”——线上 bug 里本可被测试拦截的比例，驱动测试投入的再平衡。冒烟 E2E 还可以复用为发布后的线上巡检（生产只读用例），一份用例两处价值。
追问方向：flaky 用例的根因分类与治理？视觉回归测试应该放在哪一层？
（约 480 字）