golangci-lint 是 Go 生态唯一应安装配置的静态检查主入口，它并行调度 staticcheck、govet、errcheck 等 linter，统一管理配置与输出；golint 已归档禁用，手动运行独立 linter 成本高且易出错。
golangci-lint 是当前 Go 生态中事实标准的静态检查聚合工具，不是“几款之一”，而是你应该唯一安装并配置的主入口。它本身不直接分析代码，而是并行调度多个底层 linter（比如 staticcheck、govet、errcheck），统一管理配置、路径排除和输出格式。
其他工具要么已弃用，要么只在特定环节有不可替代性——它们不该被平行列为“可选方案”，而应理解成 golangci-lint 的组成部分或补充。
为什么别单独装 golint 或手动跑一堆独立 linter
官方早在 2021 年就归档了 golint，它规则主观、噪音大、不维护；社区也明确建议禁用。你看到的“golint”报错，基本都来自旧配置残留。手动维护 staticcheck、errcheck、gosimple 等二进制的版本、PATH、调用参数、忽略逻辑，成本远高于用 golangci-lint 统一纳管。
-
golangci-lint内置对govet的调用，无需额外写go vet -unmarshal ./ - 它的
--fix能自动修正gofmt、goimport类问题，独立工具做不到这点 - CI 中一条
golangci-lint run --timeout=3m就覆盖全部语义+风格+错误处理检查
staticcheck 必须启用，但不能脱离 golangci-lint 单独用
staticcheck 是目前最成熟的 Go 语义级分析器，能发现死代码、无效类型断言、过时 API 调用（SA1019）、无用 return（SA9003）等。但它依赖模块上下文，必须在 go.mod 所在目录运行，且首次执行慢（构建类型图谱）。单独装它容易踩两个坑：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 运行时报
no Go files in directory→ 八成是因为没在模块根目录，或GO111MODULE=off - 配错
-checks导致大面积误报（比如在模板层开SA1006）→ 应通过golangci-lint的linters-settings.staticcheck.checks控制
govet 不是可选项，是基础防线
go vet 是 Go SDK 自带、零依赖、秒级响应的检查器，专抓“合法但大概率写错了”的模式。它不查未处理 error、不查死代码，但能立刻暴露：fmt.Printf("%s", 42)、结构体字段小写却带 json:"name"、sync.WaitGroup 传值不传址、json.Unmarshal 传非指针。这些全是 runtime panic 前兆。
- 默认只开几个检查项，必须显式启用关键项：在
.golangci.yml里配linters-settings.govet段，加check-shadowing: true、unmarshal: true等 - CI 中不必单独跑
go vet，golangci-lint默认已包含；但本地改完核心逻辑后，建议补一句go vet -tags=dev ./快速过一遍
真正需要你花精力的，不是“选哪个工具”，而是：
- 在项目根目录运行
golangci-lint init生成基础.golangci.yml - 删除配置里默认启用的
golint - 显式启用
errcheck（捕获忽略 error）、staticcheck（语义深度检查）、govet（基础语义防线）、unused（未使用符号） - 把
run.timeout设为5m，避免 CI 中因缓存未热导致超时
复杂点在于：不同 linter 对同一段代码可能给出冲突建议（比如 staticcheck 认为某函数该删，unused 却因测试文件引用而保留）；这时得靠 issues.exclude-rules 精确过滤，而不是关掉整个检查器。
