R3.04.3budget checked in the build pipeline设计
预算需在构建流程中被检查
别名: CI 里查预算 · 合入前的体积门槛 · performance budget in CI
概念解释
写在文档里的上限，如果每次改动不自动跑、不能在流水线上给出超 / 未超，对合入就没有牙齿。预算要进构建流程：打包之后比体积、在预览环境跑实验室档案、把结果挂在拉取请求上，越界则失败或升成必须处理的警告。靠人在发版前想起打开一份表格，等于没有检查。
检查的位置是管道，不是个人电脑上的一次性审计。本地机器的数字既不稳定，也不会在别人改动时再跑一遍。
机制
构建流水线每次改动都在相对固定的环境里跑，人不会。体积、请求数、实验室时延一旦变成管道步骤，超预算就和测试失败、类型错误一样有一个阻塞点。没有这一步，上限只在有人记得时存在，而记得发生在功能已经合入、再撤代价变高之后。
本地检查还会说谎：开发开了代理、用了空缓存、关了一半功能旗标。管道用同一套安装和同一份构建命令，数字才和将要发出去的那份产物对应。检查还必须看得见：拉取请求上的体积对比、失败日志里的越界项，让「超了」成为讨论的输入，而不是发版后的惊讶。
边界
还没有产品管道的设计原型，谈不上进构建，先不要假装有检查。热修、事故通道可以明文跳过，但跳过必须留下越界记录和补跑时间，静默跳过等于拆掉牙齿。只统计打包体积、从不在接近真实的预览里跑的检查，会漏掉请求瀑布和第三方脚本；体积门槛仍有用，只不是完整检查。原生应用的包体可能在另一条流水线（商店打包），网页管道里的步骤管不到，要接到那一条上，而不是在网页 CI 里空转。完全离线、无构建步骤的静态手工发布，需要另一套发布前脚本，不能因为「没有 CI」就省略数字对比。
怎么落地
- 把每条预算接成管道步骤：脚本体积、请求数、或实验室档案上的时间；默认失败，不要只发一条可以忽略的评论。
- 拉取请求展示与主分支的对比；越界必须有人认领处理动作后才能合入。
- 允许跳过的通道（热修）要留越界记录和下一次补跑，禁止无记录的
--skip。 - 验证：在分支里故意加入一份明显超标的资源，看管道是否失败或发出必须处理的越界。管道全绿、资源已经进包，就是检查没进构建。再关掉本地网络再打包，若只有这时才看出体积问题，说明平时靠的是人而不是管道。