Go中:=会声明新变量并遮蔽外层同名变量，导致逻辑错误；应仅在真正需要声明时使用，复用变量须用=，并启用gopls shadow分析或go vet -shadow检测。
Go里用:=一不小心就遮蔽了外层变量
Go中:=不是单纯的赋值，而是“声明并赋值”——只要左边有任何一个新变量名，整条语句就按声明处理。这意味着，哪怕你只想改一个已有变量的值，只要顺手写了:=，又恰好名字和外层变量一样，就会悄悄创建一个新变量，把外层的盖住。
常见错误现象：if块里用err := doSomething()，之后err在if外还是nil；或者for循环里val := item，结果循环外val根本没变。
- 只在确实要声明新变量时才用
:=；想复用外层变量，必须用= - 检查IDE是否启用了
shadow警告（如gopls的shadow分析器），它能标出被遮蔽的变量 - 避免在
if/for块首行就用:=声明err，推荐提前声明：var err error，再用err = doSomething()
函数参数和返回值名也会被:=遮蔽
函数签名里定义的参数或命名返回值，本质是函数作用域内的变量。如果在函数体内用:=声明同名变量，它们会被遮蔽——这不是语法错误，但逻辑可能错乱。
使用场景：写HTTP handler时，习惯性写req := r或ctx := req.Context()，结果req参数就失效了；或者命名返回值func parse() (err error)，内部又写err := json.Unmarshal(...)，导致return时返回的是零值err。
立即学习“go语言免费学习笔记（深入）”；
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 命名返回值尽量少用
:=重新声明同名变量；真要临时存中间值，换名字，比如err2 := ... - 参数名别轻易覆盖；如果需要改造（如
req = req.WithContext(...)），直接用= - 用
go vet -shadow可以检测这类问题（注意：默认不启用，需显式加-shadow）
嵌套作用域里遮蔽容易漏看，尤其在defer和goroutine中
defer和goroutine捕获的是变量的引用，不是值。如果外层变量被内层:=遮蔽，defer实际执行时访问的可能是另一个变量，或者根本访问不到原变量。
典型例子：for i := range items { go func() { fmt.Println(i) }() }——这里i被每个goroutine共享，最后全打印最后一个值；但如果改成for i := range items { i := i; go func() { fmt.Println(i) }() }，就是用遮蔽来“捕获当前值”，但这属于刻意利用，非常容易混淆。
- 循环启动goroutine时，不要依赖遮蔽来“固定”变量值；更安全的做法是传参：
go func(i int) { ... }(i) -
defer里用到的变量，确保没被同名:=遮蔽；否则可能defer执行时读的是空值或旧值 - IDE里打开“show shadowed variables”高亮（如VS Code + Go extension），能快速定位嵌套遮蔽点
为什么Go不禁止遮蔽？以及它和别的语言的区别
Go允许遮蔽，是因为设计上认为“局部作用域优先”更符合直觉，且能减少样板代码（比如不用反复写var）。但它不像Python那样有nonlocal，也不像Rust那样编译期强制所有权转移，所以遮蔽的副作用更隐蔽。
性能影响几乎没有——遮蔽只是栈上多一个变量头，但逻辑错误带来的维护成本极高。兼容性上，所有Go版本行为一致，但老代码里大量存在遮蔽，升级工具链（如gopls）后突然报shadow警告，容易误以为是bug。
- 项目初期就开启
gopls的"analyses": {"shadow": true}配置，比后期补救成本低得多 - CI里跑
go vet -shadow，但注意它会把合法遮蔽也报出来（比如循环里i := i），需结合上下文判断 - 最麻烦的不是遮蔽本身，是遮蔽后变量生命周期错位——比如外层
err本该在函数末尾检查，却被内层遮蔽后“消失”，这种bug很难通过测试覆盖
遮蔽问题不会让程序编译失败，也不会立刻panic，它藏在变量作用域的边界线上，靠人眼很难稳定识别。
