Go 的 defer 在 return 赋值完成后、栈帧销毁前执行，因此能修改命名返回值但不能影响普通返回值；其参数在 defer 注册时即求值，而非执行时。
Go 的 defer 不是在函数“退出后”才执行，而是在 return 完成赋值、但栈帧尚未销毁的精确时间点运行——这个窗口决定了它能否修改返回值、为何参数会“卡住”、以及为什么资源释放顺序容易出错。
defer 执行时机：在 return 赋值之后、栈销毁之前
这是所有行为的根源。很多人写 func() int { x := 1; defer func(){x++}(); return x } 期望返回 2，结果还是 1。因为 return x 立即把 x 的当前值（1）拷贝为返回值副本，defer 改的是局部变量 x，不影响已确定的返回值。
但换成命名返回值：func() (ret int) { ret = 1; defer func(){ret++}(); return } 就真能返回 2——ret 是栈帧里的可寻址变量，defer 闭包能直接改它。
-
return语句本身分两步：计算并写入返回值 → 触发defer链表执行 - panic 时同样走这套流程，所以
recover()必须写在defer函数里才有效 - 函数末尾隐式
return也触发该机制，不是只有显式return才算
defer 参数求值：注册时就固定，不是执行时读
写 for i := 0; i ，输出是 <code>2 2 2（Go 1.21 及之前），不是 2 1 0 或 0 1 2。因为每次执行到 defer 那行时，i 的值就被拷贝进 runtime._defer 结构体了，循环结束时 i == 2，三份拷贝全是 2。
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
立即学习“go语言免费学习笔记（深入）”；
- 值类型（
int、string）拷贝值；指针/引用类型（*int、map、slice）拷贝地址，后续改内容会影响defer执行结果 - 想捕获当前值？用显式传参：
defer func(n int) { fmt.Println(n) }(i) - 想捕获最新值？用闭包：
defer func() { fmt.Println(i) }()（注意：这依赖于i的作用域和生命周期） - Go 1.22+ 对循环中闭包的
defer做了优化，但参数求值时机规则没变——别指望靠版本升级绕过逻辑问题
多个 defer 的执行顺序：LIFO，只看注册顺序
defer f1.Close() 和 defer f2.Close() 谁先执行？不看缩进、不看是否嵌套，只看哪条 defer 语句**后执行到**。最后注册的那个最先执行。
- 打开文件 A、再打开文件 B，
defer A.Close()写在前面、defer B.Close()写在后面 → 实际先关 B、再关 A，符合资源依赖逻辑 - 但锁嵌套时容易翻车：比如
mu1.Lock()→mu2.Lock()，对应defer mu2.Unlock()必须在defer mu1.Unlock()之前注册，否则解锁顺序颠倒，可能触发use of closed network connection - 不要依赖代码书写顺序来推断执行顺序，要按控制流实际执行路径判断注册时机
defer 的真实开销：高频路径慎用，循环里别乱 defer
每次 defer 都会分配一个 runtime._defer 结构体，链入 goroutine 的 defer 链表。这不是零成本语法糖。
- 空函数 +
defer比纯return慢 3–5 倍（Go 1.21 基准测试） - 每秒百万次调用的热路径上，GC 压力明显升高
- 循环内写
for range s { defer cleanup(i) }会累积 N 个待执行延迟调用，不仅拖慢性能，还可能 OOM - 简单清理动作（清空 map、重置 slice）优先用显式赋值，别硬套
defer
真正需要 defer 的地方，是那些必须保证执行、且路径分支多（如多处 return 或可能 panic）的收尾逻辑——不是所有清理都值得用它。
