用net/http而非gorilla/websocket因更轻量可控，自定义握手（如token校验）、避免路由冲突、sync.Map管理房间连接、json.RawMessage零拷贝透传、过滤无效ICE candidate提升NAT穿透效率。
为什么用 net/http 而不用 gorilla/websocket 做信令通道
信令服务器本质是转发 SDP 和 ICE candidate，不涉及媒体流，纯文本交换，HTTP + WebSocket 就够用。但直接用 net/http 自带的 Upgrade 处理 WebSocket 握手，比引入 gorilla/websocket 更轻量、更可控——尤其当你需要自定义握手逻辑（比如校验 token、绑定 room ID）时，gorilla 的封装反而会绕弯子。
常见错误：直接在 http.HandleFunc 里调 websocket.Upgrader.Upgrade 却没检查 Origin 或忽略 Content-Type 头，导致前端连不上或被中间代理拦截。
- 必须显式设置
Upgrader.CheckOrigin = func(r *http.Request) bool { return true }（仅开发环境），生产务必校验r.Header.Get("Origin")或 JWT - 避免复用全局
http.ServeMux，为信令路径单独注册 handler，防止路由冲突 - WebSocket 连接建立后，立即发
{"type":"welcome"}确认链路通，前端可据此触发本地RTCPeerConnection初始化
如何用 sync.Map 管理房间和连接而不锁死
每个房间（room ID）对应一组用户连接，高频增删查场景下，用 map[string][]*websocket.Conn 加 sync.RWMutex 容易成为瓶颈；而 sync.Map 对读多写少的信令场景更友好，但要注意它不支持原子性“读+写”操作（比如“若不存在则插入”）。
典型问题：两个客户端几乎同时加入同一房间，导致重复创建房间或漏广播 join 事件。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 房间存在性检查和插入必须用
LoadOrStore，值类型用*sync.Map（存 conn），而非直接存 slice - 不要在
sync.Map里存裸*websocket.Conn，包装一层带id、room、lastSeen的结构体，方便超时清理 - 广播消息时，遍历
sync.Map的Range方法是安全的，但需注意：遍历时 conn 可能已断开，必须用conn.WriteMessage的返回值判断是否存活
json.RawMessage 怎么避免反复序列化信令消息
信令消息类型杂（offer/answer/candidate）、字段动态（candidate 有 sdpMid/sdpMLineIndex 等可选字段），如果统一用 map[string]interface{} 解析，每次转发都要 json.Marshal → json.Unmarshal → json.Marshal，CPU 消耗明显。用 json.RawMessage 可以零拷贝透传原始字节。
容易踩的坑：前端发来含中文或特殊控制字符的 description，直接 json.RawMessage 转发却没做 UTF-8 校验，导致接收端解析失败。
- 接收时用
type SignalingMsg struct { Type string `json:"type"` Payload json.RawMessage `json:"payload"` } - 转发前只校验
Type字段合法性（如是否为"offer"、"candidate"），不碰Payload - 若需修改 payload（如注入 room ID），用
json.Unmarshal+map[string]interface{}局部处理，再json.Marshal回json.RawMessage
怎么让信令服务器支持 NAT 穿透所需的 ICE candidate 过滤
真实部署时，客户端常在内网，STUN 返回的 candidate 包含 host/candidate 类型，但服务端不需要处理 host candidate（它们无法被外网访问），只应透传 srflx（经 STUN 映射）和 relay（TURN）类型。
错误做法：把所有 candidate 原样转发，导致远端 RTCPeerConnection 尝试连接无效的内网地址，报错 ICE connection failed。
- 解析 candidate 字符串用
ice.UnmarshalCandidate（来自pion/ice库），别手写正则 - 过滤条件：只保留
c.Type == ice.CandidateTypeSrflx || c.Type == ice.CandidateTypeRelay - 注意：某些企业 NAT 会改写 candidate 的 IP，需配合 STUN server 日志交叉验证 candidate 是否真实可达
信令本身不参与 NAT 打洞，但它转发的 candidate 必须干净——少一条无效 candidate，就少一次无谓的连接尝试，首帧延迟可能降低几百毫秒。
