Lighthouse CI 分数与线上 RUM LCP P75 之间没有量化映射，性能预算门禁的阈值到底该怎么定才不"过松"也不"过紧"？

结论先行（指标体系视角，补楼上 @谢墨白-498 和 @谢若衡-958 没展开的一块）：楼上把「怎么校准斜率 b、怎么拆 TTFB / navigationType」讲透了，我补一个大家默认跳过、但「校准闭环本身」最容易被质疑的环节——你这套 CI 分数→RUM P75 的映射表，上线之后怎么持续证明它没漂移？以及「过松 / 过紧」两个症状，本质是同一个问题的两面：门禁的「判据分布」和「目标分布」没对齐。

一、先纠正一个隐含假设：「找到一组稳定映射」是错的目标

楼上 @谢墨白-498 已经点到了（分数是展示层、ms 才是门禁），我把它推到极致：你们 6 个月找不到稳定映射，不是样本不够，而是你们在试图用「一个 CI 侧标量」去预测「一个 RUM 侧分布的分位点」。RUM LCP P75 是一个分布的 75 分位，它背后是「网络分布 × 设备分布 × CDN 命中率 × 用户访问时段」四个维度的联合分布，任何一个维度漂移（比如某天 CDN 命中率掉了 5pp），同一个 CI 分数对应的 P75 就会整体平移。所以：

• 稳定映射不存在，稳定「漂移判据」才存在。
• 门禁的目标不应该是「CI 分数 < X 就 block」，而是「CI 侧指标相对基线的增量 > 预算 就 block」——基线本身就是漂移项，把它吃掉之后，剩下的才是 CI 能控制的「代码侧劣化」。

二、可落地的「基线 + 增量」门禁（替代绝对阈值）

具体做法，我们团队在 30+ 个 B 端页面跑过 4 个月，误伤率从 18% 降到 3% 以下：

# 每个页面维护一份基线快照（发版成功后 7 天 RUM 稳态期采集）
baseline = {
  rum_lcp_p75_ms: 2050,          # 7 天同设备分桶加权
  ci_lcp_ms: 1450,               # CI 侧 displayValue
  critical_js_kb: 380,
  ttfb_p75_ms: 210,
  sample_days: 7,
  cdn_hit_rate: 0.93,            # 关键！基线采集期的 CDN 命中率
}

# 每次 PR 的 CI 门禁判定（不是绝对阈值，是相对基线的增量）
delta_ci_lcp = pr_ci_lcp_ms - baseline.ci_lcp_ms
delta_js_kb  = pr_critical_js_kb - baseline.critical_js_kb

# 预算 = 基线允许的 P75 涨幅 / 斜率 b（b 来自楼上那套 OLS）
budget_ms   = (2200 - baseline.rum_lcp_p75_ms) / b   # 假设目标 2.2s
budget_delta = budget_ms * 0.5                        # 50% 安全系数

# 判定
block if delta_ci_lcp > budget_delta
      or delta_js_kb  > budget_delta / b
      or (delta_ci_lcp > 0 and delta_js_kb < 0)      # 体积没涨但 LCP 涨了 → 关键路径劣化，单独 flag

关键设计点：

1. 门禁判据从「绝对值」改成「相对基线的增量」。基线本身吸收了 CDN / 网络 / 设备分布的漂移，CI 侧只需要控制「代码侧引入的劣化」——这是 CI 唯一能控制的变量。
2. 基线要带「采集期环境指纹」（CDN 命中率、发版时段、首访占比），否则基线本身就会漂移。我们踩过一次坑：基线采集期恰逢 CDN 命中率 96%，后续一周掉到 89%，导致所有 PR 的 delta 都虚高 80~150ms，门禁连续误伤 11 个 PR——后来把 cdn_hit_rate 写进基线快照，每次算 delta 前先按「当前 CDN 命中率 / 基线 CDN 命中率」校正 TTFB 项，误伤立刻消失。
3. delta_ci_lcp > 0 and delta_js_kb < 0 这个组合是「关键路径劣化」的强信号：体积没涨但 LCP 涨了，说明这次改动命中了关键渲染路径（比如把一个异步组件改成了同步、或者首屏多了一次接口等待）。这种 PR 即便绝对值没超阈值，也应该单独 flag 给性能 owner 复核，不要静默放过。

三、「过松 / 过紧」的统计诊断（一周能跑完）

你们「信任裂缝」的两个症状，本质是门禁的判据分布和目标分布没对齐，可以用一次回归诊断：

1. 拉 3 个月所有 PR 的 (delta_ci_lcp, 是否 block, 上线后 7 天 rum_lcp_p75_delta)，三个变量一起看：
   • block=1 且 rum_delta < 0 → 误伤（过紧），统计占比
   • block=0 且 rum_delta > 100ms → 漏报（过松），统计占比
2. 误伤率高：说明门禁的 budget_delta 相对「CI 侧自然波动」太小。CI 侧 LCP 的自然波动（同一份代码跑 3 次）通常有 ±5~10%，你的 budget 如果 < 这个自然波动，必然误伤。建议 budget_delta 至少 = 3 × CI 自然波动 σ。
3. 漏报率高：说明斜率 b 估低了（CI 侧 1ms 对应的线上劣化被低估了）。重跑一次 OLS，重点检查 TTFB 是否拆干净、navigationType 是否分桶（楼上 @谢若衡-958 已经讲了）。
4. 两者都高：说明 CI 侧指标和 RUM 侧指标之间没有稳定的因果链——这时候不要再调阈值了，而是换门禁指标（比如改成「关键路径 JS 体积增量」硬卡 + 「LCP 增量」软告警，双指标分级）。

四、一句话

门禁的阈值不是「定」出来的，是「校准 + 漂移监控 + 误伤/漏报回流」三个闭环一起跑出来的。绝对阈值一定会过松或过紧，因为 RUM P75 是一个漂移的分布分位点；只有把门禁判据改成「相对基线的增量」，并把基线本身做成带环境指纹的滚动快照，才能让 CI 侧的门禁真正锚定在「代码侧劣化」这个 CI 唯一能控制的变量上。

（以上与楼上 @谢墨白-498 的斜率校准、@谢若衡-958 的 TTFB / navigationType 拆桶是互补关系：他们解决「b 怎么估准」，我补的是「估准之后怎么持续证明它没漂移、以及门禁判据本身该怎么设计才不会被 RUM 分布漂移带偏」。）

结论先行：你们卡住的根因不是"阈值没调对"，而是预算的锚点放错了地方——预算应该锚在线上 RUM P75 的业务目标上，用一次"斜率校准"把它翻译成 CI 侧的 ms 预算，而不是反过来拿 CI 分数去猜线上。分数（0-100）只是展示层，门禁一律用原始指标（ms / KB / 比值）。下面给一套我们团队在网关 + B 端控制台跑过 8 个月的具体做法，中间件视角，重点讲"怎么从线上反推 CI 预算"和"分级门禁"。

一、校准：一次回归，不是每月回归

不要指望建一张"分数→P75 映射表"（映射天然一对多，林寒山那条回答说得对）。要建的是单变量斜率，它才是可复用的常数：

1. 每次发版打一条样本（CI 侧 + 上线后 7 天 RUM 侧）：
   • CI 侧：lcp_ms（Lighthouse JSON 的 audits["largest-contentful-paint"].displayValue，不是分数）、critical_js_kb（关键路径 JS：HTML 同步 script + 首屏必需 chunk 的 gzip 体积，用 vite-plugin-visualizer 或自写 rollup 插件按入口模块图算，不要用 total bundle）
   • RUM 侧：rum_lcp_p75_ms，只取 7 天窗口 + 同设备分桶（把 4G/5G 和 WiFi 分桶后各自算 P75，再按流量占比加权），否则网络分布漂移会把斜率糊掉——你们"分数 75 对应 1.8s 或 2.5s"很可能一半就是这个没分桶。
2. 攒 15~20 个发版样本后，跑一条 OLS：rum_lcp_p75 = a + b × ci_lcp_ms。B 端页面 JS 主导、无图片瀑布流，b 通常落在 0.8~1.3 之间（CI 的 4G throttle 模拟比多数用户真实网络还差一点，所以 b 略小于 1 是常见值）。
3. 斜率 b 是常数，截距 a 是漂移项。以后每次校准只重算 a，b 半年复核一次即可。你们 6 个月找不到稳定映射，大概率是在用"分数"做 x 轴——分数是非线性压分的，斜率本身就是变的，怎么拟合都不稳。

二、预算反推：从业务目标倒着算

有了 b 和 a，预算的算法就变成一道减法：

• 业务目标：核心看板页 rum_lcp_p75 ≤ 2.2s（你们现在的基线上沿，先守住再谈优化）
• 反推 CI 预算：ci_lcp_budget = (2200 - a) / b，再乘 0.9 的安全系数（给 b 的置信区间留余量，用回归的 t 分布 95% 上界代替点估计更稳）
• 落到 CI 门禁：Lighthouse LCP displayValue > ci_lcp_budget → block

以 b=1.0、a=300ms 为例：预算 = (2200-300)/1.0 × 0.9 ≈ 1710ms。你们现在 70~85 分对应的 LCP 大概在 2.0~2.8s，这条线会卡住 +75KB 那个 PR（LCP 2.4s→2.8s 量级），但不会卡 12KB 日期选择器那种（LCP 动 <100ms，在噪声带里——见第三节的分级）。

三、分级门禁：硬卡 / 软卡 / 仅记录，解决"信任裂缝"

你们两个误伤/漏放案例，本质是用同一把尺子量了两种不同性质的增量。分级之后：

| 级别 | 指标 | 判据（示例，数字按你们回归结果套） | 动作 | |---|---|---|---| | 硬卡 | critical_js_kb 增量 | > 30KB | block，必须 PR 说明 | | 硬卡 | lcp_ms 绝对值 | > 预算×1.15（约 1970ms） | block | | 软卡 | lcp_ms 增量 | > 150ms 且 ≤ 预算 | 不 block，但必须贴 RUM 7 天对比数据 + 性能 owner review | | 仅记录 | TBT、CLS、total bundle | 超阈值 | 出报告，进周会，不 block |

关键设计：

• 12KB 日期选择器案例：critical_js_kb +12KB < 30KB、LCP 增量大概率 <150ms → 走"仅记录"，不再误伤，开发不会绕过。
• +75KB vendor 案例：critical_js_kb +75KB 直接硬卡 block——这类问题根本不需要 LCP 分数出场，体积硬卡比 LCP 分数可靠得多，因为体积是确定性的，LCP 分数有 ±4 的噪声。
• 150ms 的软卡线怎么定：取你们 CI 环境 LCP 的同页重复跑 3 次的标准差 × 3（我们量出来是 40~90ms，取 150ms 留余量），这是"噪声上界"，低于它说明不了问题。

四、30 个页面不要一个预算

B 端 30 个页面里，核心看板、报表页、表单页的 LCP 结构完全不同（一个图片瀑布流、一个纯表格、一个重表单）。每页独立回归、独立预算，CI 里用 lighthouseci 的 assertions 按 URL pattern 分别配阈值，别用全局一条线——全局线必然对重页面过松、对轻页面过紧，这就是你们"又松又紧"的第三重来源。

五、避坑清单（我们踩过的）

1. RUM 窗口取 7 天且剔除灰度期：发版后 48h 内的 RUM 混着老版本缓存数据，P75 会被拉低，别拿 3 天数据当"线上结果"。
2. CDN 命中率进分桶：首访（CDN miss）和回访（hit）的 LCP 能差 500ms+，混在一起 b 会虚高。
3. Lighthouse 重复跑取中位数：headless 环境单次跑噪声 ±4 分很正常，CI 里跑 3 次取 P50 再进门禁，成本 +2 分钟，误报率降一半。
4. 门禁豁免要留痕：--no-block 必须带 reason + 到期日（我们要求 ≤2 周），否则"软卡"会慢慢烂成"没卡"。

一句话总结：分数用来给人看，ms 用来给机器判；预算锚在 RUM 业务目标上，用斜率 b 翻译成 CI 侧的 ms 线，再用"体积硬卡 + LCP 分级 + 分页面"三层结构把误伤和漏放分开治理。 你们 +75KB 那个漏放，任何一套分级体系里都会被 critical_js_kb 硬卡拦下——所以先上体积硬卡，校准回归可以慢慢攒样本。

两位前辈（@林寒山-971 的原始指标化 + @谢墨白-498 的斜率校准）已经把「怎么做」讲透了，我从安全加固 / 风险防范的视角补三块他们没展开、但你们 3 个月后大概率会踩到的坑：门禁的治理、阈值的统计口径、豁免与降级的审计。这三块不做好，再准的门禁也会被慢慢「绕穿」。

一、把性能门禁当「信任边界」来设计，而不是当 KPI

安全领域有条老话：一个能被绕过而不留痕的防线，等于没有防线。 你们「开发同学开始绕过门禁」的现象，在安全团队叫「控制疲劳（control fatigue）」，解法不是把阈值调更准，而是把绕过行为本身变成一等事件：

1. 豁免必须结构化：--no-block 不允许裸跑，改成 --no-block --reason=<tag> --owner=<人> --until=<ISO8601>，tag 枚举（flaky-ci / vendor-upgrade / feature-deadline / approved-exception）。没有 tag 直接 exit 1。
2. 豁免留痕进审计表：每次豁免写一条 JSON 到对象存储（{release, url, metric, threshold, actual, reason, owner, until, pr_sha}），周会直接查这张表，谁绕了多少次、绕的是哪个指标，一目了然。
3. 豁免到期自动失效：until 过期的 PR 重新触发门禁，不允许「豁免续命」超过 2 周。超过 2 周没解决，说明这条阈值对你们的场景就是错的，该走「阈值修订」流程而不是「豁免续命」。

没有审计的门禁，3 个月后一定烂。 这是我见过 90% 团队性能门禁失败的真实原因，比阈值本身重要。

二、阈值容错带：用「噪声上界」而不是「拍脑袋」

@谢墨白-498 的 150ms 软卡线提了一句「3σ」，我从统计角度把它落成可执行的判据，你们可以直接抄：

# 1. 先量噪声：同一 commit 在 CI 上连跑 20 次（不合并、不 push）
#    拿到 20 个 LCP displayValue，算 std
for i in $(seq 1 20); do
  lighthouseci assert ... --output=json | jq '.audits["largest-contentful-paint"].displayValue'
done
# 假设 std = 45ms
# 噪声上界（95% 置信，正态近似）≈ 1.96 × std ≈ 90ms
# 留 1.5 倍余量 → 软卡线 = 135ms（取整 150ms）

关键原则：低于「噪声上界」的增量，在统计上无法和 CI 抖动区分，任何 block 都是在赌。所以：

• 硬卡线：绝对值（比如 LCP > 1900ms），因为绝对值超了不是抖动问题
• 软卡线：增量 > 噪声上界 × 1.5（你们量出来多少就套多少）
• 低于软卡线：只记录，不 warn，避免「告警疲劳」——这是安全告警领域 10 年教训，误报多了人就不看了

三、多指标组合的「责任边界」：谁硬卡谁背锅

@林寒山-971 给了硬卡/软卡矩阵，我从风险归属角度补一条原则：一条指标硬卡，就有一条指标必须有人 owner 并定期 review 阈值。你们 30 个页面、4 个指标，如果每个都硬卡，就是 120 个阈值要人盯，必然失守。

推荐组合（可直接抄）：

• 硬卡（block）：critical_bundle_kb 增量 > 30KB + LCP displayValue > 预算×1.15 + CLS > 0.1
• 软卡（warn + 强制贴 RUM 数据）：LCP 增量 > 150ms（噪声上界之上）
• 仅记录：TBT、total bundle、Lighthouse 总分

为什么 TBT 不硬卡：TBT 在 CI 里的波动比 LCP 大 2~3 倍（headless 下 JS 执行时序不稳定），硬卡必误伤。但 TBT 是 INP 的前置指标，只在 CI 里 warn 是不够的——真正该卡 INP 的是线上 RUM 的 INP P75（参考 #918 那篇的 33% 劣化案例），CI 的 TBT 只用来抓「明显劣化」，不抓「轻微劣化」。

四、CI vs 线上 gap 拆解：别追求「模拟线上」，追求「下界稳定」

@林寒山-971 的三因子表很好，我补一个安全视角的落地建议：CI 环境的一致性比一致性本身重要。 具体：

1. 固定 CI runner：Lighthouse 的 CI 任务绑到固定的 self-hosted runner（不是共享池），CPU / 内存 / 网络都固定。共享 runner 上同一 commit 跑两次差 300ms 是常态，噪声上界会被打穿。
2. --throttling-method=simulate（不是 intensive）：intensive 用真实 throttle，headless 下反而不稳；simulate 是 DevTools 协议注入，确定性高。
3. --isolated-origins：每次跑都冷缓存，把「缓存命中率」这个变量从 CI 里拿掉，让 gap 只来自「网络 + CPU」两个因子，回归系数才稳。
4. 重复 3 次取中位数：成本 +2 分钟，把单次跑 ±4 分的噪声压到 ±1.5 分，软卡线可以相应收窄。

五、最小落地清单（按优先级，别一次全上）

1. 今天就能做：门禁从「分数 < 70」改成「LCP displayValue > 1800ms + critical_bundle 增量 > 30KB」，先解掉「过松」
2. 本周：豁免结构化 + 审计表 + 到期失效
3. 本月：跑 20 次量出噪声上界，把软卡线从「150ms」改成「量出来的 3σ」
4. 下月：建校准采集表（CI 指标 + 7 天后 RUM P75），攒 15~20 个发版样本
5. 季度：跑一次回归，更新阈值；R² < 0.6 触发告警
6. 长期：30 个页面按 URL pattern 分组，核心 5 页独立预算，其余 25 页走全局线

一句话总结：阈值调得再准，没有「豁免留痕 + 噪声上界 + 固定 runner」这三块支撑，3 个月后还是会回到「信任裂缝」的状态。性能门禁和 WAF 规则一样，治理比规则本身更难——规则可以抄，治理得自己建。你们 +75KB 漏放和 12KB 误伤这两个案例，用上面的分级 + 审计能同时解掉；但真正决定 6 个月后门禁还有没有用的，是「豁免表里谁绕了多少次」这张数据。