defer在return赋值后、函数退出前执行，分三步：赋值返回值→执行所有defer→跳出函数；命名返回值可被defer修改，非命名则不可；defer参数在注册时求值；多个defer按lifo顺序执行。
defer 在 return 赋值之后、函数真正退出之前执行
结论很直接：return 不是原子操作，它分三步：计算并赋值返回值 → 执行所有 defer → 跳出函数。所以不是“defer 在 return 之后”，而是“return 开始执行后，先写返回值，再轮到 defer”。这个顺序决定了命名返回值能否被修改。
- 命名返回值（如
func f() (x int)）在函数入口就声明为局部变量，defer中闭包可读写它 - 非命名返回值（如
func f() int）的返回值是临时寄存器值，defer无法修改 -
defer的参数在defer语句**执行时**求值（即“快照”），不是在真正调用时——这是闭包捕获变量出错的高发点
多个 defer 按后进先出（LIFO）顺序执行
你写的顺序和执行顺序是反的。最后写的 defer 最先跑，最先写的最后跑。这不是设计缺陷，是栈式注册机制决定的——Go 在执行到 defer 那一行时，就把它压入当前 goroutine 的 defer 栈，函数返回前统一弹出。
- 常见错误：以为
defer fmt.Println("1"); defer fmt.Println("2")会输出1\n2，实际是2\n1 - 资源清理场景下，这反而合理：先开文件，后开数据库连接；那就要先
defer db.Close()，再defer f.Close()，确保关闭顺序正确 - 性能上无额外开销，但大量
defer会略微增加函数退出时的延迟（毕竟要逐个调用）
defer 出现在 return 语句后面不会执行
这是语法层面的硬限制：defer 必须在控制流能到达的位置才能注册。一旦遇到 return，后续代码（包括 defer）根本不会执行。
- 错误写法：
return 0; defer func() { ... }()—— 后面的defer永远不会注册，更别说执行 - 正确做法：把
defer放在return前，或封装进条件分支中（如if err != nil { defer cleanup() }） - 注意：
panic不影响已注册的defer，它们仍会执行；但未走到的defer依然不会注册
用 defer 修改命名返回值的典型陷阱
能改 ≠ 应该改。看似方便的 ret++ 操作，容易掩盖逻辑意图，且在多层嵌套或并发场景下难以追踪。
- 示例：
func f() (x int) { defer func() { x++ }(); return 5 }返回6，但阅读者第一眼看不到返回值被动过手脚 - 如果
defer中发生 panic，而你又没recover，整个函数返回行为会被中断，命名返回值可能停留在中间状态 - 更安全的做法：显式赋值 + 显式 return，把副作用收束在一处；仅在日志、指标、清理等无业务语义的场景用
defer
最常被忽略的一点是：defer 的参数求值时机和返回值修改能力，都依赖于“命名返回值”这个语言特性。不声明命名返回值，就等于主动放弃了 defer 对返回值的干预权——这不是 bug，是设计约束，得记牢。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
