defer在for循环中累积内存是因为每次迭代都注册独立defer，全部压入函数私有lifo栈并持有循环变量引用，直至函数返回才执行，导致gc无法及时回收且defer数量与迭代次数正相关。
defer 在 for 循环里为什么会累积内存？
因为 defer 不是立即执行，而是压入当前 goroutine 的 defer 链表，等函数 return 前统一执行。在循环中写 defer func() { ... }()，每次迭代都会注册一个新 deferred 函数，它们全部持有循环变量的引用（尤其是闭包捕获），直到外层函数结束才释放——这会导致内存无法及时回收，甚至 OOM。
为什么直接用 defer os.Remove(filename) 在循环里很危险？
常见误写：for _, filename := range files { defer os.Remove(filename) }。问题在于所有 os.Remove 都延迟到函数末尾才调用，且闭包捕获的是同一个 filename 变量地址，最终可能全删错文件，或因大量待执行 defer 占用栈和堆内存。
- 闭包捕获的是变量本身，不是值；循环结束后
filename已是最后一个值 -
defer数量 = 迭代次数，10 万次循环就注册 10 万个 deferred 调用 - 每个 deferred 函数都持有其捕获变量的指针，GC 无法回收相关对象
正确做法：显式复制变量 + 立即执行或分拆函数
核心原则：不让 defer 持有循环变量的引用，也不让它堆积。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用局部变量“快照”当前值：
for _, filename := range files { f := filename; defer func() { os.Remove(f) }() } - 更清晰的做法是封装成立即执行函数：
for _, filename := range files { func(name string) { defer os.Remove(name) }(filename) } - 如果操作耗时或需错误处理，干脆不用
defer，改用同步清理：err := os.Remove(filename); if err != nil { log.Printf("remove %s failed: %v", filename, err) }
哪些场景其实不该用 defer？
defer 适合资源配对（open/close、lock/unlock），不适合批量、异步或需及时释放的场景。
- 循环中打开多个文件并 defer close → 改为单次 open + 批量操作，或用
defer file.Close()在子函数内 - HTTP handler 里循环 defer http.Error → 错误应即时返回，defer 会延迟响应
- goroutine 内部 defer 日志记录 → 日志可能在 goroutine 结束后才打，丢失上下文
真正容易被忽略的是：defer 的生命周期绑定的是外层函数，不是循环体。哪怕你把 defer 写在 for 里，它也只属于那个函数作用域——这点和 JavaScript 的 event loop 或 Python 的 __del__ 完全不同，得按 Go 的调度模型来想。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
