必须用golangci-lint而非单独工具：golint已归档禁用，govet默认漏检unmarshal等高危项，staticcheck单独运行易因路径或模块模式报错；golangci-lint并行调度多linter，统一配置、超时与输出，CI中一条命令即覆盖全维度检查。
静态分析不是“锦上添花”，而是Go项目上线前必须卡住的质量门槛。不跑staticcheck或golangci-lint，等于默认接受空指针、goroutine泄漏、SQL资源未关闭等隐患进入主干。
go vet 能查什么？哪些问题它根本不管
go vet是Go标准工具链里最轻量但最可靠的守门员，它只做语义级可疑模式识别，比如：
-
fmt.Printf参数类型与格式符不匹配（如%d传了string） - 结构体字段标签重复或语法错误（
json:"name" json:"name"） - 无用的
break、goto跳转，或select中default永远不执行
但它**不检查命名风格**（如myVar该不该叫MyVar），**不报未使用的包导入**（import "os"但全没用），也**不分析函数复杂度或内存分配开销**。这些得靠更重的工具补位。
staticcheck 为什么比 golint/golint 替代品更值得投入
golint早在2021年就被官方归档，社区已普遍迁移到staticcheck——它不是风格检查器，而是带语义理解的“代码医生”：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 能识别
for range里取地址导致的变量复用问题：for _, v := range items { go func() { fmt.Println(v) }() }→ 实际打印的全是最后一个v - 检测
time.Now().Unix()这种低效写法，建议改用time.Now().UnixMilli() - 发现
strings.Replace被误用于单字符替换，提示改用strings.ReplaceAll或strings.Replace第4个参数为-1
它的检查项分三类：S（simple）、SA（static analysis）、ST（style），默认只开SA和S就足够覆盖90%线上事故诱因。
golangci-lint 配置不当反而掩盖关键问题
很多人把golangci-lint当“全家桶”直接跑，结果大量unused、errcheck警告刷屏，反而忽略真正的SA1019（已弃用API调用）或SA1021（time.After在循环中滥用）。
- 必须显式启用
staticcheck：在.golangci.yml里加enable: ["staticcheck"]，否则它默认不激活 - 禁用过时linter：
disable: ["golint", "maligned", "scopelint"]——这些要么废弃，要么被staticcheck覆盖 - 对测试文件豁免资源检查：
run: --skip-dirs="testdata|_test"，避免sqlrows在mock场景误报
CI里别只写golangci-lint run，加上--fast（跳过缓存重建）和--issues-exit-code=1，让构建真正失败而非仅输出警告。
本地开发时最容易漏掉的两个动作
开发者常在IDE里依赖自动提示，但以下两件事必须手动做：
- 每次
git commit前运行staticcheck ./...：它会检查整个模块依赖树，而IDE通常只扫当前打开文件 - 更新
staticcheck本身：go install honnef.co/go/tools/cmd/staticcheck@latest——它的规则库每月迭代，旧版本可能漏掉net/http新API的误用检查
最危险的盲区是：认为“没报错=没问题”。比如staticcheck不会警告你context.WithTimeout没调cancel()，但它能发现defer cancel()写在if err != nil分支里导致漏调——这种细节，只有深度控制流分析才能揪出来。
