别一上来就全开：聊聊用 golangci-lint 增量检查、低摩擦落地代码规范的实践

最近在给组里的老项目推 golangci-lint，一开全量直接喷出 1600+ 个 warning，当场把大伙干沉默了。全量修是不可能的，硬卡 CI 绝对会被提刀问候。

我们目前落地的姿势比较直给：

1. 增量兜底：CI 门禁只跑 --new-from-rev=origin/main，新代码严格卡死，旧代码暂不追究。
2. 规则分级：先开并发、资源泄露和明显 bug 相关的（比如 govet、staticcheck、bodyclose），像什么命名规范、注释格式这类偏玄学的样式规则先靠边站，减少推进阻力。
3. CI 提速：把缓存搞好，本地压测过几次，跑满核打热缓存后整个 lint 耗时能从 42s 压到 3.5s 左右，至少别让跑 CI 变成摸鱼借口。

不过现在痛点也很明显：有时候同学改了老文件的一行代码，diff 判定波及到了旧上下文，直接报一堆陈年老账出来，体验贼差。

想问问老哥们在团队里都是怎么搞平滑过渡的？是直接走 baseline 机制硬磨，还是自研脚本做精细化 diff 过滤？有没有摩擦力更小的解法？