defer在函数即将返回前按后进先出顺序执行，包括显式return、隐式返回及panic时；注册时捕获变量地址，命名返回值可被defer修改，不适用于跨函数或异步资源管理。
defer 语句到底在什么时候执行
defer 不是“函数返回后才执行”，而是“当前函数即将返回前、按后进先出顺序执行”。关键在于：它注册在函数的栈帧上，但实际调用时机由 return 指令触发 —— 包括显式 return、隐式返回（如函数末尾）、panic 导致的提前退出。
常见错误现象：defer 看似没执行，其实是被 panic 中断了；或者误以为 defer 能捕获后续代码的变量变化，结果闭包捕获的是注册时的值（见下节）。
- defer 注册发生在语句执行时，但调用发生在函数控制流离开该函数前
- 多个 defer 按逆序执行：
defer f1()、defer f2()，则先调f2()，再调f1() - 即使函数 panic，已注册的 defer 仍会执行（除非程序被
os.Exit强制终止）
defer 中闭包引用局部变量的坑
defer 后面跟的是一个函数调用表达式，如果写成 defer func() { println(x) }()，这是立即执行；而写成 defer func() { println(x) }()（末尾无括号），才是注册闭包。问题在于：这个闭包捕获的是变量 x 的地址，不是值 —— 如果 x 在 defer 注册后又被修改，闭包执行时看到的就是新值。
使用场景：常见于资源清理，比如文件关闭、锁释放，但若在 defer 里读取循环变量或临时计算结果，极易出错。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 循环中直接 defer 使用循环变量：
for i := range files { defer os.Remove(files[i]) }→ 所有 defer 都删最后一个文件 - 正确做法是传参绑定值：
for i := range files { i := i; defer os.Remove(files[i]) }（短变量声明重新绑定） - 或显式传参：
for _, f := range files { defer func(name string) { os.Remove(name) }(f) }
defer 对返回值的干扰（尤其是命名返回值）
当函数有命名返回值（如 func foo() (err error)），defer 中的匿名函数可以读写这个返回变量。这会让逻辑变得隐蔽：defer 修改的不是“返回结果”，而是函数即将返回的那个变量本身。
性能影响：命名返回值 + defer 修改，会让编译器无法做某些优化；兼容性无问题，但可读性差，容易引发误解。
- 示例：
func bad() (x int) { x = 1; defer func() { x = 2 }(); return }→ 返回 2，不是 1 - 这种写法在错误包装、日志记录等场景出现过，但应避免：它把控制流和返回值耦合得太紧
- 如果真需要修饰返回值，显式赋值 + return 更清晰：
x = 1; ...; x = 2; return
defer 不是万能资源管理器
defer 适合生命周期与函数作用域一致的资源清理，比如打开一个文件、加一把锁、启动一个 goroutine 协作。但它不解决跨函数、异步、或需提前释放的场景。
容易踩的坑：用 defer 关闭 HTTP 响应体 resp.Body，却忘了在读取完响应前就返回错误，导致 body 没被读完、连接无法复用；或者 defer 关闭数据库连接，但连接实际属于连接池，不该手动 close。
- HTTP client 场景：
defer resp.Body.Close()必须在检查resp.StatusCode和读取resp.Body之后，否则可能 panic 或丢数据 - 数据库操作：一般不用 defer
db.Close()，而是 deferrows.Close()；db实例通常全局复用 - goroutine 泄漏风险：defer 启动 goroutine 但没控制其退出，会导致 goroutine 永远挂起
最常被忽略的一点：defer 的开销虽小，但在高频循环或性能敏感路径里，累积起来不可忽视；Go 1.14+ 对 defer 做了优化，但仍有少量栈操作成本。别为了“看着整洁”而在每层都套 defer。
