裸WebSocket无语义保障，需手动实现房间隔离、消息路由、状态同步与并发安全，否则易致信令丢失、乱序或安全漏洞。
直接用 gorilla/websocket 搭 WebSocket 信令服务是可行的，但必须手动处理房间隔离、消息广播范围、连接生命周期和状态同步——稍有疏忽就会出现“A发的消息B收不到”“用户重复加入”或“ICE候选丢失”这类问题。
为什么不能只用裸 WebSocket 处理信令
WebRTC 的信令不是简单转发字符串。SDP offer/answer 必须按顺序、按参与者配对处理；ICE candidate 需绑定到特定 PeerConnection；一个用户退出时，必须主动通知其他所有成员并清理其 track 状态。裸 WebSocket 不提供这些语义保障。
-
upgrader.CheckOrigin若设为return true，会暴露跨域攻击面，生产环境必须校验 Origin 或 Token - 用
map[string]*websocket.Conn存连接，没有并发安全保护，多 goroutine 写入会 panic - 广播逻辑若不跳过 sender 自身，会导致客户端收到自己刚发的 SDP，触发 WebRTC 的
InvalidStateError - 缺少心跳和超时机制，NAT 超时或网络抖动后连接假死，但服务端仍认为用户在线
Room + Participant 分层模型怎么落地
把“房间”抽象成结构体，而非全局 map，能自然隔离状态。每个 Room 实例持有自己的 sync.Map（键为 userID，值为封装了 conn 和元数据的 *Participant），避免跨房间干扰。
-
Participant结构里应包含conn *websocket.Conn、isPublisher bool、lastSeen time.Time，用于后续静音/踢人/自动剔除逻辑 - 进房时生成唯一
roomID（如uuid.NewString()），避免用用户传入的任意字符串做 key，防止路径遍历或哈希碰撞 - SDP 交换必须带
fromUserID和toUserID字段，服务端据此路由，而不是盲目广播给全房间 - ICE candidate 消息需附带
targetUserID，否则接收方无法知道该往哪个RTCPeerConnection上 add
如何避免信令消息乱序和丢失
WebSocket 本身不保证消息顺序？错。它基于 TCP，天然保序。但开发者常犯的错误是：在多个 goroutine 中并发调用 conn.WriteMessage()，导致写操作被调度器交错执行，最终帧粘连或截断。
- 每个
Participant应独占一个写协程（writePump），从私有 channel 读取消息，串行写出 —— 这是 Go 实现可靠信令的铁律 - 读协程（readPump）收到消息后，不直接广播，而是先解析 JSON，校验
type字段（如"offer"、"candidate"），再分发到对应逻辑，避免非法消息污染状态 - 对关键消息（如
offer）加简单重试：客户端发完后启动定时器，若 3s 内未收到answer，主动触发重发提示 - 禁用
WriteBufferPool或自定义 buffer，避免小消息被合并成大帧，导致浏览器端onmessage触发延迟
生产环境必须补上的三件事
本地跑通和上线稳定是两回事。最容易被跳过的点，恰恰是压测时最先崩的环节。
- 用
http.Server.ReadTimeout和WriteTimeout控制连接空闲时间，而不是依赖前端 ping/pong —— 后者可能被拦截或丢包 - 所有
json.Unmarshal必须检查 error，WebRTC 信令字段缺失（如漏掉iceUfrag）会导致 Chrome 直接拒绝 setRemoteDescription - 日志中记录每条信令的
roomID、from、type、size，出问题时才能快速定位是哪次 offer 卡住了，而不是翻几十万行无结构日志
信令服务器真正的复杂点不在协议解析，而在状态与连接的耦合管理：一个 Participant 的生命周期要横跨 WebSocket 连接、WebRTC PeerConnection、媒体 Track 发布/订阅、以及可能的后台权限校验。任何一环没对齐，都会表现为“画面卡住但音频正常”或“用户显示在线却收不到呼叫”。
