golangci-lint 默认不检查 go.mod 依赖一致性，因其仅做代码静态分析、不解析模块语义；需配合 go mod verify、go list 或专用工具补全。
golangci-lint 为什么默认不检查 go.mod 依赖一致性
它压根不负责依赖管理，只做代码层面的静态检查。你运行 golangci-lint run 后没报 require 版本冲突或 indirect 脏包问题，不是它漏了，是它根本没读 go.mod 的语义——它只解析 AST 和 token 流。
常见错误现象：改完 go.mod 升级了某个库，CI 里却没发现新版本引入的已废弃函数调用（比如 http.CloseNotifier），结果跑测试才爆 panic。
- 真要捕获这类问题，得靠
go list -m all+go vet -vettool=...或专用工具如govulncheck、go-mod-upgrade -
golangci-lint的govetlinter 会间接触发部分go vet检查，但不包括模块图校验 - 如果硬要在 CI 里补这一环，建议在
golangci-lint run前加一步：go mod verify && go mod graph | head -20快速兜底
如何让 golangci-lint 正确识别 GOOS/GOARCH 条件编译
默认配置下，golangci-lint 只按 host 环境（比如你本地 macOS）解析代码，遇到 // +build linux 或 runtime.GOOS == "windows" 就可能跳过检查，导致跨平台 bug 漏检。
使用场景：写了一个只在 darwin 下启用的信号处理逻辑，但 linter 在 Linux 机器上跑，直接忽略该文件，后续 Windows 构建时才发现未定义标识符。
立即学习“go语言免费学习笔记（深入）”；
- 必须显式传参：
golangci-lint run --build-tags="linux darwin windows"，把所有目标平台 tag 都列全 - 若用
//go:build新语法（Go 1.17+），需确保golangci-lint版本 ≥ v1.50.0，旧版会静默跳过 - CI 中建议统一用环境变量驱动：
GOOS=linux GOARCH=arm64 golangci-lint run --build-tags="linux"，避免 tag 冗余爆炸
.golangci.yml 里禁用 linter 的真实影响
禁用一个 linter（比如关掉 errcheck）不只是少几条 warning，而是会让整条检查链断掉——某些 linter 依赖其他 linter 的中间结果，比如 goconst 需要 go/analysis 框架就绪，而关掉底层 typecheck 会导致它直接退出。
性能影响常被低估：禁用 unused 看似省事，但它顺带干掉了未使用变量/函数的 AST 标记，导致 gosimple 和 staticcheck 的部分规则失效（比如未使用的 channel send）。
- 别用
disable-all: true+ 单独启用几个，改用enable:显式声明白名单，更可控 - 想临时跳过某行？用
//nolint:govet，别全局关掉govet——后者会同时关掉printf、atomic等关键子检查 - 检查是否真生效：加
--print-resources-usage参数，看各 linter 的 CPU/内存占比，异常低说明被意外跳过
CI 中 golangci-lint 报 context canceled 错误怎么定位
这不是代码问题，是 linter 进程被外部强制终止了。最常见于超时设置不合理，尤其在大型 monorepo 里，golangci-lint 默认 1 分钟超时，但首次缓存构建可能卡在 go list 或 go/types 加载阶段。
错误信息长这样：ERRO Running error: context canceled，后面往往没具体文件名，让人以为是并发 bug。
- 先加
--timeout=5m看是否消失；若仍出现，再加--verbose，重点看最后几行输出的是哪个 package 卡住 - 检查是否启用了
fast: false（默认为 true），设成 false 会逐包串行分析，慢但稳定；CI 中建议保持 true，靠增加 timeout 解决 - 真正容易被忽略的是 Go proxy 设置：如果
GOPROXY指向不稳定的私有源，golangci-lint在 resolve deps 时会 hang 住直到 context cancel，务必在 CI 前验证go list -m all能秒出
