go中变量名重复导致的shadowing是真问题，因编译器静默复用或覆盖同名变量，引发逻辑bug却无报错警告；常见于:=声明、有名返回值、for循环及struct字段同名场景。
变量名重复导致的 shadowing 是真问题，不是风格争议
Go 里用 := 声明变量时，如果左侧有**已声明但未赋值的同名变量**，编译器会静默复用它；但如果左侧出现**全新变量名**，哪怕只多一个，整个声明就变成“新声明 + 可能覆盖”，这时旧变量就被 shadow 了——你还在用它，但它已经不是你以为的那个了。
常见错误现象：if err != nil { return err } 后面又写 err := doSomething()，结果 err 变成局部变量，外层的 err 没被更新，后续判断失效。
- 使用场景：函数内嵌
if/for块、defer前修改错误、测试中重用变量名 - 参数差异：
var err error和err := ...语义完全不同；前者是声明+零值，后者是声明+赋值（且可能 shadow） - 性能影响几乎为零，但逻辑 bug 极难定位——因为不报错、不警告、运行时行为诡异
- 实操建议：启用
go vet -shadow（注意：1.22+ 默认禁用，需显式开启），或用staticcheck的SA5001规则
函数参数和返回值命名不能随便省略
Go 允许函数签名里写 func foo(x, y int) (int, error)，但一旦你给返回值起了名字（比如 (n int, err error)），这些名字就自动成为可赋值的变量，作用域覆盖整个函数体——这时候再用 n := 42 就会 shadow 它，而你可能根本没意识到自己正在覆盖返回值。
常见错误现象：函数开头写了 func process(data []byte) (result string, err error)，中间却写 result := strings.ToUpper(string(data))，结果 result 变成局部变量，return 时还是零值。
立即学习“go语言免费学习笔记（深入）”；
- 使用场景：需要提前赋默认返回值、error 处理链中反复修改返回值
- 参数差异：无名返回值（
(int, error)）无法被直接赋值；有名返回值（(n int, err error)）天然可写，但容易误 shadow - 兼容性影响：有名返回值会让 godoc 更清晰，但也会放大 shadowing 风险——尤其团队协作时，新人未必注意到顶部那行声明
- 实操建议：有名返回值只在真正需要提前设置（如初始化
err = nil）或文档价值明显时才用；否则统一用无名返回 + 显式return xxx, err
for 循环里的 index 变量最容易被反复 shadow
for i, v := range slice 中的 i 和 v 每次迭代都会复用同一块内存，但如果你在循环体内又写 i := i * 2，就立刻创建了一个新的 i 局部变量，原 i 不再可达——而且这个新 i 在下一轮迭代开始前就失效了，完全没意义。
常见错误现象：想对索引做变换后传给 goroutine，却写了 go func() { fmt.Println(i) }()，结果所有 goroutine 打印的都是最后一个 i 值（因为闭包捕获的是变量地址，而那个变量已被多次 shadow 或复用）。
- 使用场景：启动多个 goroutine 处理
range数据、循环中条件修改索引、嵌套循环重用变量名 - 性能影响：每次
:=都分配新变量，虽然小，但在高频循环里可能被 linter 报告为浪费 - 实操建议：循环内需要改值就用
i = i * 2（别用:=）；要传进 goroutine 就显式绑定：go func(idx int) { ... }(i)
struct 字段名和局部变量名撞车时，编译器不会提醒
Struct 字段本身没有作用域层级概念，但当你在方法里声明一个和字段同名的变量，比如 u.name := "foo"（假设 u 是 *User），这行代码其实等价于 name := "foo" —— 它不会给 u.name 赋值，而是新建一个局部变量 name。这种写法既不报错也不警告，但逻辑彻底跑偏。
常见错误现象：方法里写了 id := getUserID()，然后以为 u.id 已更新，实际 struct 字段仍是零值；或者更隐蔽地，在 defer 中打印 u.id，却发现一直是初始值。
- 使用场景：方法内临时计算字段值、测试中 mock 字段、从 map 解构时重名
- 参数差异：字段访问必须带接收者（
u.name），而局部变量赋值不用（name := ...）；两者语法相似但语义隔离 - 实操建议：结构体字段名尽量加前缀（如
UserID而非id），或启用staticcheck的SA9003（检测未使用的局部变量，间接暴露这类 shadow）
最麻烦的不是写错，是错得毫无动静——Go 的 shadowing 不触发任何错误，只悄悄替换掉你心里认定的那个变量。盯紧 := 出现的地方，尤其是缩进变深、逻辑分支变多的时候。
