shadowing 是 Go 中内层作用域用 := 声明同名变量时“看不见的覆盖”，不报错但会隐藏外层变量；常见于 if、range、defer 和 goroutine 中，易导致逻辑错误，需用 go vet -shadow 等工具检测并养成复用变量赋值的习惯。
什么是 shadowing：不是重定义，而是“看不见的覆盖”
Go 中没有“变量重复声明”错误，但如果你在内层作用域（比如 if、for 或函数内部）用 := 声明了一个和外层同名的变量，Go 会悄悄创建一个新变量，把外层那个“盖住”——这就是 shadowing。它不报错，也不警告，但你读代码时很可能以为在改原变量，实际操作的却是另一个。
-
shadowing只发生在使用:=时；用var或直接赋值=会报错（no new variables on left side of :=） - 外层变量依然存在，只是当前作用域里访问不到
- 函数参数、接收者字段、包级变量都可能被局部变量遮蔽
常见踩坑场景：从 if 到 range 都在偷偷换人
最典型的是在 if 块里用 := 初始化错误变量：
err := someFunc()
if err != nil {
err := fmt.Errorf("wrap: %w", err) // ← 这里 shadowed 了外层 err！
log.Println(err)
}
log.Println(err) // ← 还是原来的 err，没被修改
类似地，range 循环中也容易误用：
items := []string{"a", "b"}
for i, s := range items {
i, s := i+1, strings.ToUpper(s) // ← 新建了 i 和 s，外层循环变量没变
fmt.Println(i, s)
}
// 下一轮循环时，i 和 s 仍是原始值
-
defer中引用被遮蔽的变量，会捕获到“遮蔽后”的值（常导致日志或清理逻辑出错） - 在 goroutine 中闭包捕获遮蔽变量，结果可能和预期完全不符
- IDE（如 GoLand）默认不标出
shadowing，需手动开启go vet -shadow检查
怎么发现和避免：别靠眼力，靠工具和习惯
Go 官方工具链提供 go vet -shadow，但它默认不启用，且只检查局部遮蔽（不报包级变量遮蔽）。建议加入 CI 或本地 pre-commit：
立即学习“go语言免费学习笔记（深入）”；
go vet -shadow ./...
更实用的习惯是：
- 所有错误处理统一用
err = fmt.Errorf(...)而非err := fmt.Errorf(...) - 在
if/for块开头不声明新变量，优先复用已有变量名 + 赋值 - 使用
golangci-lint并启用govet和shadowlinter - VS Code 中安装 “Go” 插件后，在设置里打开
"go.vetFlags": ["-shadow"]
为什么 Go 允许它：简洁性代价是隐式作用域切换
Go 的设计哲学是“显式优于隐式”，但 shadowing 是个例外——它让短作用域初始化更紧凑（比如 if err := do(); err != nil { ... }），可读性短期提升，长期却增加理解成本。
- 它不影响性能（只是栈上多一个变量），但影响维护心智负担
- 不同团队对是否禁用
shadowing有分歧：Kubernetes 代码库明确禁止；一些 CLI 工具项目则宽松 - 最难调试的是嵌套多层遮蔽（比如函数内
if再套for），变量名相同、类型相同、含义不同，IDE 跳转也只会带你去最近一次声明处
真正麻烦的不是写错，是读错——你以为在修 bug，其实只是没看见自己正对着一个“假变量”打补丁。
