defer按注册逆序（lifo）执行，即后注册的先执行；参数在注册时求值；可修改命名返回值；panic时仍执行，recover必须在defer内调用。
defer 的执行顺序不是“代码从上到下”，而是“注册顺序的逆序”——它本质是栈，不是队列。 你写 defer f1() 再写 defer f2()，最终先执行 f2()，再执行 f1()。这个反直觉点一旦错判，资源释放就可能出乱序问题，比如 body 没关连接先关、锁没解锁就 return。
defer 执行时机：不是 return 后，而是函数退出前
很多人以为 return 一执行函数就结束了，其实 Go 中的 return 是三步：赋值返回值 → 执行所有已注册的 defer → 跳出函数。这意味着：
- 即使函数末尾没有显式
return，隐式返回（函数自然结束）也会触发defer -
panic会中断当前逻辑，但已注册的defer仍会执行（除非被os.Exit强制终止） - 如果在
defer里修改命名返回值（如func() (err error)），它真能改掉即将返回的那个变量
参数求值发生在 defer 注册时，不是执行时
这是最常踩的坑：defer fmt.Println(x) 中的 x 在这行语句执行那一刻就被读取并固化了，后续改 x = 100 不影响输出。常见错误现象包括：
- 循环中写
for _, f := range files { defer os.Remove(f) }→ 所有defer都删最后一个f - 想延迟读最新值？得用闭包：
defer func() { fmt.Println(x) }()（注意末尾无括号） - 更安全的做法是显式传参：
defer func(name string) { os.Remove(name) }(f)
多资源清理必须按 LIFO 逆序安排注册顺序
资源依赖有天然顺序，比如打开文件 → 解析 JSON → 写入 DB，对应清理应是：DB transaction rollback → JSON 解析器释放 → 文件关闭。而 defer 执行是逆序，所以注册顺序就得倒着来：
- 正确：
defer file.Close()写在defer jsonParser.Cleanup()之前 - HTTP 场景：
defer resp.Body.Close()必须在defer client.Close()之前注册 - 锁操作：
mu.Lock()后立即defer mu.Unlock()是安全的，因为sync.Mutex方法允许零值调用 - 但自定义结构体若
Unlock()里有指针解引用，就得先判空
真正容易被忽略的是：defer 不是语法糖，它是 runtime 层级的 _defer 栈帧节点，每次 defer 都要分配内存（Go 1.14+ 对小 defer 做了栈上优化，但高频循环中仍可能引发 GC 压力）。别在每轮 for 循环里无节制 defer，尤其当循环次数可能达万级时。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
