golangci-lint 安装后 go mod tidy 报错找不到包
这是最常见的一击即溃场景：刚装好 golangci-lint，一跑就提示 cannot find module providing package github.com/xxx/yyy。根本原因不是 lint 工具本身坏了，而是它默认在 module mode 下执行，会严格按 go.mod 里的依赖解析 —— 如果你本地没 go mod download 过，或者用了 replace 指向未初始化的本地路径，它就直接失败。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先确保项目根目录下能正常运行
go build或go list -m all，否则 lint 不会比编译器更宽容 - 如果依赖里有
replace指向本地模块，确认那个路径存在且含有效go.mod - 临时绕过（仅调试）：加
--no-config参数跳过配置加载，看是否是 .golangci.yml 里启用了某插件触发了额外 import
.golangci.yml 中启用 govet 却不报错
govet 是 Go 自带的检查器，但 golangci-lint 默认只启用部分子检查项（比如 printf、shadow），不是全开。你写了明显有问题的格式化字符串，却没提示，大概率是它被禁用了，或者被 run.skip-dirs 排除了当前目录。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 查
.golangci.yml里有没有linters-settings.govet.checks配置；没配就等于只用默认白名单，不会检查atomic或bools等项 - 加一行
checks: ["all"]显式启用全部子检查（注意：Go 1.21+ 的govet支持all，旧版本需列具体名） - 确认
run.skip-dirs没把当前包路径写进去了，尤其注意正则匹配是否误伤
CI 中 golangci-lint run 超时或内存爆掉
默认并发数是 CPU 核心数，大项目（尤其含大量 test 文件或嵌套 vendor）容易卡住或 OOM。这不是 bug，是它真在并行 parse 所有 .go 文件 —— 包括 _test.go 和第三方代码。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 加
--concurrency=2限制并发，比默认值更稳；CI 环境通常资源受限，4 核机器别硬上 8 并发 - 用
--skip-dirs="vendor,third_party"明确跳过非主代码区域（注意路径分隔符用逗号，不是空格） - 避免在 CI 中用
--fast：它跳过一些耗时检查（如unused），但掩盖真实问题，不如调低并发来得实在
vscode-go 插件不识别 .golangci.yml 配置
VS Code 的 Go 插件（golang.go）默认用内置的 gopls 提供实时 lint，而 gopls 只读 gopls.settings，完全不认 .golangci.yml。你改了 yml，编辑器里没反应，不是配置错了，是压根没走那条路。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 想让 VS Code 实时显示
golangci-lint结果，必须关掉gopls的内置 lint，改用外部命令：在 settings.json 里设"go.lintTool": "golangci-lint"，并确保"go.lintFlags"包含["--fast"]（不然保存即全量扫描太慢） - 确认
golangci-lint在 shell PATH 中可用；Windows 用户常卡在这步，WSL 路径和 CMD 不互通 - 别指望
gopls和golangci-lint报错完全一致 —— 它们用不同 AST 解析器，gopls更重语义，golangci-lint更重模式匹配
配置真正生效的临界点，往往卡在「谁在调用谁」和「谁在读哪个配置文件」—— 多半时候不是工具不行，是你以为它在读的文件，它根本没打开。
