defer 在 for 循环中注册会导致 defer 链表爆炸，每次迭代追加节点且延迟至函数结束才执行，10 万次循环即注册 10 万个 deferred 调用，引发栈溢出或堆内存激增；闭包捕获循环变量还会导致对象无法回收。
defer 在 for 循环里注册会导致 defer 链表爆炸
每次迭代执行 defer，Go 运行时都会在当前函数的私有 defer 链表中追加一个节点。这个链表不会在循环结束时清空，而是等到整个函数 return 或 panic 时才统一执行——也就是说，10 万次循环就注册 10 万个 deferred 调用。
后果很直接：runtime: goroutine stack exceeds 1000000000-byte limit panic，或 pprof 显示大量 runtime.deferproc 占用堆内存。这不是 GC 慢，是 defer 结构体本身在堆上持续分配且无法提前释放。
- 高频网络包处理、日志批量写入、数据库批量查询等场景最容易触发
- 用
go tool trace查看 trace 文件，若 “deferproc” 事件密集出现，就是信号 - 避免在每轮循环都调用
defer f.Close()、defer os.Remove()这类操作
闭包捕获循环变量导致所有 defer 共享同一值
写 for _, v := range items { defer fmt.Println(v) }，输出全是最后一个 v 的值。因为 v 是循环变量，地址不变，所有闭包捕获的是同一个指针。
更危险的是它会钉住整个对象：比如 v 是 *http.Request，那 v.Body 底层数组、v.Header、TLS 连接全被持有，GC 完全无法回收，直到外层函数结束。
立即学习“go语言免费学习笔记（深入）”；
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 正确做法是显式传参：
defer func(x string) { fmt.Println(x) }(v) - 或创建局部副本：
val := v; defer fmt.Println(val) - 若只用字段（如
v.Name），优先提取后再传：name := v.Name; defer log.Println(name)
HTTP client 循环中 defer resp.Body.Close() 是典型 OOM 原因
这段代码在压测中极易崩溃：
for i := 0; i < 100000; i++ {
resp, _ := http.Get(url)
defer resp.Body.Close() // ❌ 错误：全部延迟到函数末尾
}
实际效果是：10 万个未关闭的 resp.Body 同时驻留内存，文件描述符耗尽，pprof 显示 net/http.(*persistConn).readLoop 占用飙升。
- 立刻关闭才是正解：
resp, err := http.Get(url); if err != nil { ... }; defer resp.Body.Close()—— 注意这行必须紧贴http.Get后，不在循环体内 - 若需批量请求，改用单次
http.Client复用 + 并发控制（如semaphore），而不是在循环里反复Get+defer - 永远不要在循环内写
defer *something.Close()，除非你明确知道该资源生命周期覆盖整个函数
defer 不适合替代同步清理逻辑
defer 的设计目标是“配对式资源管理”（open/close、lock/unlock），不是“批量异步收尾”。把它塞进循环，本质是误用了它的作用域绑定机制——它绑定的是函数，不是 for 语句块。
- 循环中启动 goroutine 并
defer cancel()：cancel 可能在 goroutine 启动前就被调用，导致误杀 - HTTP handler 里
defer http.Error()：错误响应被延迟，客户端早断连了 - 大 buffer 分配后
defer _ = buf：buf 一直悬空，内存不释放 - 真正该做的：用
slice记录待清理资源，循环结束后遍历调用Close()；或把单次迭代逻辑抽成子函数，在子函数内用defer
最常被忽略的一点：defer 的生命周期完全由外层函数控制，和循环体毫无关系。哪怕你在 for 里写了 100 行 defer，它们也只属于那个函数栈帧——这点和 JavaScript 的 microtask 或 Python 的 __del__ 逻辑完全不同，得按 Go 的 runtime 调度模型来想。
