defer在for循环中总打印最后一个值，因其捕获变量引用而非当前迭代值；若i在循环外声明，所有defer共享同一变量，最终执行时i已是循环结束后的终值。
defer 在 for 循环里为什么总是打印最后一个值？
因为 defer 捕获的是变量的引用，不是当时循环迭代的值。只要那个变量在函数结束前还活着（比如是循环外声明的），所有 defer 语句最终执行时看到的都是它最后被赋的值。
常见错误现象：for i := 0; i 输出三行 <code>3，而不是 0、1、2。
- 最直接的解法：在循环体内用新变量“快照”当前值，比如
for i := 0; i - 或者把逻辑封装进匿名函数并立即传参：
for i := 0; i - 注意：如果循环变量是切片或结构体指针，且你 defer 的是它的字段或方法调用，同样会受此影响——捕获的是地址，不是副本
defer 调用的函数参数是何时求值的？
参数在 defer 语句执行时（即碰到那行代码时）就求值并保存，但函数体本身等到外围函数 return 前才执行。
这意味着：如果参数里有表达式（比如函数调用、取地址、取长度），它会在 defer 写出的那一刻就运行；而函数体里的逻辑，包括对同一变量的再次读取，是在延迟执行阶段发生的。
立即学习“go语言免费学习笔记（深入）”；
for i := 0; i ：参数 <code>i在每次 defer 时求值，所以输出0和1for i := 0; i ：不影响结果，因为参数早已确定for i := 0; i ：函数体里的 <code>i是闭包引用，最终都读到2
在 goroutine 里用 defer 需要特别注意什么？
goroutine 的生命周期独立于创建它的函数，而 defer 只在所在函数 return 时触发。如果你在 goroutine 里写 defer，它只对那个 goroutine 的函数生效，和主线程完全无关。
典型误用场景：想用 defer 自动释放资源（如 close channel、unlock mutex），却把它写在了 go 关键字启动的函数里，结果 goroutine 还没跑完，资源就被提前释放了。
- 不要在 goroutine 内部依赖 defer 来管理跨 goroutine 生效的资源（比如全局 mutex、共享 channel）
- 如果必须用，确保 defer 所操作的对象作用域覆盖整个 goroutine 生命周期，例如局部打开的文件、临时分配的内存
- 更稳妥的做法是显式控制：在 goroutine 函数入口加 lock，在出口 close 或 unlock，不靠 defer
defer 性能开销和编译器优化边界
Go 1.13+ 对单个函数内无条件 defer（比如没套 if）做了栈上分配优化，避免堆分配；但循环中多次 defer 仍会累积 defer 记录，runtime 需在 return 前遍历链表执行，有轻微调度开销。
这不是性能瓶颈，但会影响可读性和调试体验——尤其当 defer 嵌套多层或混用 panic/recover 时，执行顺序容易反直觉。
- 别为了“看起来整洁”在循环里塞一堆 defer；该用显式 close/unlock 就用
- 用
go tool compile -S看汇编，能确认是否触发了 defer 优化（搜索deferproc调用次数） - 真正容易被忽略的是：panic 后 defer 仍执行，但如果 defer 里又 panic，会覆盖原始 panic，导致错误信息丢失
