需结合Lighthouse CI与Performance API构建性能回归防线：前者建立跨版本合成基线，后者捕获真实用户时序数据，CI中联动断言并驱动团队响应。
单纯依赖 Lighthouse CI 或只用 Performance API 都难以构建可靠的性能回归防线。前者提供跨版本可比的合成监控指标，后者提供真实用户场景下的细粒度时序数据。两者结合，才能既守住基线、又感知真实体验变化。
用 Lighthouse CI 建立可对比的合成基线
Lighthouse CI 不是跑一次报告就完事，关键在于建立带历史上下文的基准：
- 必须启用 upload 配置（哪怕先用
temporary-public-storage），否则无法跨构建比对趋势 - 固定采集环境：统一用
startServerCommand: 'npm run preview'启动服务，确保每次测试 URL、端口、静态资源路径一致 - 开启多次采样：
collect.numberOfRuns: 3–5，降低 Chrome 渲染抖动带来的偶然误差 - 按设备与网络分层配置，例如移动端设为
emulatedFormFactor: 'mobile'+throttling: { rttMs: 150, throughputKbps: 1638.4 }
用 Performance API 补充真实用户行为信号
Lighthouse 是实验室模拟，Performance API 能捕获真实加载链路中的关键耗时。可在页面初始化阶段主动上报核心指标：
- 监听
navigation和paint类型的performance.getEntriesByType()，提取first-contentful-paint、largest-contentful-paint、domContentLoadedEventEnd等时间戳 - 计算业务相关耗时，例如“从点击搜索按钮到首屏渲染完成”的自定义标记：
performance.mark('search_start')→performance.mark('search_rendered')→performance.measure(...) - 将结果通过
navigator.sendBeacon或轻量上报 SDK 发送到监控后端，打上 commit hash、环境标签（staging/prod）、用户设备类型
在 CI 中联动判断回归
不要让两个系统各自为政。把 Performance API 的真实数据作为 Lighthouse CI 断言的补充依据：
- 在 CI 流程中，先运行 Lighthouse CI 收集合成指标（LCP、CLS、TBT），再启动一个轻量 Puppeteer 脚本，访问同一 URL 并注入 Performance API 采集逻辑，导出 JSON 结果
- 编写自定义断言脚本，例如：若 Lighthouse 报告 LCP 为 2600ms，而真实用户样本中 P95 LCP > 3000ms 且同比上升 15%，则触发警告
- GitHub Actions 或 Jenkins 中，用
if: ${{ steps.lhci.outputs.exitCode != 0 || steps.perf-check.outputs.failed == 'true' }}统一控制构建失败逻辑
让报告驱动团队响应
检测出退化只是起点，信息要能直达、可归因、可回溯：
- 启用
upload.target: 'lhci-server'自建仪表盘，关联 PR、commit diff 和 Performance API 上报图表 - 在 PR 评论中自动插入双维度摘要：Lighthouse 指标变化 + 关键 Performance 时间点波动（如 FCP ↑12%、INP ↑28ms）
- 对连续两次出现同指标恶化（如 LCP 在三个相邻 PR 中均超 2.8s），自动 @ 相关模块负责人并创建 Issue
