循环中直接写 defer 会堆积资源，直到函数退出才释放，导致内存泄漏和文件描述符耗尽；应使用立即执行函数或显式 close 控制作用域并及时释放资源。
循环里直接写 defer 会堆积资源，直到函数退出才释放——这是内存泄漏和文件描述符耗尽的常见源头。
为什么循环中 defer file.Close() 会泄漏资源
每个 defer 都注册到当前函数的 defer 栈，不是“执行完这轮循环就关”，而是全部压栈、等整个函数 return 才统一弹出。比如打开 100 个文件，defer file.Close() 就注册 100 次，但所有 file 句柄在函数结束前都保持打开状态。
- 操作系统级资源（文件描述符、网络连接、数据库连接）不会自动回收，只靠 GC 无法释放
- Go 运行时不主动限制 defer 栈大小，大量注册可能引发栈膨胀或延迟释放
- 错误日志里出现
too many open files或use of closed network connection往往就源于此
用立即执行函数（IIFE）控制 defer 作用域
把 defer 放进一个匿名函数里并立刻调用，让它绑定到本轮迭代的作用域，函数返回即触发 close。
for _, filename := range filenames {
func() {
file, err := os.Open(filename)
if err != nil {
log.Printf("open %s failed: %v", filename, err)
return
}
defer file.Close() // ← 这个 defer 属于内层函数，不是外层 for 所在函数
processFile(file)
}()
}
- 每次迭代都新建一个函数作用域，
defer在该作用域退出时执行 - 避免了变量捕获问题：
file是局部变量，不会被后续迭代覆盖 - 注意：不能用
go func() { ... }()替代，goroutine 退出 ≠ 函数返回，defer不会触发
更推荐：显式 close + 错误检查
对高频或关键路径，直接调用 Close() 并处理 error，比依赖 defer 更可控、更易调试。
for _, url := range urls {
resp, err := http.Get(url)
if err != nil {
log.Printf("GET %s failed: %v", url, err)
continue
}
// 必须先 defer resp.Body.Close()，再读取 body，否则可能提前关闭
defer resp.Body.Close()
// ❌ 错误：这里 defer 属于外层函数，仍会累积
// ✅ 正确做法是手动 close：
body, err := io.ReadAll(resp.Body)
resp.Body.Close() // ← 立即释放
if err != nil {
log.Printf("read %s body failed: %v", url, err)
continue
}
processBody(body)
}
-
Close()可能返回 error（如写缓冲失败），defer无法捕获，容易掩盖问题 - HTTP 场景下，
resp.Body.Close()必须在读完后立刻调用，否则连接无法复用 - 简单逻辑下，显式调用比包装一层函数更轻量、更直观
闭包传参陷阱：i 值捕获必须显式传入
写 for i := 0; i 输出的是 <code>3 3 3，因为所有 defer 共享同一个变量 i 的地址，注册时没拷贝值。
- 正确方式一（参数传值）：
defer func(n int) { fmt.Println(n) }(i) - 正确方式二（局部副本）：
n := i; defer fmt.Println(n) - 错误方式（闭包捕获）：
defer func() { fmt.Println(i) }()→ 依然输出3 3 3 - 注意：只有值类型（
int、string）适合传值；如果是*os.File，传指针本身没问题，但别误以为能“捕获当时状态”
真正难处理的不是语法，而是资源生命周期和函数作用域的错位——defer 绑定的是函数，不是循环轮次；一旦忽略这点，哪怕代码编译通过，运行时也会悄悄吃掉系统资源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
