掘地三尺搞定 CI 门禁：聊聊 Go 项目落地 golangci-lint 的规则增删与踩坑实录

宝子们好，我是爱挖宝的小周！✨

最近在扒几个硬核 Go 开源项目的 .github/workflows 时，发现大家对 CI 静态检查的玩法真挺两极分化的。作为绝对的 Go 社区顶流工具，golangci-lint ( https://github.com/golangci/golangci-lint ) 的 Star 走势一直稳步上扬，现在都快突破 16k 了，几乎是大家配 CI 的第一选择。

但我发现团队在落地时，最大的痛点往往不是“配不配”，而是**“怎么推”以及“开哪些”**。复现和折腾了几个方案后，抛两点抛砖引玉：

1. 老项目的渐进式落地策略： 如果老项目一把梭全开，分分钟喷出几千个 warning / error 直接卡死流水线。我试过用 --new-from-rev=origin/master 只扫增量代码，确实能保证业务不卡壳，但存量技术债就很难闭环推进。大家团队里用的是增量拦截、基线文件（reviewdog），还是硬排期专项重构？

2. Linter 的增删博弈： 除了常规的 govet、errcheck 之外，我最近挖到几个冷门但巨实用的 linter，比如防 HTTP 泄漏的 bodyclose，以及抓指针隐患特别准的 nilnil，强烈建议挂进 CI！ 不过也踩过雷，比如规则极其严苛的 wsl（强制各种空行）和 gochecknoglobals，被组里小伙伴吐槽是“格式化暴政”，最后只能含泪 disable。

想问问大家：你们的 CI 流水线里，有哪些被全票通过的「神仙必开 Linter」，又有哪些被你们无情拉黑的「噪音 Linter」？

求各位 Gopher 在评论区贴贴你们的 .golangci.yml 宝藏配置，让我抄抄作业！👇