defer 参数当场快照、执行逆序触发、仅命名返回值可被修改；参数在defer语句执行时即求值拷贝，故后续变量变更不影响其值。
Go 里写延迟执行，直接用 defer 就行，但光写上不等于写对——参数当场快照、执行逆序触发、命名返回值才能被改，这三点没踩准，defer 很容易变成“看起来关了，其实没关”或者“想改返回值，结果白写了”。
defer 参数为什么总是旧值？
因为 defer 后面函数的参数，在 defer 这行语句执行时就求值并拷贝了，不是等到函数退出才读变量。
- 写
defer fmt.Println(i)，打印的是这一行执行时的i值，后续改i没影响 - 循环里写
for i := 0; i → 全输出3（因为循环结束时i == 3，所有defer都捕获了最后一次赋值） - 想按顺序输出
0、1、2，得用闭包传参：defer func(n int) { fmt.Println(n) }(i)，或立即执行匿名函数：defer func() { fmt.Println(i) }()
多个 defer 为什么顺序反着来？
defer 是入栈操作，后注册的在栈顶，函数退出时从顶往下弹出执行——这就是 LIFO（后进先出）。这个顺序直接决定资源是否安全释放。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
resp, err := client.Do(req)后，必须先写defer resp.Body.Close()，再写defer client.Close()；否则client.Close()可能提前断开连接，导致Body读不全 - 打开多个文件后要关闭，注册顺序得是
defer f1.Close()、defer f2.Close()、defer f3.Close()，这样实际执行才是f3→f2→f1，符合“后开先关”逻辑 - 加锁嵌套时：
mu1.Lock(); defer mu1.Unlock()和mu2.Lock(); defer mu2.Unlock()必须按加锁反序注册，否则可能死锁
defer 能改 return 的值吗？
只能改命名返回值。匿名返回值在 return 表达式求值后就拷贝走了，defer 改的是局部变量，不影响最终返回。
- 有效：
func f() (err error) { err = io.ErrUnexpectedEOF; defer func() { err = fmt.Errorf("wrap: %w", err) }(); return }→ 返回包装后的 error - 无效：
func f() error { e := io.ErrUnexpectedEOF; defer func() { e = fmt.Errorf("wrap: %w", e) }(); return e }→ 返回原始e，defer里的赋值没用 - 更隐蔽的坑：
func() *int { i := 0; defer func(){i++}(); return &i }→ 返回悬空指针，i栈空间已回收
最常被忽略的一点：defer 不是语法糖，每次调用都生成一个 _defer 结构体，链入 goroutine 的 defer 链表。万级循环里无节制写 defer，哪怕 Go 1.22+ 做了栈上优化，GC 压力还是会明显上升——真要批量清理，优先考虑显式收口，而不是靠 defer 堆着等函数结束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
