go中for循环变量复用内存地址，匿名函数直接捕获i会导致所有闭包共享同一地址，执行时全输出最终值且阻碍内存回收。
循环中直接捕获 i 导致所有闭包共享同一地址
Go 的 for 循环变量复用内存地址，不是每次迭代新建变量。匿名函数若直接引用 i，所有闭包实际指向同一个堆地址——哪怕你创建了 100 个闭包，它们都钉住同一个 i 及其引用的全部对象。
- 现象：闭包执行时全输出最终值（如全是
10），且i所在栈帧无法回收，连带它引用的大切片、结构体也被长期驻留 - 错误写法：
for i := 0; i - 正确写法：必须在循环体内显式创建副本 ——
for i := 0; i - 注意：
go func(i int) { ... }(i)仅适用于立即启动 goroutine；若闭包要存起来延后调用（比如注册进中间件链），仍需i := i方式
defer 中闭包隐式捕获 req 或 body 延迟释放
defer func() { ... }() 这种写法会让闭包无差别捕获当前作用域所有变量，包括 req *http.Request、已读取的 body []byte、大 map 等。这些对象生命周期被强制延长到函数返回之后，而 defer 又在函数末尾才执行，中间整段执行时间里它们全被钉在堆上，GC 完全无能为力。
- 错误写法：
defer func() { log.Printf("path: %s", req.URL.Path) }()→ 整个req被持有，哪怕只用了其中一个小字段 - 正确写法：
defer func(r *http.Request) { log.Printf("path: %s", r.URL.Path) }(req)→ 显式传参，避免隐式捕获 - 特别危险：
defer func() { ioutil.ReadAll(req.Body) }()→ 若req.Body已被读取为大[]byte，整个底层数组会被锁死 - 更稳妥做法：提前读取并转为小结构体再传入，或直接关闭
req.Body后再 defer
全局注册表存储闭包且无注销机制
把闭包塞进 map[string]func() 或 sync.Map 看似无害，但一旦注册后永不清理，闭包所捕获的上下文（如数据库连接、配置结构体、甚至整个 *http.Request）就永久滞留内存。
- 典型场景：插件系统、事件总线、中间件链注册、自定义指标上报回调
- 风险点不在闭包本身，而在它捕获的“短命对象”——比如 handler 里捕获了
ctx和user，注册进全局eventHandlers，后续无人调用Unregister - 必须配套设计注销接口，并在资源生命周期结束时显式调用
- 避免用
unsafe或反射绕过引用计数；注册时优先传值或 ID，而非直接捕获指针
goroutine 启动时闭包捕获 req 却未监听 ctx.Done()
HTTP handler 内起 goroutine 做异步日志或清理，若闭包直接引用 req 或 resp，又没绑定请求上下文，就会生成“孤儿 goroutine”——它可能比请求存活时间长十倍，持续持有 buffer、header map、TLS 连接等。
- 错误写法：
go func() { logReq(req) }()→req被闭包捕获，且无退出机制 - 正确写法：
go func(ctx context.Context, r *http.Request) { select { case - 所有阻塞操作（
ch 、<code>、<code>http.Do、db.QueryRow）都要放进select，且必含分支 -
cancel()必须在启动 goroutine 的作用域里defer或明确调用；漏掉这句，等于没加
*model.User 占比高但调用栈只显示 ServeHTTP，基本就是 handler 里某个 defer 或 goroutine 闭包在作祟。真正要盯的不是“分配了多少”，而是“谁拽着不放”。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
