信令服务器本质是带房间/客户端状态管理的WebSocket中继器，负责转发SDP和ICE候选等元数据，不参与音视频传输或ICE连接建立。
直接用 AppRTC Collider 或 LiveKit Server 就能跑起来，但如果你需要自定义逻辑、控制连接生命周期、或嵌入现有Go服务中，就得自己实现信令交换核心——它本质就是一个带房间/客户端状态管理的WebSocket中继器，不是“服务器”而是“消息路由器”。
WebSocket连接必须用gorilla/websocket还是gobwas/ws？
两者都能用，但选错会影响连接稳定性与错误处理粒度：
-
gorilla/websocket是事实标准，WriteMessage和ReadMessage自动处理 Ping/Pong，超时设置细（SetWriteDeadline可控到毫秒级），适合高并发长连接场景 -
gobwas/ws更轻量，但需手动处理心跳和关闭帧；在低配VPS上内存占用略低，但遇到websocket: close 1006 (abnormal closure)时调试困难 - 别用
net/http原生升级——它不校验 WebSocket 协议头，容易被中间代理静默断连
register 消息处理时，为什么客户端反复重连却进不了房间？
根本原因通常是 roomid 和 clientid 的一致性没对齐，或状态未及时清理：
- 前端发的
{"cmd":"register","roomid":"abc","clientid":"u123"}，后端解析后必须原样存入roomTable映射，不能做 trim() 或大小写转换 - 若同一
clientid多次注册，旧连接必须先deregister再允许新连接，否则房间内出现“幽灵客户端” - 忘记启动
roomTable.CleanLoop()（如 AppRTC 中的go rt.cleanLoop()），会导致超时房间堆积，新用户无法加入 - 检查是否在
wsHandler中漏掉了defer conn.Close()，导致 goroutine 泄漏，最终accept: too many open files
转发 send 消息时，如何避免广播风暴和消息乱序？
信令消息不是媒体流，但乱转或重复发会直接卡死前端 RTCPeerConnection 状态机：
- 只转发给同房间的**其他**客户端，不包括自己——用
if clientID != msg.FromID过滤，否则setRemoteDescription会被调两次 - SDP
offer和answer必须严格按顺序到达，建议加简单序列号（如"seq":1）并丢弃乱序包，避免Failed to set remote offer sdp: Session error code: ERROR_CONTENT - ICE candidate 消息体里带
"candidate":"candidate:..."字段，转发前务必验证该字段存在且非空，空 candidate 会导致addIceCandidate报TypeError: Failed to execute 'addIceCandidate' on 'RTCPeerConnection' - 不要用
json.Marshal后再WriteMessage——直接用conn.WriteJSON(msg)（gorilla提供），省去中间字节切片拷贝
最易被忽略的是：信令服务器本身不参与 ICE 连接建立，它只负责“把字符串从 A 传到 B”。一旦 SDP 交换完成、candidate 开始上报，后续所有网络路径选择、重传、回退都由浏览器或 Pion 等客户端库自行处理——信令层多一个换行、少一个引号，就可能让两个端永远卡在 checking 状态。
