识别隐藏性能退化需建立带基线的自动化流水线：lighthouse ci 通过多次采样、历史对比、业务阈值断言及 ci 集成，将偶然检测变为持续守门，精准定位 lcp、cls 等指标恶化并驱动团队响应。
识别隐藏的性能退化（Hidden Performance Regressions）不能靠肉眼或偶尔跑一次 Lighthouse，关键在于建立可重复、可对比、带基线的自动化流水线。Lighthouse CI 的核心价值，正是把“偶然检测”变成“持续守门人”——它不只告诉你当前得分多少，而是明确回答：“这次比上次变差了吗？差在哪？是否超出容忍范围？”
用历史基线代替单次快照
单次 Lighthouse 报告没有上下文，容易忽略缓慢累积的退化。Lighthouse CI 通过保存每次构建的完整指标（如 LCP、CLS、TBT），自动计算趋势变化。
- 必须启用 upload 配置（哪怕先用
temporary-public-storage），否则无法跨构建对比 - 确保每次收集都面向相同 URL 和相同环境（如统一用
startServerCommand: 'npm run preview'启动静态服务） - 在
lighthouserc.js中开启collect.numberOfRuns: 3，用多次采样降低随机波动影响
设置有业务意义的断言阈值
“分数下降 5 分”不是退化，“LCP 超过 2.8 秒且连续两次恶化”才是需要拦截的隐藏问题。
- 避免使用笼统的
preset: 'lighthouse:recommended'，它只做基础合规检查，不防回归 - 针对核心页面（如首页、商品页、登录页），单独配置
assertions，例如：'largest-contentful-paint': ['error', {maxNumericValue: 2800}],'cumulative-layout-shift': ['warn', {maxNumericValue: 0.1}], - 对关键交互路径（如点击搜索按钮后首屏渲染），可在 CI 中额外运行定向测试，而非仅依赖首页 URL
在 Jenkins 或 GitHub Actions 中嵌入回归判断逻辑
CI 工具本身不理解“性能退化”，需靠 Lighthouse CI 的 exit code 和报告结构来驱动决策。
- Lighthouse CI 在
assert失败时默认返回非零 exit code（如 1），Jenkins 构建会自动失败；GitHub Actions 中可用if: ${{ failure() }}触发通知 - 不要只看总分：在 Jenkins 构建日志中搜索
Regression detected in关键字，它会明确指出哪个指标、在哪个 URL 上出现恶化 - 配合
lhci healthcheck命令定期验证服务连通性与采集稳定性，排除因环境抖动导致的误报
把报告变成可协作的信号源
退化被识别出来只是第一步，团队能否快速响应，取决于信息是否直达、可追溯、可归因。
- 启用
upload.target: 'lhci-server'自建服务，获得带 commit diff、PR 关联、图表趋势的 Web 仪表盘 - 在 PR 描述中自动插入 Lighthouse CI 摘要（GitHub Actions 可用
stefanoeb/lighthouse-ci-action实现） - 对反复触发同一指标警告的 PR，添加标签（如
perf/lcp-regression），推动专项优化
