不能忽略。govet检测逻辑可疑但语法合法的问题，如参数类型不匹配、变量重用、WaitGroup误用等，可能引发线上数据错乱、goroutine泄漏或竞态，必须修复。
govet报错但代码能编译运行，是不是可以忽略？
不能忽略。govet不是编译器，它查的是“逻辑可疑但语法合法”的问题，比如fmt.Printf参数类型不匹配、range遍历时变量被意外重用（shadowing）、sync.WaitGroup方法调用顺序错误、time.After在循环中滥用等。这些错误在本地可能不触发 panic，但上线后容易导致数据错乱、goroutine 泄漏或竞态行为。
- 常见误判场景：mock 测试里用
sql.Rows没.Close()，govet会报rows.Close() not called——这不是 bug，是测试环境合理省略，应通过--skip-dirs="_test|testdata"跳过 - 真实风险点：
for range s { s[i] = ... }这种写法在切片长度变化时可能越界，govet能捕获，但go build完全放行 - 别依赖 IDE 自带的
govet检查：VS Code 的 Go 插件默认只启用部分子检查项，且缓存可能 stale；必须用golangci-lint run --config=.golangci.yml实打实跑一遍
为什么.golangci.yml里写了enable: ["govet"]，却没看到govet报错？
govet默认启用，但它的子检查项（subtests）很多是关闭的。比如printf参数校验、atomic误用、fieldalignment等，默认不激活。你看到的“没报错”，大概率是关键子检查被关了。
- 必须显式开启常用子检查：
linters-settings.govet.checks设为["all"]，或至少包含["printf", "shadow", "atomic", "loopclosure"] - 配置位置必须正确：
linters-settings是顶层字段，不是linters的子项；缩进全用空格，Tab 会导致整个配置静默失效 - 别信
golangci-lint init生成的默认配置：它把govet当黑盒，不展开子检查项，结果就是“启用了但等于没开”
govet报SA1021或GO1012这类编码，怎么定位具体问题？
这些不是govet原生错误码，而是staticcheck或go vet新版输出的诊断 ID。比如SA1021来自staticcheck（time.After 在循环中），GO1012是govet 1.22+ 新增的http.Response.Body未关闭检查。它们混在一起，是因为golangci-lint聚合输出，但根源不同。
- 先确认来源：加
--verbose参数跑一次，看错误前缀是govet还是staticcheck；或者临时禁用staticcheck再跑，对比输出差异 - 查文档要对号入座：
SA1021去 staticcheck.dev 查，GO1012去 pkg.go.dev/cmd/vet 找对应说明 - 修复优先级有差别：
GO1012（Body 未关闭）是资源泄漏，必须修；SA1021（time.After 循环）在高并发下可能拖垮调度器，也得修；但GOXXX编号里有些是建议性提示（如GO1023关于log.Printf格式），可酌情忽略
CI里govet报错却不中断构建，怎么让它真正卡住？
默认golangci-lint run即使发现 100 个govet错误，退出码仍是 0，CI 就当成功。这是最常被忽略的配置盲点。
立即学习“go语言免费学习笔记（深入）”；
- 必须在
.golangci.yml的issues段显式设exit-code: 1，不能只靠命令行参数 - 别在 CI 脚本里写
golangci-lint run || exit 1：这样会掩盖真正的错误信息，日志里只剩“command failed”，看不到哪行代码、哪个文件出问题 - 如果项目允许少量低风险警告（比如某些测试辅助函数），可用
issues.max-same-issues: 3限流，但别设成 0 或 -1
--verbose或不查来源，很容易修错地方。配完记得用golangci-lint run --debug看下实际加载了哪些检查项，比猜靠谱。 
