2024 年 11 月，项目接入了 golangci-lint 和流水线代码审查。第一反应并不轻松：旧代码一次冒出大量问题，部分规则与现状冲突，流水线也因为 CGO 和构建环境反复调整。

工具接入并不等于习惯形成。

我们踩过的三个阶段

1. 一次性清零

试图在一个提交里消灭全部告警，结果是改动巨大，真正有风险的问题被淹没在命名和格式变化里。

2. 为了通过而通过

遇到难处理的规则就全局关闭。流水线绿了，但工具逐渐只剩装饰作用。

3. 只约束增量

保留一份可解释的规则集，旧债单独治理，新代码不再继续增加同类问题。审查机器人把意见贴到变更附近，开发者能在上下文还新鲜时修正。

真正有效的是第三种。

规则也需要被审查

我不认为 linter 永远正确。复杂度阈值、注释比例、错误处理方式，都需要结合项目判断。规则的价值不在于替团队思考，而在于稳定地处理那些已经达成共识、却很容易遗忘的事情。

机器负责重复提醒，人负责决定什么值得成为规则。

当一个团队开始主动讨论“为什么启用这条规则”，代码规范才从个人偏好变成共同语言。工具最好的状态不是警察，而是把好习惯变成默认路径。