go中函数内变量仅在调用期间存在，每次调用均重新分配栈空间并返回后立即释放；闭包捕获的变量生命周期取决于闭包是否被引用；for循环中goroutine复用循环变量会导致全部打印同一值。
函数内定义的变量只在该函数执行期间存在
Go 中没有“函数作用域变量持久化”这回事。每次调用 func，所有局部变量（包括 var、:= 声明的）都会重新分配栈空间，函数返回后立即释放——哪怕它是个闭包捕获的变量，其生命周期也绑定到闭包值本身是否被引用。
常见错误现象：for 循环中启动 goroutine 却复用循环变量，导致所有 goroutine 打印同一个值：
for i := 0; i <p>原因不是作用域问题，而是变量 <code>i</code> 在整个循环中是同一个地址，goroutine 实际读取的是它最终的值。修复方式是显式传参或在循环体内用 <code>:=</code> 创建新变量：</p>
- 推荐：用参数绑定
go func(val int) { fmt.Println(val) }(i) - 也可：在循环内加
val := i再闭包引用val
闭包捕获的是变量的引用，不是值快照
Go 的闭包捕获的是外围变量的内存地址，而非声明那一刻的副本。这意味着只要闭包值还存活，它所引用的变量就不会被回收——即使外围函数已返回。
使用场景：实现带状态的回调、延迟初始化配置、计数器工厂等。例如：
func newCounter() func() int {
count := 0
return func() int {
count++
return count
}
}
c1 := newCounter()
fmt.Println(c1()) // 1
fmt.Println(c1()) // 2
注意点：
-
count是堆上分配的（因为逃逸分析判定它会逃出函数），生命周期由闭包引用决定 - 若闭包未被任何变量持有（比如直接调用后丢弃），
count会被 GC 回收 - 多个闭包共享同一变量时，修改会相互可见——这不是 bug，是预期行为
defer 中的变量求值时机容易误解
defer 语句注册时，**函数名和参数表达式会立即求值**，但函数体执行推迟到外层函数返回前。这是造成“变量值不对”的高频坑。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误：
func example() {
a := 1
defer fmt.Println(a) // 这里 a=1 被确定了
a = 2
} // 输出 1，不是 2
如果想延迟读取变量当前值，必须用闭包包装：
- 错：
defer fmt.Println(a)→ 求值在 defer 行 - 对：
defer func() { fmt.Println(a) }()→ 求值在真正执行 defer 时
参数多的时候更明显：defer log.Printf("status=%d, msg=%s", code, msg) 中 code 和 msg 都在 defer 行求值，后续修改不影响日志内容。
全局变量和包级变量的生命周期贯穿整个程序运行期
包级变量（在函数外用 var 或 const 声明）在 main 启动前完成初始化，直到程序退出才释放。它们不受函数调用影响，但要注意并发安全。
容易踩的坑：
- 在
init()函数中初始化全局变量时，依赖其他包的init()执行顺序不确定，可能 panic - 多个 goroutine 同时写同一个包级变量（如
var counter int）而没加锁，产生竞态（go run -race可检测） - 误以为
sync.Once保护的是变量本身——其实它只保证初始化逻辑只执行一次，变量后续仍可被任意读写
真正需要跨函数维持状态且线程安全时，优先考虑封装成结构体 + mutex，而不是裸用包级变量。
作用域本身很简单，难的是变量背后的内存归属（栈/堆）、GC 时机、以及并发下的可见性。别只盯着“能不能访问”，得多问一句：“这个值此刻到底存在哪？谁在 hold 它？”
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
