存量治理的基本思路
存量代码的 lint 治理一句话可以概括：老代码宽容，新代码严格。做法是把当前所有违规快照成基线文件，或只检查变更行、按目录逐步收紧，CI 只对新增违规失败，然后每个迭代顺手清理一小片存量。这样能立刻止住新问题，又不必停下来做不现实的全量清理。
基本信息
| 策略 | 新代码优先（Clean as You Code 思路） |
|---|---|
| 手段 | 基线文件 / 只检查变更行 / 分目录收紧 |
| 门禁口径 | 新增违规失败，存量不阻断构建 |
| 治理节奏 | 每个迭代顺手清一小片 |
| 观察指标 | 新增违规数与存量下降曲线 |
典型使用场景
- 老项目第一次接入 lint，不想被上万条历史告警淹没
- 多模块仓库按模块分批纳入检查范围
- 代码评审只要求本次改动不新增违规
- 季度目标：存量违规按固定比例下降
- 新人接手老模块时，先看清该模块已有的豁免清单
增量治理步骤
增量治理步骤
1. 全量扫描，把当前违规落盘为基线快照（记录工具版本与规则集）
2. CI 只对新增违规失败，存量默认放过
3. 每个迭代顺手清一小片，同时删掉基线里对应条目
4. 规则集升级时先按警告试跑，稳定后再纳入门禁
5. 定期输出存量下降曲线，避免治理变成一次性运动三种手段的取舍
| 手段 | 适用场景 | 注意 |
|---|---|---|
| 基线文件 | 违规量大、历史包袱重 | 清理后要同步更新基线 |
| 只检查变更行 | 改动集中在少量文件 | 未改动文件的存量保持不动 |
| 分目录收紧 | 模块边界清晰 | 不同目录可设不同严格度 |
一次性清零存量的项目多半因工作量失控而放弃：先冻结新增，再按迭代小步清理，比强行全量更可靠。
基线不是免责声明：只冻结不修正，存量代码会变成没人敢动的禁区。给存量治理设定可见的下降目标与时间点，才不至于停在冻结那一步。