Go不能直接实现WebRTC点对点通信，因其缺乏对DTLS/SCTP/ICE/STUN/TURN/SDP协商、音视频编解码、NAT穿透等底层能力的支持，官方标准库及主流生态无生产就绪的libwebrtc绑定，pion/webrtc仅支持作为一端Peer且需手动补全媒体栈。
Go 本身不直接提供 WebRTC 实现，webrtc 协议栈必须由客户端（浏览器或原生客户端）完成；Go 只能作为信令服务器或 SFU/MCU 的控制/转发层，不能替代 RTCPeerConnection。
为什么 Go 不能直接“实现 WebRTC 点对点通信”
WebRTC 的核心——DTLS/SCTP/ICE/STUN/TURN/SDP 协商、音视频编解码、NAT 穿透、拥塞控制——全部依赖底层 C/C++ 库（如 libwebrtc），而 Go 官方标准库和主流生态中没有完整绑定 libwebrtc 的成熟、生产就绪封装。社区有 pion/webrtc 这样的纯 Go 实现，但它只支持 *作为 WebRTC 的一端*（Peer），且仅限于数据通道（DataChannel）或简单媒体流转发，无法替代浏览器的完整媒体栈。
常见误解是“用 Go 写个服务就能让两个浏览器直连”，实际做不到：浏览器只能通过 RTCPeerConnection 与其他支持 WebRTC 的终端通信，Go 进程若不集成 libwebrtc（如通过 cgo 调用），就无法生成合法的 DTLS 证书、处理 SRTP 密钥交换、解析 RTP 包头或做 Jitter Buffer。
- 浏览器 ↔ 浏览器：可行，信令靠 Go 服务中转
- 浏览器 ↔ Go 进程：仅当 Go 进程使用
pion/webrtc并启用MediaEngine+ 编解码器注册（如opus,vp8），且自行处理音频采集/渲染（无 GUI 时需对接gstreamer或ffmpeg） - Go ↔ Go：可通，但双方都得用
pion/webrtc，且必须手动管理所有媒体管道，无浏览器自动能力（如自动回声消除、自适应比特率）
用 pion/webrtc 搭建最简 P2P 数据通道（无媒体）
这是 Go 中最稳定、文档最全的 WebRTC 入口场景：跳过音视频，专注信令 + DataChannel 文本/二进制消息传输。适合远程控制、实时协作白板、游戏状态同步等。
关键步骤：
- 初始化
webrtc.Configuration{}，至少配置ICEServers（哪怕只用stun:stun.l.google.com:19302） - 调用
webrtc.NewPeerConnection创建连接，监听OnICECandidate发送 candidate 到对端，监听OnICEConnectionStateChange判断是否 connected - 主动方调用
pc.CreateDataChannel，被动方在OnDataChannel回调里接收；双方都需在OnOpen后才能Send - SDP 协商必须严格遵循 offer/answer 流程：
pc.CreateOffer→pc.SetLocalDescription→ 发 offer → 对端pc.SetRemoteDescription→pc.CreateAnswer→ 回传 answer → 双方SetRemoteDescription
坑点：SetRemoteDescription 必须在 SetLocalDescription 之后调用，否则会 panic；candidate 必须按顺序送达（用 WebSocket 或 HTTP POST，别用 UDP）；DataChannel 默认是 unreliable（类似 UDP），如需可靠请设 DC.Init.Reliable = true。
浏览器信令服务器该怎么做（Go 实现）
信令本身无协议强制要求，但必须保证两件事：消息能路由到目标用户、状态可追踪。不要自己发明房间/用户模型，直接复用成熟结构。
- 用
gorilla/websocket建立长连接，每个连接绑定一个userID（如 JWT payload 中的 sub） - 收到
offer消息时，查出目标userID对应的 websocket 连接，直接WriteJSON推送；若对方离线，丢弃或存入 Redis 延迟投递（视业务而定） - 消息体建议固定字段：
{"type":"offer","from":"u123","to":"u456","sdp":"v=0..."}，避免嵌套过深导致前端解析失败 - 不要在信令中传 candidate 大量字符串——浏览器发 candidate 是流式、高频的，应聚合为数组批量发送，或改用
trickle: false关闭 trickle ICE，在 offer/answer 中一次性携带所有 candidate
性能注意：WebSocket 连接数上万时，gorilla 默认的 Upgrader.CheckOrigin 若不做白名单限制，可能被恶意 Origin 扫描拖垮；务必设 Upgrader.CheckOrigin = func(r *http.Request) bool { return r.Header.Get("Origin") == "https://your.app" }。
想传音视频？绕不开的三个硬坎
即使你坚持用 pion/webrtc 接音频/视频，下面三件事必须手动补全，没有捷径：
-
MediaEngine注册：默认不带任何编码器，必须显式调用m.RegisterCodec添加webrtc.RTPCodecCapability{MimeType: "audio/opus", ...}和video/vp8，否则CreateOffer生成的 SDP 不含媒体行 - 音频采集与播放：Go 无跨平台音频 API，Linux 需
ALSA，macOS 需CoreAudio，Windows 需WASAPI；pion/ion等项目用cgo封装了部分，但维护成本高、设备兼容性差 - RTP 包构造与消费：浏览器发来的 RTP 包需从
OnTrack回调拿到*webrtc.TrackRemote，再用Read循环读取裸 RTP 数据——你得自己解析 timestamp、SSRC、丢包重传逻辑；播放端则要写入音频设备缓冲区，延迟控制不好就会卡顿
真正落地的方案，几乎都把媒体处理交给浏览器或专用客户端（如 Electron + WebRTC），Go 只管信令和房间管理。强行在 Go 里拼凑媒体链路，调试周期远超预期，且无法享受浏览器持续更新的抗弱网能力。
