go vet不能代替staticcheck，因其仅检查语法合法但语义可疑的低阶问题（如printf参数错配、重复struct标签），不覆盖并发安全、资源泄漏、API弃用等高危场景；staticcheck则能识别for range变量复用、time.After滥用、未处理error等线上崩溃主因，且必须通过golangci-lint显式启用才能生效。
go vet 为什么不能代替 staticcheck
go vet 是 Go 官方自带的轻量级守门员，只查“合法但大概率写错”的模式，比如 fmt.Printf("%d", "hello")、json:"name" json:"name" 这类语法合法但语义可疑的代码。它不检查 err 是否被处理、time.After 在循环里滥用、for range 中 goroutine 捕获变量复用等问题——这些正是线上崩溃的高发原因。
常见错误现象：go vet ./ 零报错，CI 构建通过，但服务上线后出现空指针或 goroutine 泄漏。这是因为 vet 根本不覆盖资源管理、并发安全、API 弃用等维度。
- 它默认不分析
database/sql.Rows是否调用了.Close() - 不识别
strings.Replace(s, "a", "b", 1)实际想全替换却漏传-1 - 跳过
json.Unmarshal后忽略error的 SA1006 高危项
golangci-lint 必须显式启用 staticcheck
很多人以为装了 golangci-lint 就自动有了 staticcheck，其实不是。它默认禁用所有第三方 linter，包括 staticcheck。不手动打开，等于没装。
在 .golangci.yml 中必须写明：
立即学习“go语言免费学习笔记（深入）”；
enable: - staticcheck disable: - golint - maligned - scopelint
否则你会看到大量 unused、errcheck 噪声，却漏掉真正致命的 SA1021（time.After 循环泄漏）或 SA1019（调用已弃用 API）。
-
golangci-lint run默认只跑内置 linter，性能快但深度不够 - CI 中建议加
--fast --issues-exit-code=1，让构建真正失败而非仅输出警告 - 对测试目录豁免资源检查：
run: --skip-dirs="testdata|_test"，避免 mock 场景误报
本地开发最容易忽略的两个动作
IDE 自动提示不可信：很多编辑器只对当前文件运行 go vet，跨包调用、接口实现、嵌入结构体字段标签等场景完全漏检。
必须手动做两件事：
- 在项目根目录定期执行
go vet -vettool=$(which go tool vet) ./，显式指定vettool路径，避免某些 CI 环境因 PATH 不一致导致静默失败 - 每次提交前运行
golangci-lint run --timeout=5m，尤其注意检查select中default分支是否永远不执行、sync.WaitGroup是否传值而非指针
staticcheck 的 SA 类规则（如 SA1006、SA1021）才是真正卡住线上质量的硬门槛，它们不会出现在 IDE 提示里，也不会被 go build 拦住，只能靠主动、显式、带配置的静态扫描触发。
