golangci-lint 不适用于老旧项目开箱即用，需先禁用高噪声检查器（如unused、deadcode）、跳过生成代码目录（vendor/pb/gen等）、延长超时至10m，并按历史问题精准启用govet、errcheck等2–3个核心linter，CI设为警告不中断，本地pre-commit仅跑fast模式。
老旧项目直接跑 golangci-lint run 会爆炸
不是工具不行，是默认配置和遗留代码严重错配。你一执行，unused 会把所有未导出但实际被反射调用的函数标红，errcheck 会狂报几百个 io.Copy(...) 没处理 error，staticcheck 在 protobuf 生成代码里报 SA1019（deprecated），而这些根本不是你能改的。
- 先禁用高噪声 linter：
disable: ["unused", "deadcode", "structcheck", "defers", "exportloopref"] - 必须跳过非手写代码目录：
skip-dirs: ["vendor", "pb", "gen", "mocks", "third_party"] - 把超时设宽一点：
run: timeout: 10m，老项目依赖多、文件杂，扫描慢是常态 - 别信
golangci-lint init生成的配置——它默认启用全部 linter，等于给你扔一颗手雷
怎么判断哪些 linter 真正值得开
看历史 bug 和人工 review 频发点。比如团队过去三个月在 PR 评论里反复指出 “忘记 close io.ReadCloser”，那就只开 errcheck；如果总有人写 if x > 0 && x > 1 这种冗余逻辑，就单独启用 staticcheck 的 SA4006 规则，而不是整个 staticcheck。
- 初期只开 2–3 个：推荐
govet（查printf类型错）、gosimple（基础简化建议）、ineffassign（无效赋值） - 每个 linter 单独测试：
golangci-lint run --enable=errcheck ./pkg/http，确认路径和效果再写进配置 - 用
issues.max-same-issues: 3限制重复提示数，避免同一类问题刷屏掩盖真正风险
CI 中如何避免“一票否决”式阻断
遗留项目不可能一夜达标，CI 里直接 fail-on-issue: true 会导致所有人绕过检查或删掉 lint 步骤。
- CI 阶段只 warn 不 fail：
issues.exit-code: 0，输出报告但不中断构建 - 把结果导出为 SARIF 格式，接入 GitHub/GitLab 的 code scanning，让问题出现在 PR diff 里，而不是构建日志末尾
- 加一条脚本统计新增问题：
golangci-lint run --new-from-rev=origin/main | wc -l，只对“本次提交引入的新问题”做拦截
开发者本地怎么不被干扰又逐步适应
强迫所有人改完所有 warning 才能提交，只会催生 //nolint 泛滥。重点是让 lint 成为“可感知但不打断”的存在。
立即学习“go语言免费学习笔记（深入）”；
- pre-commit 只跑 fast linters：
golangci-lint run --fast --enable=govet,goimports ./...，控制在 2 秒内完成 - IDE 里关掉
unused和staticcheck的实时标记，只留govet和格式类（gofmt,goimports） - 在
.golangci.yml里给每个启用的 linter 加注释说明业务动因，比如：# 启用 errcheck：近半年 3 起线上连接泄漏均源于此
平滑接入的关键不在“全量开启”，而在“精准识别哪几行代码改了会让线上更稳”。遗留系统里最危险的从来不是风格问题，而是那些没人敢动、但每次发布都悄悄出问题的角落——把 lint 的探针插到那里，比扫完整个项目更有价值。
