golangci-lint 不生效主因是路径或版本不匹配：需确保在含 go.mod 的模块根目录运行，版本 ≥v1.52，并使用项目根目录下的 .golangci.yml 配置；多模块需各自配置或统一指定。
golangci-lint 不生效？先确认 go.mod 路径和 golangci-lint 版本对齐
很多情况下 golangci-lint 看似运行了但没报错，其实是它没找到 go.mod，于是退化成 GOPATH 模式（只检查当前目录下 .go 文件，不识别 module 依赖和配置）。golangci-lint v1.50+ 强制要求项目根目录存在 go.mod，否则直接报错 no go files to analyze 或静默跳过子模块。
- 运行前先
pwd确认在 module 根目录（即含go.mod的目录） - 用
golangci-lint --version检查是否 ≥ v1.52（推荐），旧版本对 Go 1.21+ 的泛型或嵌入接口支持不全 - 如果项目是多 module 仓库（如 monorepo），每个子 module 都得有独立的
.golangci.yml或统一用--config指定路径
怎么让 golangci-lint 读取自定义配置？不是所有字段都支持环境变量或命令行覆盖
golangci-lint 只认特定位置的配置文件，默认按顺序查找：.golangci.yml → .golangci.yaml → .golangci.toml → .golangci.json，且只读取项目根目录下的那个。命令行参数（如 --enable）只能开启 linter，不能改其行为；真正要调参数（比如 revive 的规则阈值、errcheck 忽略的函数），必须写进配置文件。
- 别把配置放
~/.golangci.yml—— 它不会自动加载用户级配置 -
linters-settings下的字段名严格区分大小写，例如revive的配置块必须叫revive，写成Revive或REVIVE会被忽略 - 想临时禁用某条规则？用
run.skip-dirs或issues.exclude-rules，而不是删 linter —— 后者可能掩盖真实问题
golangci-lint run 太慢？80% 的性能损耗来自 linter 加载和重复解析
默认 golangci-lint run 会启用全部 50+ linter（即使你只关心 vet 和 staticcheck），每个都做 AST 解析，导致 CPU 和内存飙升。尤其在 CI 中，反复 clone + go mod download 后直接跑全量检查，经常超时。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
golangci-lint run --fast跳过耗时 linter（如goconst,gocyclo），适合 pre-commit - CI 中固定启用集合：
--enable=vet,staticcheck,errcheck,unused，避免隐式依赖默认列表 - 加
--skip-dirs vendor（即使用了 Go modules，vendor/仍可能被扫描） - 注意：
--fast不影响golint（已弃用）或gosimple的启用状态，它们得单独关
为什么 golangci-lint 报的错和 IDE（GoLand / VS Code）不一致？
IDE 插件通常只跑部分 linter（如 govet, staticcheck），且用的是本地缓存的 AST，而 CLI 默认每次重新 parse 所有文件。更关键的是：IDE 往往忽略 .golangci.yml 里的 issues.exclude-rules 或 linters-settings，只认自己内置的开关。
立即学习“go语言免费学习笔记（深入）”；
- VS Code 的
golang.go扩展默认不集成golangci-lint，需手动配置"go.lintTool": "golangci-lint"并指定"go.lintFlags": ["--config=.golangci.yml"] - GoLand 在 Settings → Other Settings → Go Linters 里选 “Use golangci-lint config file”，否则它只读自己的 UI 设置
- 最稳的做法：CI 里只信任
golangci-lint run -v输出，本地开发用--out-format=json导出给 IDE 解析，别依赖图形界面的实时提示
.golangci.yml。容易被忽略的是——golangci-lint 不会帮你推断 module 边界，也不会继承父目录配置，每个子 module 都得自己管。 
