defer在函数返回前（含正常return和panic）执行，按后进先出顺序；参数在defer语句执行时求值并快照，非调用时求值。
defer 在函数返回前执行，不是在作用域结束时
很多人以为 defer 类似于 Python 的 finally 或 C++ 的析构，会在变量作用域退出时触发——其实不是。defer 语句是在**当前函数即将返回（包括正常 return 和 panic）的那一刻才执行**，且按后进先出（LIFO）顺序执行所有已注册的 defer。这意味着即使你在 if 分支里写了 defer，只要它被执行过，就会等到整个函数 return 前才跑。
常见错误现象：
– 在循环里反复写 defer close(f)，结果只有最后一个文件被关闭（前面的被覆盖或延迟到函数末尾才执行，但那时可能已失效）；
– 误以为 defer fmt.Println(i) 中的 i 会“捕获”每次循环的值，实际捕获的是变量引用，最终全打印同一个值（比如循环结束后的终值）。
- 若需捕获当前值，用闭包：
defer func(v int) { fmt.Println(v) }(i) - 资源类操作（如
os.Open后立即defer f.Close()）是安全的，因为打开和延迟关闭绑定在同一逻辑路径上 - 不要在循环体中直接
defer资源释放，应把打开+关闭封装进子函数，或改用显式close
defer 参数在声明时求值，不是执行时
defer 后面的函数调用，其**参数在 defer 语句执行那一刻就完成求值**，而函数本身等到函数返回前才调用。这是最容易踩坑的一点。
func example() {
i := 10
defer fmt.Println("i =", i) // 此处 i 已经是 10，不会受后续修改影响
i = 20
return
}
上面会输出 i = 10，不是 20。同理，如果参数是函数调用（如 defer foo(getID())），getID() 会在 defer 这行就执行，而不是等真正调用 foo 时再执行。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 需要动态参数？用匿名函数包装：
defer func() { fmt.Println("i =", i) }() - 对指针或 struct 字段赋值不影响参数求值时机，但会影响 defer 函数体内读取的值（因指向同一内存）
- 在 panic 场景下，这点尤其关键：
defer的参数早就算好了，哪怕 panic 发生在之后几行，也不改变参数值
panic/recover 与 defer 的执行顺序必须理清
当函数发生 panic，它不会立刻终止进程，而是开始「遍历当前 goroutine 的 defer 链」，按 LIFO 顺序执行所有已注册但未执行的 defer；其中任意一个 defer 里调用了 recover()，就能截获 panic 并阻止其向上传播。
关键约束：recover() 只在 defer 函数中调用才有效；且必须是**正在被 panic 触发执行的那个 defer 函数内**，否则返回 nil。
- 不能在普通函数里调
recover()，毫无效果 - 多个
defer时，只有最靠近 panic 处（即最后注册、最先执行的那个）有机会 recover；后面的 defer 仍会运行，但recover()已失效 - recover 后函数仍会正常返回，不会“继续往下跑”，所以 defer 是唯一能做清理 + 拦截的组合
defer 不是万能的，性能和可读性要权衡
每次 defer 都有少量运行时开销：记录函数地址、参数拷贝、维护 defer 链表节点。在高频路径（如每毫秒调用数万次的函数）中，累积起来可观。Go 1.14+ 虽优化了部分场景（如无参数、无闭包的简单 defer），但无法消除本质成本。
更隐蔽的问题是可读性：把清理逻辑分散在函数开头写 defer，会让读者难以一眼看出“这里到底打开了什么、关了什么、顺序如何”。特别是嵌套函数或长函数中，defer 可能离对应的资源获取几十行远。
- 简单资源管理（单个 file / lock / mutex）适合用 defer
- 多个关联资源（如 open → setup → use → cleanup）建议提取为独立函数，用显式 error 处理 + 显式 close 更清晰
- 基准测试中发现 defer 成为瓶颈？用
go test -benchmem -cpuprofile=prof.out确认，再决定是否替换为手动清理
真正难的不是记住 defer 怎么写，而是判断某处该不该用——它掩盖了控制流，也隐藏了执行时机。越是业务核心路径，越要问一句：这里加 defer，是为了简化，还是为了偷懒？
