go vet最常漏掉的3个警告是：printf动词与参数类型不匹配、range闭包变量捕获问题（需显式启用-shadow）、结构体字段标签格式错误；defer参数在声明时求值而非执行时；io.Reader/Writer实现须正确处理空切片和短写；go.mod中indirect标记不可手动增删，且需警惕replace引发的版本冲突。
Go代码审查最常漏掉的3个go vet警告
很多人以为go vet只是“锦上添花”，其实它能直接揪出运行时 panic 或逻辑错位。比如printf动词和参数类型不匹配，编译器不报错，但程序可能静默截断或崩溃。
-
go vet默认不检查range中闭包捕获变量的问题（需加-shadow），这是并发 bug 高发区 - 结构体字段标签写错（如
json:"name"写成json:"name,"）会被go vet识别为无效标签，但go build照常通过 - 用
fmt.Printf打印error值时误传指针（&err），go vet会提示printf: %v verb for error type，避免日志里输出&{...}这种无意义地址
审查defer时必须盯住的2个执行时机
defer不是“函数结束才跑”，而是“当前函数返回前”，但它的参数在defer语句执行时就求值了——这点被大量误读。
- 写
defer fmt.Println(i)后修改i，打印的是旧值；想打印新值得写defer func(){ fmt.Println(i) }() - 在
for循环里启动 goroutine 并defer资源释放，容易因变量复用导致所有 goroutine 共享同一个defer实例，应把循环变量显式传入闭包 - 若
defer调用的函数本身有 panic，它会覆盖原始 panic，审查时要确认defer内是否做了recover或日志记录
接口审查：别让io.Reader和io.Writer变成“纸面契约”
Go 接口是隐式实现的，但很多代码只管“能编译”，不管“行为对不对”。比如自定义io.Reader实现，Read([]byte)方法没处理len(p) == 0的情况，上游io.Copy就会卡死。
- 所有
io.Reader实现必须支持p为空切片（即len(p) == 0），此时应返回(0, nil)，否则bufio.Scanner等会无限等待 - 实现
io.Writer时，若Write返回n < len(p)但err == nil，调用方可能误以为写成功了，实际只写了部分字节——除非你明确设计为“短写”，否则应返回err != nil - 用
interface{}接收参数却暗中要求实现了某个接口（比如要求传入对象有Close()方法），属于破坏接口抽象，应直接声明具体接口类型
审查go.mod依赖时最容易忽略的版本陷阱
go mod tidy自动拉取最新补丁版，但某些小版本更新会悄悄改掉行为——比如golang.org/x/net/http2从v0.7.0升到v0.8.0后，Transport默认启用了 HTTP/2 的流控，导致高并发下连接复用率骤降。
立即学习“go语言免费学习笔记（深入）”；
- 用
go list -m all查间接依赖，确认没有意外引入indirect标记的模块（尤其是测试用的 mock 库混进生产依赖） - 升级主依赖前，先看它的
go.mod文件里是否replace了其他模块——如果被 replace 的模块在你项目里也直接引用，就可能出现版本冲突 -
require行末尾的// indirect不是注释，是 go mod 的标记，删掉会导致构建失败；但更危险的是手动加// indirect假装解决依赖，实际掩盖了缺失的显式依赖声明
真正难的不是发现这些问题，而是每次git diff里夹着几十行go.mod变更、十几个defer调用、一堆接口实现时，能不能一眼扫出那个少了个err != nil判断的地方。
