go变量作用域由代码块层级严格定义：包级变量跨文件可见但import仅限当前文件；短变量声明:=易遮蔽外层变量；go 1.22前循环变量共享地址，闭包中易出错。
Go 语言里变量能不能用、在哪能用、用完会不会被回收，全由作用域决定——不是靠经验猜，而是由代码块层级严格定义的。理解它，关键不是背分类，而是看清「谁声明的、在哪声明的、被谁遮住了」。
包级变量和文件级 import 不是同一层作用域
包级变量（比如 var db *sql.DB）在同一个包的所有 .go 文件里都可见，但 import 声明只在当前文件生效。这意味着：
- 你在
main.go里写了import "fmt"，utils.go不能直接用fmt.Println，必须自己也写一遍import "fmt" - 包级变量名冲突不会跨文件报错，但若两个文件都声明了同名包级变量（如
var config Config），编译会失败：duplicate symbol - 包级变量初始化顺序按源文件字典序，不是按 import 顺序——所以别在 init 函数里依赖其他文件中未显式声明的包级变量
短变量声明 := 只在函数块内有效，且容易意外遮蔽
:= 看似方便，但它只允许出现在函数体内，并且左侧至少有一个新变量；否则就是赋值，不是声明。最常踩的坑是：
- 在
if或for块里用:=声明同名变量，结果外层变量被遮蔽，后续逻辑读到的是块内那个（可能未初始化或已失效） -
err是重灾区：比如if f, err := os.Open(...); err != nil { ... }，这个err只活在if块里，后面想return err就会报错undefined: err - 想复用
err，得先在外层声明var err error，再在块内用=赋值
循环变量在 Go 1.22+ 之前共享同一内存地址
这是闭包场景下最隐蔽的 bug 来源。看这段代码：
for i := 0; i <p>输出往往是 <code>3 3 3</code>，而不是 <code>0 1 2</code>。原因：</p>
- 循环变量
i在整个for块中只分配一次内存，每次迭代只是改它的值 - 所有 goroutine 共享这个
i的地址，等它们真正执行时，循环早已结束，i值为3 - Go 1.22 起默认启用
loopvar模式，每个迭代生成独立变量；但老版本或显式关闭该模式时仍需手动捕获：go func(i int) { ... }(i)
变量遮蔽不是错误，但会让调试变困难
Go 允许内层作用域用同名变量覆盖外层变量，编译器不报错，但语义已变：
- 函数参数叫
name，函数体里又写name := "default"，那参数就彻底不可达了 - 包级变量
var timeout = 30，函数里timeout := 5，看起来像配置覆盖，实际是全新变量，原包级变量没动 - IDE 很难高亮遮蔽关系，建议用
go vet -shadow检查（注意它默认不开启，需显式加 flag）
真正麻烦的从来不是“能不能写”，而是“写完之后，哪一行代码读到的是哪个值”——作用域规则不会变，但人眼容易漏掉那一层花括号或那个冒号等号。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
