闭包是WebSocket连接处理中绑定长连接状态的关键载体，它通过捕获当前循环中的局部变量（如conn、clientID、hub指针）确保每个goroutine独享自身上下文，避免共享变量导致的竞态；必须轻量捕获、配defer清理、生命周期与连接严格对齐。
闭包不是语法糖，是长连接状态绑定的关键载体；它让每个连接的读写 goroutine 能安全持有 conn、id、hub 等上下文，而不是靠全局变量或传参硬编码。
为什么 WebSocket 连接处理必须用闭包包裹 goroutine
直接写 go readPump(conn) 会导致所有连接共享同一个 conn 变量（尤其是 for 循环中），最终所有 goroutine 都操作最后一个连接——这是 Go 新手最常踩的坑。闭包能捕获当前迭代的局部变量快照，确保每个连接独享自己的状态。
- 错误写法：
for _, conn := range conns { go handle(conn) }——conn是循环变量，地址不变，最后所有 goroutine 都拿到同一个值 - 正确写法：
for _, conn := range conns { go func(c *websocket.Conn) { handle(c) }(conn) }—— 显式传参，闭包捕获c的副本 - 更常用写法：
go func() { readPump(conn) }()—— 利用闭包隐式捕获当前作用域的conn，前提是conn是该次循环中声明的局部变量（如conn, _ := upgrader.Upgrade(...)）
闭包里该捕获什么，不该捕获什么
闭包要轻量、明确、可预测。捕获过多或错误的对象，会延长内存生命周期，甚至引发 goroutine 泄漏。
- 应该捕获：
conn（必须）、clientID（用于注册/广播）、hub指针（用于调用hub.register或hub.broadcast） - 避免捕获：
http.ResponseWriter（已随 handler 结束失效）、*http.Request（只在 upgrade 前有效）、大结构体或未清理的资源句柄 - 特别注意：不要在闭包里捕获整个
hub实例（而非指针），否则每次连接都会复制一份 map 和 mutex，既浪费内存又破坏并发安全
闭包 + defer + 错误恢复 = 安全退出路径
每个连接 goroutine 的闭包末尾必须有清晰的清理逻辑，而 defer 是唯一能保证执行的机制。但 defer 里的函数本身也是闭包，要注意变量捕获时机。
立即学习“go语言免费学习笔记（深入）”；
- 正确：
defer func() { hub.unregister(clientID) }()—— 捕获的是当前clientID的值，安全 - 危险：
defer hub.unregister(clientID)—— defer 时clientID还没赋值？或者被后续循环覆盖？行为不可控 - 必须搭配：
defer conn.Close()和recover()，防止 panic 导致连接残留；但recover()要放在闭包最外层，不能嵌套在子函数里
闭包变量生命周期与连接实际存活时间必须对齐
一个连接 goroutine 的闭包变量，其生命周期应严格等于该连接的存活期。一旦连接断开，闭包里所有变量都应自然释放——这要求你不能在闭包里意外引用外部长生命周期对象（比如全局 map 的 key 或 channel）。
- 典型泄漏场景：闭包里启动另一个 goroutine 并向全局
logChan发送日志，但没做限流或缓冲，导致日志 goroutine 永远阻塞，连带整个闭包无法退出 - 调试技巧：用
runtime.NumGoroutine()对比连接数，若持续上涨，大概率是闭包里 goroutine 没退出 - 关键判断点：只要
conn.ReadMessage()返回非io.EOF错误（比如websocket.ErrCloseSent），就该立刻 break 循环并让闭包结束——别等超时，别靠心跳“发现”断连
闭包本身不解决并发问题，但它决定了状态绑定的粒度；真正决定连接是否可靠的是：你捕获了什么、何时释放、以及有没有让 goroutine 在连接终止那一刻真正停下来。
