websocket连接需在upgrade成功后立即通过url参数（如/ws?room=general）解析roomid，并用sync.map维护roomid→连接映射；须校验roomid合法性，断连时及时清理，广播采用带缓冲channel+专属goroutine串行推送，辅以心跳、读写超时三重机制判定连接状态。
WS连接怎么绑定到房间ID
Iris 默认不提供房间管理，得自己用 sync.Map 或 map[roomID]map[*websocket.Conn]bool 维护。关键不是存连接，而是确保每个连接在建立时就明确归属——比如从 URL query 提取 room 参数：/ws?room=general，然后在 websocket.Handler 里解析并注册。
常见错误是把房间 ID 存在 HTTP session 或中间件变量里，但 WebSocket 升级后这些上下文就丢了。必须在 Upgrade 成功后的第一个 ReadMessage 前完成绑定，否则收发消息时找不到归属房间。
- 用
ctx.URLParam("room")或ctx.Request().URL.Query().Get("room")获取房间 ID - 注册前检查
roomID是否为空或含非法字符（如/、..），避免 map key 污染 - 连接断开时务必从对应房间的连接池中
delete，否则内存泄漏 + 广播发给已断连的 conn
群聊广播为什么只推了一半人
根本原因是并发读写 map 导致 panic 或跳过某些连接，或者广播循环中对某个 *websocket.Conn 调用 WriteMessage 失败后没 continue，直接 break 了整个循环。
Iris 的 websocket.Conn 不是线程安全的，多个 goroutine 同时写同一连接会 panic；而向不同连接广播时，又需要遍历房间内所有连接——这两者必须隔离。
- 广播前对房间连接集合做一次浅拷贝（
for conn := range roomConns { ... }是安全的，但前提是roomConns是map[*websocket.Conn]bool且未被其他 goroutine 修改） - 每次
conn.WriteMessage都要加defer func() { recover() }()或显式检查 error，失败就delete该 conn 并 continue - 别在广播循环里调用阻塞操作（如数据库查询、HTTP 请求），否则拖慢整个房间推送
怎么让广播不卡住新连接接入
广播逻辑如果写在主线程（比如 HTTP handler 里同步执行），会阻塞后续请求；如果全丢进 goroutine 又可能丢失顺序或引发竞态。正确做法是为每个房间配一个带缓冲的 channel，把消息塞进去，由专属 goroutine 串行消费并广播。
这样新连接的 Upgrade 完全不受广播耗时影响，且能自然实现“消息队列”语义——哪怕广播慢，消息也不会丢（只要 channel 缓冲够大）。
- 每个房间启动一个长期运行的 goroutine：
go func() { for msg := range roomMsgCh { broadcastToRoom(roomID, msg) } }() -
roomMsgCh类型设为chan []byte，避免序列化开销；发送方统一用json.Marshal后写入 - channel 缓冲大小建议设为 128 或 256，太小容易阻塞发送方，太大占用内存且延迟上升
客户端断连后服务端怎么及时清理
靠心跳检测最稳。Iris 的 websocket.Conn 支持 SetPingHandler 和 SetPongHandler，但默认不启用。不主动 ping，TCP 连接可能数分钟才因 keepalive 超时断开，期间房间里还留着个“幽灵连接”。
别依赖 ReadMessage 返回 io.EOF——它往往来得太晚；也别只靠 defer 删除连接，因为 panic 或进程 kill 时 defer 不一定执行。
- 连接建立后立即启动定时器：每 20 秒
conn.WriteMessage(websocket.PingMessage, nil) - 设置
conn.SetReadDeadline(time.Now().Add(30 * time.Second))，并在每次ReadMessage前刷新 - 在
PingHandler里记录最后活跃时间，广播前过滤掉超过 45 秒无响应的 conn
Iris 没有开箱即用的房间抽象，所有“群聊感”都来自你对连接生命周期和消息分发节奏的控制。最容易被忽略的是：广播失败不等于连接已死，得结合心跳+read deadline+write error 三重判断才算真正离线。
