前端灰度放量（5%→20%）的「继续/回滚」判定怎么做：LCP 差分、JS 错误率、样本量与观察窗口有没有可复用的量化阈值方案？

背景

我负责一个 B 端 SaaS 前端（React 18 + Vite 5，约 20 个中后台页面），DAU 约 3.5 万，核心页日均 PV 约 8~12 万。发版流程是：CI 过了（Lighthouse CI LCP < 2.5s、bundle 增量 < 50KB）→ 灰度 5% 观察 → 20% → 100%。但「5% 观察期怎么算通过」这件事，我们现在靠的是人肉盯大盘 + 主观判断：看个半天没红字就放量。这明显不靠谱，想把它变成一套可执行的量化门禁。

现象（想解决的痛点）

1. 5% 灰度下信号太弱：5% 流量就算某个路由白屏，大盘错误率只动 0.05 个点，肉眼根本看不出来——和后端那篇「2% 灰度看 48 小时一切正常，全量后 30 分钟被工单打穿」（id=1620）说的「大盘指标在灰度下几乎不会报警」是同一个坑，只是发生在前端侧。
2. RUM 样本稀疏：5% × 3.5 万 DAU ≈ 1750 个会话/天，摊到 20 个页面后，很多次级页面一天只有几十条 LCP 样本——分位数（P75 LCP）在这种样本量下波动非常大，我拿 P75 做门禁怕被噪声打穿。
3. 判定窗口拍脑袋：现在「观察多久」没有共识，有人说 30 分钟够（覆盖一个工作日的早高峰），有人说要看满 4 小时跨一个业务波峰，还有人直接看 24 小时——三个说法都有道理，没有量化依据。
4. 没有对照组：我们的灰度是「按 user_id 尾号分桶」，理论上可以拿 95% 存量当对照组，但目前 RUM 上报里没有带灰度桶标记，导致根本做不了「灰度组 vs 对照组同口径差分」——这也是我最大的卡点之一。

已尝试的排查与结果

• 拉了最近 3 次发版的 RUM 数据做对比：P75 LCP 在发版前后波动 ±15%，但分不清是代码变更还是自然波动（时段、网络、机型分布都在变）；
• 试过「JS 错误率 > 0.5% 就回滚」的粗规则，结果一次发版因为一个存量的第三方 SDK 报错（非本次引入）误触发，白白回滚了——说明绝对阈值不可用，必须做差分；
• 社区里 #1431（前端性能预算进 CI）和 #569（灰度观察窗口谁拍板）讨论过 CI 预算和发布流程，但都是发布前的门禁和流程分工，没有覆盖「灰度中如何量化判定继续放量」这一段。

期望得到的答案形态

希望回答者能给出一套可直接落地的量化方案，至少覆盖：

1. 指标清单与口径：前端灰度判定该盯哪几个指标（LCP P75？JS 错误率？CLS？API 失败率？白屏率？），每个指标的采集口径（RUM 还是合成拨测、按页面还是按路由、session 还是 PV 为单位）；
2. 差分 vs 绝对值：灰度组 vs 对照组的差分怎么算（相对差？绝对差？置信区间？），样本量 < 100 的次级页面怎么处理（合并路由？只卡核心页？）；
3. 阈值怎么定：比如「灰度组 P75 LCP 相对对照组劣化 > X%，且 95% CI 下界 > 基线，持续 N 分钟」这种形式的规则，X 和 N 你们团队定的是多少、依据是什么；
4. 观察窗口的量化依据：5% → 20% 之间观察多久，怎么和 DAU / 业务波峰对齐（比如「至少覆盖 X 个会话数」而不是「至少 X 分钟」）；
5. 误判防护：存量报错、第三方 SDK 噪声、灰度桶本身不均衡（比如尾号分桶恰好把某个大客户划进灰度组）这些坑，你们是怎么防的。

如果有真实的灰度护栏配置（PromQL/Grafana 表达式、RUM 查询语句、或 CI 脚本片段）能贴出来就更好了——我这种喜欢抄配置的人，光讲原则没用，要能直接跑。

引用参考

• id=1620《2% 灰度看 48 小时「一切正常」，全量后 30 分钟被工单打穿》：后端侧的灰度护栏思路，我直接想抄到前端；
• id=1431《前端性能预算到底该不该硬卡 CI》：CI 侧预算的讨论，但灰度中段的判定没覆盖；
• id=569《前端发布后验证：灰度观察窗口、核心指标与「谁拍板全量」》：流程分工讨论，缺量化阈值。