go vet 是 Go 工具链自带的语义分析检查工具，专查语法合法但逻辑可疑的代码，如 printf 参数不匹配、range 复制结构体、struct 标签拼写错误、未用变量、WaitGroup 调用顺序错误等。
go vet 是什么，它能查出哪些问题
go vet 不是 linter，也不是静态类型检查器，它是 Go 工具链自带的**语义分析检查工具**，专注发现那些「语法合法但逻辑可疑」的代码模式。比如 printf 格式串和参数类型不匹配、range 循环中意外复制结构体字段、struct 字段标签拼写错误（如 json:"name" 写成 json:"nmae"）、未使用的变量（仅限函数内局部变量）、sync.WaitGroup 方法调用顺序错误等。
它不检查风格、命名规范或复杂逻辑缺陷——那是 golint（已归档）、revive 或 staticcheck 的事。别指望 go vet 报出空指针解引用，它也做不到。
如何正确运行 go vet，避免漏检
直接执行 go vet 在当前目录下，只会检查当前包（不含子包），且默认跳过测试文件（_test.go）。常见误操作是只跑 go vet 就以为全量覆盖了。
- 检查整个模块所有包（含子目录）：
go vet ./... - 显式包含测试文件：
go vet -tests ./... - 检查特定文件（调试时有用）：
go vet main.go utils.go - 忽略某个检查项（慎用）：
go vet -vettool=xxx不推荐；更安全的是用-exclude，例如go vet -exclude="printf" ./...
注意：如果项目用了 Go modules，确保在 module 根目录执行，否则 ./... 可能无法解析依赖包路径，导致部分检查失效。
立即学习“go语言免费学习笔记（深入）”；
常见 false positive 和必须绕过的坑
go vet 的 copylocks 检查会警告「不能将带锁结构体作为值传递」，但它对嵌入字段、接口断言、反射调用等场景识别不准，容易误报。例如：
type Wrapper struct {
mu sync.RWMutex
data map[string]int
}
func (w Wrapper) GetData() map[string]int { return w.data } // go vet 会报 copylocks
这不是 bug，而是设计使然（Wrapper 确实被按值传递了），但 go vet 无法判断你是否真的需要并发安全。此时应：
- 优先重构为指针接收器：
func (w *Wrapper) GetData() - 若必须值接收，加
//go:novet注释（仅限该行） - 切勿全局禁用
copylocks，它在多数场景下确实能捕获真实风险
另一个高频坑是 shadow 检查：它会标记同名变量遮蔽外层变量，但有时在 for range + goroutine 中故意复用变量名来避免闭包陷阱，这时反而要主动规避检查（加注释或改名）。
集成到 CI 和本地开发流程中
把 go vet 当成编译前必过门槛，而不是「有空再跑」的可选步骤。CI 中建议：
- 使用
go vet -tests ./...，确保测试代码也被扫描 - 配合
-json输出便于解析（如接入 SonarQube）：go vet -json ./... - 不要和
go build合并在一条命令里（如go build && go vet），失败时构建可能已污染$GOPATH/pkg；应单独作为检查阶段
本地开发中，VS Code 的 gopls 默认已启用 go vet 实时诊断，但仅限当前打开文件。保存时自动触发全包检查需配置 task（如 tasks.json 调用 go vet ./...），否则容易遗漏未打开的文件。
最常被忽略的一点：go vet 不检查 vendor 目录以外的第三方依赖，也不校验 go:generate 生成的代码——那些地方的问题，得靠生成脚本自身保障或额外加检查。
