ReadMessage返回websocket.CloseAbnormalClosure(1006)时必须立即停止读写、同步调用conn.Close()并退出goroutine，因这是TCP彻底断开而非半关闭，服务端收不到关闭帧，继续操作将导致panic或资源泄漏。
ReadMessage返回websocket.CloseAbnormalClosure(1006)时必须立刻关闭连接
这不是半关闭，是TCP连接已彻底断开——websocket.CloseAbnormalClosure（1006）只表示底层连接不可用，协议层无法完成握手。浏览器关页、Nginx超时、手机切后台都会触发它，服务端收不到任何关闭帧，也就谈不上“读端关闭、写端可用”。
常见错误现象：read: connection closed 或 use of closed network connection 与 1006 同时出现；后续还调 conn.WriteMessage() 导致 panic。
- 收到非 nil
err后，第一行必须是websocket.IsCloseError(err, websocket.CloseAbnormalClosure)，否则漏判 - 确认是 1006 后，立即停止所有读写操作，不再调
ReadMessage()或WriteMessage() - 必须同步调用
conn.Close()，不能依赖defer conn.Close()—— WebSocket 长连接的 goroutine 不会退出，defer 根本不执行 - 关闭前可选发
conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(...))，但失败就跳过，别阻塞
gorilla/websocket没有半关闭语义，别碰conn.CloseWrite()
conn.CloseWrite() 是 TCP 层操作，对 WebSocket 协议无效且危险：它不会发送合法 CloseMessage 帧，客户端只能等到超时后报 1006；服务端自己下次 ReadMessage() 也会立刻返回 read: connection closed，而非预期关闭码。
真正需要的是协议级握手，不是传输层控制。
- 不要用
conn.CloseWrite()模拟“只停读”或“只停写” - 想暂停接收消息，应改用
context.WithCancel()控制读循环，而不是动底层连接 - 若真需单向终止写入（极少见），也必须配合心跳/超时机制，继续读直到
io.EOF或 deadline 超时
不主动Close()会导致fd和goroutine持续泄漏
每个 WebSocket 连接占用一个文件描述符（fd），Linux 默认每进程最多 1024 个。若每次断连都不调 conn.Close()，几十次重连后就会卡在 dial: too many open files。
更隐蔽的问题是 goroutine 泄漏：读 goroutine、写 goroutine、心跳 goroutine 常共用一个 conn，但生命周期不同步。一个挂了，另一个可能还在往已关闭的 conn 发 PingMessage，刷屏 use of closed network connection。
- 必须在检测到断连（如
ReadMessage()报错）后，**同步调用conn.Close()** - 若多个 goroutine 共享该连接，需用
sync.Once或 channel 确保只关一次 - 关闭后，所有基于该
conn的 goroutine 必须退出，不能靠“等下一次读错再处理” - 验证是否泄漏：运行
lsof -p $(pidof yourapp)实时观察 fd 数量
如何区分1005、1006和正常关闭帧
Go 里没有 CloseStatus 类型，所有关闭信息都藏在 error 里。不能靠字符串匹配 err.Error()，必须用 websocket.IsCloseError() 判断。
websocket.CloseNoStatusReceived（1005）表示客户端没发关闭帧就断开了（如直接关浏览器标签）；websocket.CloseAbnormalClosure（1006）是协议兜底，表示 TCP 已断；只有你或客户端主动发 CloseMessage，才会得到 CloseNormalClosure（1000）或 CloseGoingAway（1001）。
- 判断顺序不能错：先
err == nil→ 正常；再websocket.IsUnexpectedCloseError(err)（含 1006、1011）→ 异常断连，立即清理；最后websocket.IsCloseError(err, ...)→ 合法关闭帧，可回应 - 回应关闭帧必须在当次函数调用内完成：
conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, ""))，然后return -
websocket.FormatCloseMessage()的原因字符串长度不能超 123 字节，否则截断或触发ErrBadWrite
最易被忽略的一点：你写的“关闭逻辑”往往只覆盖了读 goroutine，而忘了停掉心跳 goroutine 和写 goroutine。它们共享同一个 conn，但没人通知它们“连接已经关了”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
