net/http原生连接管理更可靠，因Gin的Context绑定单次HTTP请求，响应写出后即关闭连接，无法支撑WebSocket长连接；必须绕过Gin，直接用http.HandleFunc注册升级逻辑，并手动管理conn生命周期、写超时、心跳与广播协程。
为什么用 net/http 原生连接管理比 Gin 中间件更可靠
Gin 本身不处理长连接，gin.Context 生命周期绑定单次 HTTP 请求，一旦响应写出，连接即关闭。聊天室依赖持续双向通信，必须绕过 Gin 的请求-响应模型，直接操作底层 http.ResponseWriter 和 *http.Request。常见错误是试图在中间件里调用 c.Writer.Flush() 或长期持有 c，结果连接被 Gin 自动关闭或 goroutine 泄漏。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 注册路由时用
http.HandleFunc直接挂载 WebSocket 升级逻辑（如/ws），不要走router.GET("/ws", handler) - 升级前务必检查
Origin头防跨站滥用，用gorilla/websocket的CheckOrigin回调或手动校验 - 升级成功后立即调用
conn.Close()在 defer 中，避免未关闭连接堆积
如何安全地广播消息而不阻塞写入协程
多个客户端并发写入时，若直接遍历所有 *websocket.Conn 并调用 WriteMessage，某个慢连接会拖慢整个广播，甚至导致其他客户端超时断开。这不是 Gin 的问题，而是 WebSocket 连接本身的写阻塞特性。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 为每个连接启动独立的写协程，读协程只负责接收消息并推入该连接专属的
chan []byte - 使用带缓冲的 channel（如
make(chan []byte, 64)），避免发送方因接收方卡住而阻塞 - 广播时向每个连接的 channel 发送消息副本，而非复用同一份字节切片——防止前一个连接修改影响后一个
- 在写协程中捕获
websocket.IsCloseError和io.EOF，主动退出并清理连接
gorilla/websocket 的 WriteDeadline 必须设，且不能只设一次
很多实现漏掉写超时控制，导致网络中断后连接长期滞留，服务端内存和文件描述符缓慢泄漏。Gin 不参与这个过程，超时必须由 WebSocket 库显式管理。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每次调用
conn.WriteMessage前，必须设置conn.SetWriteDeadline(time.Now().Add(10 * time.Second)) - 不要在连接建立时只设一次——写操作可能间隔很久，需每次动态更新
- 若使用 ping/pong 心跳，也要对
SetPingHandler设置对应的读超时（SetReadDeadline） - 超时触发后，
WriteMessage会返回net.ErrDeadlineExceeded，此时应关闭连接
客户端重连时如何避免重复加入房间或消息丢失
纯内存管理的房间结构（如 map[string][]*websocket.Conn）无法感知客户端是否已重连。用户刷新页面后新建连接，旧连接尚未超时关闭，导致同一人占两个 slot，广播重复；同时断线期间的消息也无法补发。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 给每个连接分配唯一
clientID（如 UUID），由客户端在首次连接时带上，服务端按 ID 踢除旧连接 - 房间结构改用
map[string]map[string]*Client，外层是 room 名，内层是 clientID 到*Client结构体指针，含连接、最后活跃时间、消息游标等字段 - 不实现服务端消息持久化，但可在内存中为每个 client 维护最近 20 条消息的环形缓冲（
[]string+head/tail索引），重连时按游标推送 - 禁止用 Gin 的
c.Param("room")解析房间名——WebSocket 升级请求是 GET，但参数应从 URL 查询字符串解析，用req.URL.Query().Get("room")
真正麻烦的是连接状态与业务状态的对齐：比如用户 A 断线 30 秒后重连，B 在这期间发了 5 条消息，A 是否该看到？这取决于产品定义，但技术上必须明确选择“丢弃”还是“缓存”，不能默认忽略。
