14. CI 的质量门禁 1：Lint/格式化/静态分析（SAST）
把低成本问题尽量在最早阶段挡住。
本章目标
把“低成本错误”尽量挡在最前面：格式化/Lint/SAST 让问题更早暴露、更便宜修复。
你会掌握
Formatter 与 Lint 的职责边界、SAST 的定位与误报治理、以及如何分层落地质量门禁。
真实收益
减少评审摩擦与返工，让安全问题更早被发现；团队把精力从“抓低级错误”转向“讨论设计与风险”。
最痛苦的 bug 往往不是“难”，而是“蠢”：缩进乱、变量没用、空指针、SQL 注入、危险拼接……
这些问题如果在 PR 里才被发现，就会浪费评审时间；如果在生产才被发现，就会变成事故。
所以质量门禁的第一层，必须用自动化把“低成本错误”挡住——让人类把脑子用在更贵、更难、更需要判断的事情上。
这些问题如果在 PR 里才被发现，就会浪费评审时间；如果在生产才被发现，就会变成事故。
所以质量门禁的第一层，必须用自动化把“低成本错误”挡住——让人类把脑子用在更贵、更难、更需要判断的事情上。
1) 三个概念：Formatter / Lint / SAST 分别负责什么？
- Formatter（格式化）：统一代码风格（缩进、引号、换行）。目标是减少争论。
- Lint（代码规范/静态检查）：捕捉可疑代码与最佳实践（未使用变量、复杂度、潜在 bug）。目标是减少低级错误。
- SAST（静态应用安全测试）：从代码结构中发现安全风险（注入、XSS、路径遍历、危险反序列化）。目标是减少安全事故。
一句话区分：Formatter 管“长相”，Lint 管“行为习惯”，SAST 管“安全底线”。
它们组合在一起，才能既减少争论，又减少事故。
它们组合在一起，才能既减少争论，又减少事故。
2) 门禁前移：为什么要越早越好？
同一个问题，越晚发现越贵：
- 编辑器/提交前发现：几秒修复
- PR 里发现：打断评审，来回沟通
- 合并后发现：回滚/补丁/复盘，代价指数上升
图 1：门禁前移（动态）
把低成本错误尽量挡在最靠近开发者的地方：本地/预提交 → PR 门禁 → 合并后深度检查。
3) 规则资产化：把“人的经验”变成“机器的护栏”
成熟团队会把规则当作资产（像测试一样）：版本化、可评审、可回滚、可度量。
- 统一配置：同一种语言/框架尽量统一规则（避免“每个仓库一套”）。
- 分层执行：快规则进 PR 必过门禁；慢规则在 nightly/主干跑。
- 可解释：每条关键规则都要能解释“为什么存在”。
图 2：规则 → 门禁 → 反馈闭环（动态）
规则不是越多越好；关键是能否形成闭环：发现问题 → 抽象规则 → 自动化执行 → 度量误报与收益。
4) SAST：安全门禁如何既“有用”又“不扰民”？
SAST 的最大风险不是“漏报”，而是误报太多导致团队不再相信它。
要让 SAST 有用，通常需要：
- 优先高置信规则：先抓注入、命令执行、路径遍历等“硬伤”。
- 分级处理：高危阻断，低危提醒，逐步收紧。
- 结合上下文：把框架、模板引擎、过滤器纳入规则理解。
图 3：SAST 数据流（Source → Analyzer → Findings → Gate）（动态）
SAST 不是“跑一下工具”，而是一条数据链：输入、分析、产出、决策与治理。
5) 本章小结：质量门禁要像护栏一样“默认正确”
- Formatter/Lint/SAST 分工明确：长相/习惯/安全底线。
- 门禁要前移：把低成本错误尽量挡在本地与 PR。
- 规则要资产化：版本化、可评审、可度量、可持续调优。
- SAST 要可用：高置信优先、分级处理、误报治理。