go vet 默认仅运行少量轻量检查，不进行深度分析；Staticcheck 应作为主力替代，覆盖更全且支持精细配置。
Go vet 为什么没报出明显错误？
Go vet 默认只运行一小部分检查项，比如 printf 格式串不匹配、range 循环变量误用这类高频低风险问题。它不会做类型流分析或跨函数追踪，所以像空指针解引用、未使用的 struct 字段、冗余的 error 检查都默认不触发。
实操建议：
- 显式启用全部内置检查：
go vet -all ./...（Go 1.19+ 已弃用-all，改用go vet ./...，但实际仍需手动加子命令） - 更可靠的方式是逐个启用关键检查：
go vet -printf -shadow -structtag -unreachable ./... - 注意
go vet不支持自定义规则，也不能报告未导出包外的潜在问题——它本质是“语法糖检查器”，不是静态分析器
Staticcheck 要不要替代 go vet？
要，而且应该作为主力。Staticcheck 覆盖了 go vet 全部检查项，并额外提供 100+ 条深度规则，比如 SA1019（使用已弃用符号）、SA4006（无意义的循环变量赋值）、SA9003（错误地在 goroutine 中传入循环变量）。
实操建议：
- 安装：
go install honnef.co/go/tools/cmd/staticcheck@latest（注意域名和路径，不是github.com） - 基础运行：
staticcheck ./...；想看具体哪条规则被触发，加-f=full - CI 中建议禁用非阻断性警告（如
ST1000注释风格），用--checks=-ST1000过滤 - 注意 Staticcheck 默认不检查
_test.go文件，如需检查测试逻辑，得显式加上./..._test或用--tests
怎么让两者共存又不重复报警？
go vet 和 Staticcheck 有重叠规则（比如 printf），但实现逻辑不同，误报率和覆盖场景也不同。强行关掉一方可能漏掉真实问题，比如 go vet -printf 能捕获 fmt.Printf("%s", int(42)) 这类类型错配，而 Staticcheck 的对应检查（SA1006）侧重格式动词与参数数量不一致。
实操建议：
- 保留
go vet -printf -shadow -unreachable这三组轻量检查，它们启动快、误报少、适合 pre-commit - 把 Staticcheck 放进 CI，用完整规则集扫描，配合
--fail-on-issue控制出口状态 - 避免在
.golangci.yml里同时启用govet和staticcheck插件——golangci-lint 会把 Staticcheck 的SA规则映射成govet名称，造成混淆
配置文件写在哪？哪些字段最关键？
Staticcheck 支持 .staticcheck.conf（JSON 格式）或 staticcheck.conf（TOML），优先读取前者。go vet 没有配置文件机制，只能靠命令行参数控制。
实操建议：
- 必须设
"checks": ["all"]，否则默认只跑约 20% 规则；若想排除某条，写成"checks": ["all", "-SA1017"] -
"exclude": ["vendor/"]是必须项，否则 vendor 下的代码会拖慢速度并产生大量噪音 - 如果项目用了 Go modules 且有 replace，确保
GOPATH和GOROOT环境变量干净，否则 Staticcheck 可能误判标准库版本导致SA1019误报
复杂点在于：Staticcheck 的规则依赖 Go 编译器的 type-checker 输出，而它本身不走 go list 流程，所以当项目存在非标准 build tag 或 cgo 交叉编译时，某些规则（如 SA1029 遍历 map 后删 key）可能静默失效——这种时候得靠日志里的 could not type-check 提示反推。
