CI 绿了不等于能发版

常年红着的检查会让人对红灯麻木，CI 本身也只覆盖一部分。防止拿 CI 状态代替发版前的全量验证

一句话规则

发版前在本地跑完全量验证，CI 只是下限

发生了什么

有一个 CI 检查，因为 CI 的环境和本地不一样，一直是红的。看久了，我们都默认它是“环境问题”，合并照合，版本照发。

后来那个版本出了问题。回头看，最要命的不是这一个检查，而是从它常年变红开始，CI 的状态就不再有人当真了：红着的那一项是不是正好在报真问题，没人知道。

两层原因。

第一，“环境问题”是一个标签，不是诊断。CI 和本地、生产之间的环境差异，恰恰是 CI 应该暴露的东西。一旦接受某个红灯是常态，红色就成了噪音，真正的失败也会混在里面被放过。

第二，CI 本来就只覆盖一部分。为了快，常见做法是按路径过滤、跳过慢测试和不稳定的测试、复用缓存。CI 全绿说明的是“这部分没坏”，不是“这个版本能发”。

红灯不能常驻：要么限期修好，要么明确隔离，在 CI 配置里把它改成非必需，同时开 Issue 写清负责人和恢复条件（见临时方案要写明撤销条件）。不接受“心里知道它是红的”。

红了先看日志，不靠猜：

gh pr checks                        # 当前分支 PR 的全部检查
gh run view <run-id> --log-failed   # 只看失败步骤的日志

发版前本地跑全量验证四件套：单测、全量测试（含集成或 e2e）、类型检查、lint。串成一条命令，任何一步失败就停（脚本名按项目改）：

bun test && bun run test:e2e && bunx tsc --noEmit && bun run lint

关键检查在分支保护里设为 required，红着就合不进去。