golangci-lint 默认仅启用约10个linter，staticcheck（sa1019）等关键检查未开启；需正确配置.golangci.yml（位置、命名、缩进）、锁定go和工具版本、使用--new-from-rev实现增量检查，并显式启用高价值linter。

golangci-lint run 为什么没报错，但别人 PR 里一堆 SA1019？

不是工具失效，是默认只启用约 10 个 linter（比如 govet、errcheck），staticcheck（负责 SA1019）、unused、goconst 这些关键检查根本没开。

• .golangci.yml 必须存在且放在 go.mod 所在目录，不是 Git 根目录
• 文件名必须是 .golangci.yml（不是 .yaml，大小写敏感）
• 缩进只能用空格，Tab 会导致整个配置被忽略
• 本地运行时显式传参：golangci-lint run --config=.golangci.yml，别依赖自动发现

GitHub Actions 中 golangci-lint-action 失败但本地正常？

大概率是环境不一致，不是代码问题。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• GO111MODULE：CI 默认可能为 off，加 env: GO111MODULE: on 统一行为
• Go 版本：staticcheck 在 Go 1.21+ 对泛型支持稳定，CI 中用 actions/setup-go@v6 固定版本（如 1.21.10）
• golangci-lint 版本：CI 脚本里禁用 latest，用具体版本号安装或通过 version: v1.57.2 指定
• 缓存干扰：临时加 skip-cache: true 排查，确认是否因旧缓存导致解析异常

如何让 CI 只检查 PR 新增/修改的代码？

全量扫描既慢又掩盖真正的问题，--new-from-rev 是核心方案，但要注意上下文。

• 本地调试可用：golangci-lint run --new-from-rev=HEAD~1（要求工作区干净）
• CI 中不能硬写 HEAD~1——合并时 base 分支可能已更新，应由 GitHub 提供基线 commit：--new-from-rev=${{ github.event.pull_request.base.sha }}
• 配合 only-new-issues: true 参数，才能让 GitHub Annotations 只标出本次变更引入的问题
• 如果项目用 monorepo，记得加 working-directory: path/to/module，否则跨模块路径解析会失败

要不要用 --enable-all？

不要。它会启用 50+ linter，其中不少已废弃或误报严重（比如老版 lll 对中文注释疯狂报错）。

• 优先显式启用几个高价值 linter：unused、staticcheck、goconst、gosimple
• 禁用冗余检查：disable: ["scopelint", "maligned"]（后者在 Go 1.20+ 已被移除）
• 用 golangci-lint help linters 查每个 linter 的作用和稳定性，别只看名字启用
• CI 失败后先看报错 linter 名称，再决定是修复代码、加 //nolint:xxx，还是调整配置

配置文件位置、版本锁定、增量检查范围——这三处稍有偏差，自动化 lint 就会形同虚设。实际落地时，与其堆参数，不如先跑通一个最小可验证配置。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！