go vet 是专查“合法但可疑”代码的静态分析工具，非编译器亦非通用linter；默认检查项极少，需手动启用如-unmarshal、-copylocks等关键选项，并注意构建标签与未导出字段的检查盲区。
go vet 不是编译器，也不是 linter，它只报告“合法但可疑”的代码模式——能过编译，但大概率是错的。
go vet 默认只开基础检查，不等于“已经查全了”
刚跑 go vet ./ 看到零报错，不代表代码安全。默认启用的检查项极少（比如只开 printf、structtag、unreachable 等几个），大量高危模式根本不会触发：
-
nil指针接收者调用方法（仅当方法导出且 receiver 是指针时才报） - 未处理的 error（
errcheck干的事，go vet不管） - sync.WaitGroup 字段传值而非取地址（
go vet会报，但需显式启用copylocks） - json.Unmarshal 传非指针（
go vet会报unmarshal，但默认关闭）
要真正起作用，得手动开启关键检查：go vet -vettool=$(which go tool vet) -printf -structtag -unmarshal -copylocks -atomic ./
构建标签影响 go vet 的检查结果
如果你的结构体字段被 // +build dev 或 build tags 条件编译掉了，go vet 就看不到它——哪怕逻辑上它会导致 panic。
立即学习“go语言免费学习笔记（深入）”；
- 运行
go vet -tags=unit ./时，只有带//go:build unit的文件/字段参与检查 - CI 中若没对齐构建标签，
go vet可能漏掉测试专用字段的误用（比如 mock 里用了指针但没初始化） - 接口字段（
interface{}）即使底层存的是指针，go vet也只看到InterfaceKind，不会报警
go vet 报错不等于 runtime panic，但往往是 panic 前兆
它不执行代码，只做控制流和类型约束分析。典型场景：
-
go vet报nil pointer dereference：某个变量在分支中可能为nil，后续又直接调用了它的方法或字段 - 报
unreachable code：比如return后还有语句，说明逻辑有断层，可能掩盖资源未释放 - 报
printf format mismatch：不是语法错误，但运行时会输出%!d(string=...)这类难调试的字符串 - 不报切片/映射的
len(nilSlice)—— 因为这不会 panic，属于合法行为
也就是说，go vet 的价值不在“找 bug”，而在“提前暴露你写代码时的思维断点”。它逼你回答：这个变量真可能为 nil 吗？这个 fmt 参数真匹配吗？这个结构体字段真该导出吗？
go vet 和 golangci-lint 不是二选一，而是分层使用
别把 go vet 当成可选项。它是 Go 工具链的基石，速度快、无依赖、CI 必跑。
- 本地开发：VS Code 的 Go 插件默认集成
golangci-lint，实时提示更细；但改完关键逻辑后，仍应手动跑一次go vet -tags=dev ./确认基础语义没问题 - CI 流程：用
golangci-lint run --timeout=2m，它内部已包含govet，但注意它默认只启用部分govet子检查——需在.golangci.yml里显式配置settings: { "govet": { "checks": ["all"] } } - 最常被忽略的一点：
go vet对未导出字段（小写开头）检查有限；而staticcheck（通过golangci-lint启用）能覆盖它们，比如SA1029（for range 中取地址错误）就常出现在私有切片遍历里
真正容易翻车的，从来不是那些一眼能看出的错误，而是 go vet 默默跳过的条件编译分支、未导出字段的并发访问、以及 interface{} 背后那个没人检查是否初始化的指针。
