信令服务器仅中继offer、answer、candidate三类元数据，不处理音视频流或ice连接建立；选gorilla/websocket保障稳定性，须严格校验roomid/clientid字面一致性、过滤回传、防乱序重复，确保每条消息准确送达。
信令服务器不是“媒体服务器”，它不处理音视频流，也不参与ice连接建立——它只是把 offer、answer 和 candidate 这三类消息，在房间内客户端之间准确、有序、不重复地中继出去。用错库、漏清理、错发给自己，都会导致前端 setremotedescription 失败或 addicecandidate 报错。
gorilla/websocket 还是 gobwas/ws？别选轻量，选稳
两者都支持 WebSocket 协议，但生产环境必须选 gorilla/websocket：
-
WriteMessage和ReadMessage自动处理Ping/Pong，不用手动写心跳逻辑； -
SetWriteDeadline可设毫秒级超时，避免长连接卡死导致accept: too many open files； - 遇到
websocket: close 1006 (abnormal closure)时，错误堆栈能定位到具体 conn 实例，而gobwas/ws常只报io.EOF，无法区分是客户端断开还是代理静默 kill； -
net/http原生升级（Upgrade）不校验Sec-WebSocket-Key等头字段，某些 CDN 或反向代理会直接丢弃连接，且无日志提示。
register 消息反复失败？检查 roomid/clientid 的“字面一致性”
前端发 {"cmd":"register","roomid":"abc","clientid":"u123"}，后端解析后必须原样存入 roomTable，不能做任何隐式转换：
- 不能调
strings.TrimSpace()—— 用户可能有意在 roomid 里带空格做命名分隔； - 不能转小写（如
strings.ToLower()）——clientid可能是 JWT sub 或 UUIDv4，大小写敏感； - 同一
clientid多次注册，必须先调deregister清旧连接，否则房间内出现“幽灵客户端”，后续send会转发给已断连的 goroutine，触发 panic； - 忘记启动
roomTable.CleanLoop()（如 AppRTC 中的go rt.cleanLoop()），超时房间不会释放，新用户register会卡在 map 查找或锁竞争上。
转发 send 消息时，为什么前端 RTCPeerConnection 卡死？
信令消息乱序、重复或发错对象，会直接让浏览器的连接状态机崩溃，常见现象包括 Failed to set remote offer sdp: Session error code: ERROR_CONTENT 或 addIceCandidate 报 TypeError：
- 必须加
if clientID != msg.FromID过滤，禁止把消息回传给发送方——否则setRemoteDescription被调两次，状态非法； -
offer和answer必须严格按顺序到达，建议在消息体加"seq": 1字段，接收端丢弃seq 的包； -
candidate消息必须验证msg.Candidate字段存在且非空字符串，空值会导致前端addIceCandidate拒绝执行； - 用
conn.WriteJSON(msg)替代json.Marshal() + conn.WriteMessage()，避免中间字节切片拷贝，也防止因 Marshal 错误（如含NaN浮点）导致 write 静默失败。
信令服务器不参与 ICE 连接建立，但必须配对正确
很多人以为信令服务器要“帮连通”，其实它只负责中继元数据。真正决定能否连上的，是前后端配置是否对齐：
- 前端
RTCPeerConnection的configuration.iceServers必须和后端 STUN/TURN 地址一致；本地开发可只用stun:stun.l.google.com:19302，但内网穿透失败时，必须上 TURN 并传username/credential； - 后端无需实现 STUN/TURN 逻辑，但若前端连的是你自建 TURN（如 coturn），需确保其监听地址可被客户端直连，且防火墙放行 UDP 3478/5349；
- 别试图用 Go 接收 TURN 流量再转发——TURN 本身已是中继，Go 层再中转等于双跳，延迟翻倍、丢包率上升；
-
pion/webrtc等库虽能在 Go 里跑 PeerConnection，但它只适合做 SFU/MCU 节点或测试模拟器，**不能替代前端浏览器的媒体采集与渲染能力**。
最常被忽略的一点：信令服务器的健壮性不取决于它多快，而在于它是否“从不转发错一条消息”。哪怕并发扛住 10 万连接，只要有一条 candidate 发漏了、或 offer 和 answer 顺序颠倒，前端就会卡在 connecting 状态，且几乎不报明确错误。
