噪声治理的目标
linter 噪声治理的目标是让每条告警都值得看：误报通过调整参数或向上游提报解决，过于苛刻的规则降级为警告或调整阈值，工具升级引入的新告警逐类评估，而不是整体无视。一旦团队学会习惯性跳过提示，真实缺陷会跟着噪声一起漏掉。
基本信息
| 噪声来源 | 误报 / 规则过于苛刻 / 工具升级引入新告警 |
|---|---|
| 处理路径 | 调参 / 精确禁用 / 降级 / 向上游提报 |
| 禁用要求 | 写明原因、范围与复核时间 |
| 评估时机 | 工具版本或规则集更新时 |
| 验收标准 | 每条告警都能说出处理动作 |
典型使用场景
- 新规则上线前先跑一遍历史代码，评估噪声量与整改成本
- 误报集中在某类代码模式时，先看能否用参数收窄
- 同一类告警被团队反复无视时，降级或关掉并记录原因
- 升级 linter 前在分支上做全量对比，摸清新增告警
- 定期清理禁用清单，删掉已经失效的条目
治理动作示例
治理动作示例
误报 → 调整参数，或精确禁用（带注释与责任人）
太苛刻 → 降级为警告或调整阈值，保留可见性
新版本告警 → 评估后纳入治理计划，或明确搁置并写明理由
失效规则 → 直接删除，避免禁用清单不断膨胀常见噪声与对策
| 噪声类型 | 典型表现 | 对策 |
|---|---|---|
| 误报 | 告警指向的代码实际没有问题 | 收窄参数，或精确禁用并注明依据 |
| 规则苛刻 | 大量风格争议挤占评审注意力 | 降级级别或调整阈值 |
| 版本升级 | 同一份代码突然新增一批告警 | 先分支预演，再分批处理 |
验收标准很朴素：团队不再需要习惯性无视，看到告警会去判断，而不是跳过。若某类告警长期没人看，它就应该被降级、关闭或改成自动修复。
禁用要留痕：写清原因、涉及范围和复核时间，否则后人既不敢删也不敢改，清单只增不减，工具的可信度随之下降。