不配.golangci.yml，golangci-lint基本等于没开——它默认只启用govet和errcheck，staticcheck、unused、revive等关键检查器全被关闭；必须将.golangci.yml置于go.mod同级目录并显式传参--config=.golangci.yml才生效。
不配 .golangci.yml，golangci-lint 基本等于没开——它默认只启用 govet 和 errcheck 两个基础检查器，staticcheck、unused、revive 这些真正能揪出逻辑错误和烂代码的全被关着。
为什么 golangci-lint run 没报错却查不出问题
常见现象是命令跑通、返回 success，但明显有未使用变量、弃用 API 或死循环却完全没提示。根本原因是：默认配置极简，大量高价值 linter 被禁用。
-
golangci-lint启动时不读任何配置文件，除非显式传参--config=.golangci.yml；CI 中尤其容易因工作目录错位导致漏读 - 即使你放了配置文件，若名字是
.golangci.yaml、golangci.yml或放在src/下而go.mod在上层，它直接无视 - 多 module 项目（如 monorepo）中，父目录的
.golangci.yml不会继承到子 module，每个 module 都得单独放一份
必须启用的 5 个 linter 及其不可替代性
不是“建议开启”，而是实际项目中暴露问题最多、误报率可控的最小有效集合：
-
govet：Go 官方静态检查，捕获printf参数类型错、结构体字段覆盖等底层错误 -
errcheck：强制处理error返回值，避免os.Open(...) // 忽略 error这类静默失败 -
staticcheck：唯一能报SA1019（调用已弃用函数）、SA4006（无限 for 循环）、SA9003（布尔表达式恒真）的 linter -
unused：发现未导出函数、无用 import、局部变量定义后从未读取——直接清理技术债务 -
revive：替代已归档的golint，支持自定义规则，比如禁止_ = foo()忽略 error
别碰 dupl（重复代码）和 lll（行长限制）——前者阈值难调、易把合理复用判成重复；后者纯属风格偏好，不该卡 CI。
IDE 插件不亮红灯？检查这三处路径配置
VS Code 或 GoLand 装了插件却没实时提示，大概率是路径链断了：
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 确认插件设置里勾选了「Use config file」且路径填的是
.golangci.yml（不是相对路径或空值） - IDE 启动时工作目录必须是含
go.mod的目录，否则它找不到配置文件或解析错 module path - 插件调用的
golangci-lint二进制版本要 ≥ v1.52.0；旧版对revive规则支持不全，部分告警压根不触发
验证方式：在 IDE 内打开一个含未使用变量的 .go 文件，终端手动执行 golangci-lint run --config=.golangci.yml --no-config ./path/to/file.go，如果终端能报错但 IDE 不标红，就是插件路径或缓存问题。
CI 中 golangci-lint 失效的典型原因
GitHub Actions / GitLab CI 里写好步骤却一直通过，往往因为：
- 没加
--config=.golangci.yml，容器环境默认找不到配置，退回到极简模式 - 运行命令用了
golangci-lint run ./...却没限定范围，扫描了vendor/或testdata/，触发超时或跳过检查 -
go.mod不在 CI 工作目录根路径下（例如项目结构为repo/backend/go.mod），但配置文件仍放在repo/，golangci-lint根本不认
最稳写法：golangci-lint run --config=.golangci.yml --timeout=3m --out-format=github-actions ./...，其中 ./... 显式指定待检包路径，避免隐式扫描整个 repo。
配置文件名、位置、显式传参这三点，任何一个出错，golangci-lint 就退化成半个工具。它不靠“安装即用”，而靠“配准才活”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
