变量遮蔽会使 := 看似声明实则赋值，导致外层变量（如 err）被同名新变量完全遮蔽，引发 defer 错误、错误判断失效等静默故障；go vet -shadow 可检测同一作用域内遮蔽但默认关闭，需手动启用，而包级变量遮蔽需 staticcheck 等工具补充检测。
变量遮蔽会让 := 看似声明实则赋值
Go 中用 := 在已有变量作用域内“重新声明”，只要至少有一个新变量，编译器就允许——但旧变量会被同名新变量完全遮蔽。这不是错误，而是 Go 的设计特性，但极易导致逻辑错位。
- 常见错误现象：
err被反复遮蔽后，外层if err != nil判断失效，panic 或静默失败 - 典型场景：嵌套
if、for或函数调用后立即用:=处理返回值 - 容易被忽略的点：IDE 或
go vet默认不报错，需启用go vet -shadow才能捕获
go vet -shadow 能发现但不强制阻止
Go 官方工具链提供 -shadow 检查，但它默认关闭，且只警告、不报错。很多 CI 流程没集成它，导致遮蔽问题潜伏到运行时。
- 启用方式：
go vet -shadow ./...
- 它会标记类似 “declaration of
ctxshadows declaration at xxx.go:12” 的警告 - 注意：它对跨 scope（如不同函数）不检查；只关注同一作用域内“声明即遮蔽”
- 性能影响几乎为零，但建议加入 pre-commit hook 或 CI 步骤
遮蔽常和 defer + err 组合出致命 bug
这是最典型的线上事故来源：在 defer 中引用的 err 是外层变量，但中间某次 := 遮蔽了它，导致 defer 实际读的是另一个（可能未初始化或已覆盖）的 err。
- 示例：
func badExample() error {
f, err := os.Open("a.txt")
if err != nil {
return err
}
defer f.Close()
// 这里遮蔽了外层 err！
data, err := ioutil.ReadAll(f) // 注意是 :=
if err != nil {
return err
}
// defer f.Close() 仍正常，但下面这行 defer 会出问题：
defer func() {
if err != nil { // ← 这个 err 是上面声明的新变量，可能为 nil，即使前面 ReadAll 失败了
log.Printf("read failed: %v", err)
}
}()
return nil
}
- 修复方式：统一用
var err error声明，后续全部用= - 或显式重命名：
data, readErr := ioutil.ReadAll(f)，避免遮蔽
模块级变量遮蔽更难排查
当包级变量（var ErrNotFound = errors.New("not found")）被同名局部变量遮蔽，不仅逻辑异常，还可能破坏错误比较语义（比如 errors.Is(err, ErrNotFound) 失败）。
立即学习“go语言免费学习笔记（深入）”；
- 这类遮蔽不会被
go vet -shadow捕获，因为包级变量和局部变量不在同一作用域 - 调试时打印
fmt.Printf("%p", &err)可快速确认是否指向同一地址 - 静态分析工具如
staticcheck（配置SA9003）能补位检测此类问题
