go vet 是基础但不足，staticcheck 才是守门员；二者需在 CI 显式运行并配置 golangci-lint 精确启用，配合人工审查关键错误处理与资源释放。
go vet 必须跑，但只靠它远远不够
go vet 是 Golang 项目静态检查的地基——它自带、快（500ms 内扫完）、不依赖模块、不报风格问题，专查“合法但大概率写错”的代码。比如 fmt.Printf("%d", "hello")、小写字段加了 json:"name"、sync.WaitGroup 传值而非传指针。但它完全不管 err 是否被处理、API 是否已弃用、goroutine 是否泄漏。
常见错误现象：go vet ./... 没报错，CI 却在线上崩了空指针或 time.After 泄漏——说明 vet 漏掉了语义更深的问题。
- 必须在 CI 中显式运行：
go vet -vettool=$(which go tool vet) ./...（避免某些环境路径问题） - 别信 IDE 自动提示：有些编辑器默认只对当前文件 run vet，漏掉跨包调用场景
- 它不检查
database/sql的rows.Close()忘关、http.Client超时设置缺失等资源类隐患
staticcheck 是线上事故的真正守门员
golint 已归档，staticcheck 是官方推荐的替代品，不是风格检查器，而是带 AST 语义理解的“代码医生”。它能发现 vet 根本看不到的高危模式，比如 for _, v := range items { go func() { fmt.Println(v) }() } 导致所有 goroutine 打印同一个值。
使用场景集中在并发、时间、字符串、JSON 解析等易出错模块：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
time.Now().Unix()→ 提示改用time.Now().UnixMilli()（精度与性能双提升） -
strings.Replace(s, "a", "b", 1)→ 若本意是全替换，应改用strings.ReplaceAll或第 4 参数设为-1 -
json.Unmarshal后未检查 error → 直接标为 SA1006（高危）
注意：staticcheck 默认不启用，必须在 .golangci.yml 中显式加入 enable: ["staticcheck"]，否则等于没装。
golangci-lint 不是“开箱即用”，配错反而埋雷
它本质是 linter 聚合器，并行调度 staticcheck、errcheck、govet 等十多个检查器。但很多人直接 golangci-lint run，结果 unused 和 deadcode 刷屏，关键的 SA1021（循环中滥用 time.After）或 SA1019（调用已弃用 API）却被淹没。
实操建议：
- 禁用过时 linter：
disable: ["golint", "maligned", "scopelint"]——这些要么废弃，要么功能已被 staticcheck 覆盖 - 测试目录豁免资源检查：
run: --skip-dirs="testdata|_test"，避免 mock 场景下误报sql.Rows未 close - CI 中必须加参数：
--fast --issues-exit-code=1，否则警告不阻断构建，等于形同虚设
本地开发最容易忽略的两个手动动作
IDE 自动提示会让人误以为“检查已到位”，但以下两件事必须人工确认：
- 每次新增 HTTP handler 或 DB 查询，手动跑一次：
golangci-lint run --enable=staticcheck --fast ./...—— 因为 staticcheck 的部分规则（如 SA1019）需完整 module 加载才能触发 - 合并前检查是否漏掉
defer rows.Close()或defer resp.Body.Close()：这类问题不会被 vet 报，staticcheck 在非标准调用链下也可能漏检，必须结合人工 review +errcheck插件辅助
真正卡住质量的不是工具本身，而是哪几类问题你默认交给了工具、哪几类你仍靠肉眼——比如 unmarshal 后的 error 处理、context.WithTimeout 的 cancel 调用、interface{} 类型断言后的 nil 检查，这些都得落在具体代码路径上逐条核验。
