go 1.13 前 defer 慢是因为每次调用需堆分配 _defer 结构体并维护链表，返回时遍历执行；1.13 起支持栈上分配（满足静态确定条件时），1.14 改用数组+位图优化执行效率。
defer 在 Go 1.13 之前为什么慢？
因为每次 defer 调用都要在堆上分配一个 _defer 结构体，还要维护一个链表。函数返回前遍历链表执行，开销明显——尤其在高频小函数里，defer 可能比它包裹的逻辑还重。
- 典型场景：HTTP handler 里每个请求都
defer unlock()、数据库事务中反复defer tx.Rollback() - 性能影响：压测时 GC 压力上升，
defer占用的堆内存可能成为瓶颈 - 容易踩的坑：有人以为
defer是零成本语法糖，实则早期版本下它和new(_defer)几乎等价
Go 1.13 引入的 defer 栈上分配优化
核心变化是：当编译器能静态确定 defer 的调用栈深度（即不会跨 goroutine、无循环引用、参数不逃逸），就直接把 _defer 放在当前函数栈帧里，避免堆分配。
- 触发条件：函数内
defer数量固定、参数不涉及闭包或指针逃逸、没被recover干扰控制流 - 验证方式：加
go build -gcflags="-m" main.go，看到... inlining call to defer ... stack-allocated就生效了 - 注意点：一旦有
if分支里带defer，或defer在循环内，编译器大概率放弃栈分配，回落到堆上
Go 1.14 进一步减少 defer 链表遍历开销
不再用单向链表存 defer，改用更紧凑的数组结构 + 位图标记，执行阶段跳过已处理项，同时减少指令分支预测失败。
- 实际效果：多个
defer连续执行时，平均耗时下降约 20%～30%，对defer fmt.Println()这类调试型写法改善明显 - 兼容性无风险：语义完全不变，
defer执行顺序、panic/recover 行为均未改动 - 容易忽略的细节：这个优化只在 runtime 层生效，你没法手动触发或配置；但升级到 1.14+ 后，只要没关编译器优化（如用了
-gcflags="-N -l"），就自动受益
怎么判断你的 defer 是否真的变快了？
别只看文档说“优化了”，得自己测。尤其要注意基准测试里是否无意引入干扰因素。
立即学习“go语言免费学习笔记（深入）”；
- 用
go test -bench=.对比 1.12 和 1.14+ 的结果，重点看BenchmarkDeferSmallFunc-8这类短路径 case - 避免在 benchmark 函数里写
defer fmt.Printf—— I/O 会掩盖 defer 本身的开销差异 - 真正关键的是：你的业务代码里
defer是否满足栈分配条件。如果大量使用defer func() { mu.Unlock() }()这种带闭包的形式，1.13+ 的优化基本失效
defer 的性能不是线性提升的，它高度依赖编译器能否做静态判定。写的时候少一层闭包、少一次条件分支，有时候比升级 Go 版本还管用。
