defer捕获的是变量的引用而非快照；循环中所有defer共享同一变量地址，函数返回时i已为终值，故全部输出相同结果。
defer 在 for 循环中打印变量总是输出最终值
这是因为 defer 捕获的是变量的**声明时刻的引用**，而非执行时刻的值。循环变量（如 i）在每次迭代中复用同一内存地址，等所有 defer 被压入栈、函数真正返回时，i 早已超出循环边界（比如变成 3），所以全部输出 3。
常见错误现象：for i := 0; i 输出三行 <code>3，不是预期的 2、1、0。
- 根本原因：defer 的参数在语句**声明时求值**，而
i是地址复用的变量，不是每次迭代新建的 - 不能靠“等它慢一点”来修复——这是语言机制，和调度无关
- 修复核心：让每个
defer绑定一个独立、不可变的值副本
推荐写法：for i := 0; i ——通过在循环体内声明同名局部变量，强制创建新绑定。
goroutine 中直接引用 for range 变量引发 data race
和 defer 类似，但后果更严重：不仅值错，还可能触发 -race 检测器报错，甚至导致数据库写错记录、状态丢失等线上事故。
典型错误代码：for _, member := range p.Members { go func() { db.Exec("UPDATE ... WHERE steamid = ?", member.SteamID) }() } ——所有 goroutine 实际读取的是同一个 member 地址，而该地址内容在循环中持续被覆盖。
立即学习“go语言免费学习笔记（深入）”；
在 Go 中使用 google/wire 实现编译时依赖注入——wire.NewSet、wire.Build、wire.Bind（接口→实现）、wire.Struct、wire.Value、wire.Interface
- 关键事实：
range迭代变量在整个循环生命周期内复用内存，不是每次迭代 new 出来的 -
go func() { ... }()启动异步，不保证立即执行；多数情况下执行时member已是最后一个元素 - 即使没开
-race，行为也是未定义的：可能偶尔对、多数时候错
安全写法有两种，任选其一即可：
- 显式拷贝：m := member; go func() { ... m.SteamID ... }()
- 参数传值：go func(m Member) { ... m.SteamID ... }(member)
defer 在循环里关文件却一直不释放资源
很多人想用 for 循环批量打开并延迟关闭文件，结果发现文件描述符堆积、too many open files 报错。问题不在 defer 本身，而在它的**作用域边界**。
错误模式：func readFiles(paths ——所有 <code>defer f.Close() 都要等到 readFiles 函数返回才执行，而不是每次循环结束。
- defer 的执行时机是「外层函数 return 时」，不是「所在循环迭代结束时」
- 如果
paths是长流或阻塞通道，readFiles可能永不返回，文件永远不关 - 这不是竞态，是资源泄漏，且
-race检测不到
正确做法：把单次操作封装成独立函数，让 defer 在该函数返回时立刻生效：func readFile(path string) { f, _ := os.Open(path); defer f.Close(); ... }，然后在循环中调用 readFile(path)。
想用 defer 记录 error 却总拿到零值
试图在函数开头就写 defer func() { log.Println(err) }() 来统一打日志，结果日志里全是 <nil></nil> 或默认零值。这是因为 err 在 defer 声明时还是初始值，后续赋值对它无效。
只有两种情况能让 defer 看到最终 error 值：
- 使用命名返回参数（如 func do() (err error)），并在 defer 匿名函数中直接读取 err
- 把 error 当作参数传进 defer 调用的函数里（需在 return 前显式调用）
- 命名返回方式最常用，但仅限于你想修改或观察返回值本身时
- 不要在 defer 里做条件重试、状态回滚等逻辑——它不是错误处理主干，只是清理和补充
- recover 必须写在 defer 函数体内部，且只对当前 goroutine 有效；跨 goroutine panic 无法 recover
真正容易被忽略的点是：defer 不是“监听器”，它不感知变量后续变化；它只认声明那一刻的变量快照——无论这个变量是 int、struct 还是 *os.File。
