五次采集，不迷信单次分数
页面自身、网络、服务器、硬件争用与浏览器都会引入波动。五次结果按数值排序后取中位数，能削弱单个离群点；但相同环境、相同页面和相同构建仍是前提。
PASS
门禁计算中
正在核对生产构建、预算、五次采集、证据与灰度数据。
等待判定
门禁输入台
任何输入变化都会使旧快照失效；调整完数据后重新保存证据。
01 · PR 身份与生产构建
门禁证据必须能回到同一 PR、同一 commit、同一路由和同一生产构建。开发服务器数据不能代替生产构建预算。
02 · 生产构建包体预算
三个预算单位都是 KB：全局客户端 JS、全局 CSS、目标路由首次加载包。既要防止“总量太大”，也要防止“本次 PR 退步太多”。
03 · LHCI 五次采集与中位数
固定运行 5 次并显式取中位数。一次极慢样本不会直接代表典型结果，但若多数样本一起变慢，中位数仍会触发门禁。
04 · 灰度 Field RUM p75
Lab 负责在合并前阻断确定性回归；Field p75 只在灰度后回答真实用户是否变慢。样本不足时保持灰度，不把“没有证据”误写成 PASS。
05 · 可审计证据清单
构建分析不止看“多了多少 KB”，还要追到“哪个模块经由哪条 import 链进入哪个客户端路由”，这样修复才有落点。
判定规则为什么这样设计
下面是把官方资料转换成团队可执行契约后的中文解释。
绝对预算与差异预算必须并存
绝对预算守住用户可接受上限，差异预算守住“这个 PR 不得明显退步”。只设绝对值会让小回归反复累积，只设差异值则可能容忍已经很慢的页面。
噪声是复核带，不是免死金牌
越界但仍落在允许噪声内时标记 WARN：重跑、核对环境并看趋势；超过预算加噪声才 BLOCK。若多个 commit 连续落在噪声带，也应收紧或调查，而不是长期忽略。
包体结果必须能解释来源
Next.js 的构建分析应该按路由、客户端与服务端边界拆开看，并保留静态报告用于 PR 前后对比。数字告诉你“变大了”，模块与 import 链才告诉你“为什么”。
Lab 与 Field 不是二选一
Lab 环境稳定、反馈快，适合 PR 门禁；Field p75 覆盖真实设备与网络，适合灰度决策。Lab 通过不等于真实用户必然通过，Field 样本不足也不等于没有问题。
证据要跟 commit 一起保存
至少保存生产构建信息、五份原始报告、中位数、预算配置、bundle 差异、引入链和灰度标签。否则事后无法证明某次 PASS 对应哪份代码与哪套环境。
预算判定账本
所有指标统一按“越低越好”计算；包体、Lab 中位数与 Field p75 分层展示。
统一门禁公式
回归量 = 当前值 − 基线；绝对超额 = 当前值 − 绝对上限；差异超额 = 回归量 − 差异上限。两项都 ≤ 0 为 PASS；任一项在 (0, 噪声] 内为 WARN；任一项 > 噪声为 BLOCK。
LHCI 五次运行分布
紫色柱是中位位置；切换聚合方式可以观察乐观值与悲观值如何扭曲门禁。
决策解释与发布阶梯
先过 Lab 才进入灰度；Field 不稳定时停止扩大，严重回归时回滚。
证据包
快照只保存在当前页面内，便于课堂演练；真实 CI 应上传到可追溯的构建产物或 LHCI 服务。
尚未保存本轮证据。
PROGRESSIVE PRACTICE · 12 LEVELS
递进挑战：把门禁从“会看”练到“会设计”
每个挑战会载入一个故障场景。修改上方数据，再回来验证；挑战之间会逐步叠加身份、包体、波动、证据与灰度判断。
选择一关并按目标调整控制台。