Go 中 defer 参数在注册时立即求值并拷贝，而非执行时取值；闭包形式 defer func(){...}() 则捕获变量引用，输出执行时的值；循环中若未用临时变量或闭包传参，易导致所有 defer 输出相同终值。
Go 语言里没有“延迟加载”这个标准术语，你实际想问的，大概率是 defer 的误用、误解或执行反直觉行为。它常被新手当成“延迟执行的函数调用”，但真实机制远比这复杂——不搞清参数求值时机和执行阶段，轻则返回值被悄悄改掉，重则资源泄漏、goroutine 堆积、线上服务雪崩。
defer 参数在注册时就求值并拷贝
这是最隐蔽也最常踩的坑：你以为 defer 是“等函数快退出时才取变量值”，其实不是。defer 后面那条语句里的所有参数，在 defer 语句被执行（即解析）的那一刻就完成了求值和拷贝。
- 比如
defer fmt.Println(x)，x 的当前值立刻被读取并存进 defer 记录里，后续 x 再变，不影响这次 defer 输出 - 但
defer func() { fmt.Println(x) }()就不同：闭包捕获的是变量x的引用，不是值；最终输出的是函数真正执行时的x值 - 循环中写
for i := 0; i ，输出是 <code>3 3 3，因为i在循环结束时是 3，而参数是注册时求值的
修复方式统一：显式传参，defer fmt.Println(i) 或 defer func(n int) { fmt.Println(n) }(i)。
defer 在命名返回值赋值后、返回前执行
很多人以为 defer 是“函数末尾才跑”，结果发现 return 后还能改返回值，一脸懵。这是因为 Go 函数返回分三步：赋值 → 执行 defer → 交出返回值。命名返回值（如 func() (err error)）的变量在第一步就被创建，defer 可以直接修改它。
立即学习“go语言免费学习笔记（深入）”；
-
func f() (x int) { x = 1; defer func() { x = 2 }(); return }返回 2，不是 1 - 匿名返回值（
func() int）没命名变量，defer 无法修改已计算好的临时返回值 - 别在 defer 里改返回值来“兜底”，逻辑易混淆；真要兜底，用普通 if/else 或提前 return 更清晰
循环里裸写 defer 导致 goroutine 泄漏
这不是 defer 本身的问题，而是使用场景错配。HTTP handler、批量任务循环中写 defer db.Close() 或 defer mu.Unlock()，会导致大量 defer 被堆积到函数栈上，直到整个函数返回才集中执行——而这类函数可能长期运行（比如处理完一批请求才 return），中间的资源根本没释放。
- 典型表现：数据库连接池耗尽、文件句柄数飙高、mutex 长期被占
- 正确做法：把需要延迟释放的逻辑封装成独立函数，或改用作用域更小的块，例如
{ f := openFile(); defer f.Close(); use(f) } - 尤其注意 HTTP handler 中，每个请求应有独立生命周期，绝不能让 defer 累积到 handler 函数退出才执行
defer 不是资源管理银弹，别替代显式控制
defer 简洁，但掩盖了资源生命周期的真实边界。当资源释放依赖条件判断、错误分支或并发协调时，硬塞 defer 反而让逻辑更脆弱。
- 比如
if err != nil { defer f.Close() }是无效的：defer 总会注册，不会因 if 失败跳过 - 多个 defer 注册同一资源（如两次
defer f.Close()），第二次会 panic（file already closed） - goroutine 内部用 defer 关 channel 或 cancel context，但外层没等它结束，照样泄漏
- 真正健壮的做法：明确资源获取与释放的配对点，优先用结构化作用域（
{}块）、显式 error 检查、context 控制，defer 只作为兜底补充
最关键的细节往往藏在“执行时机”和“参数求值”这两个交叉点上——它们不报错、不告警，测试难覆盖，上线后才突然爆发。写 defer 前，先问自己一句：这个值现在取对吗？这个资源真的在这个函数退出时才该释放吗？
