go不能直接运行webrtc信令和媒体流，仅能作为信令服务器、sfu/mcu转发节点或数据通道中继；需依赖前端处理音视频采集与渲染，核心编解码及传输由浏览器原生实现。
Go 能不能直接跑 WebRTC 信令和媒体流？
不能。WebRTC 的核心（音视频编解码、网络传输、ICE/STUN/TURN 协商）在浏览器端由原生实现，Go 没有内置的媒体栈支持。你用 github.com/pion/webrtc 这类库，也只是在 Go 里复现了 WebRTC 的协议逻辑（如 SDP 解析、DTLS 握手、RTP 封包），但不处理摄像头/麦克风采集或屏幕渲染——这些必须交给前端。
所以 Go 在 WebRTC 架构里只承担三类角色：信令服务器、SFU/MCU 转发节点、或纯数据通道中继。别指望它“自己推流”或“直接播放视频”。
用 pion/webrtc 实现信令服务的关键点
信令不是 WebRTC 标准的一部分，但没它连不上。Go 常用 gorilla/websocket 搭配 pion/webrtc 做 WebSocket 信令通道。常见错误是把 SDP 和 ICE 候选者当成普通消息乱发，导致协商失败。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必须严格区分消息类型：用字段如
"type": "offer"或"type": "candidate"标识，前端和 Go 后端要约定一致 - ICE 候选者必须逐条发送（不能合并进 offer），且要在
pc.OnICECandidate回调里触发发送，否则对方收不到 - 注意
webrtc.Configuration中的ICEServers：本地开发可只配stun:stun.l.google.com:19302，但内网穿透失败时，必须上 TURN（比如turn:your-turn-server:3478）并传用户名/密码 - 不要在
OnTrack回调里直接读rtpReader.Read()——它会阻塞；改用rtpReader.ReadStream()配合 goroutine 处理
为什么不用 Go 写 SFU？真要写得注意什么
用 Go 写 SFU（选择性转发单元）可行，pion/ion-sfu 就是例子，但性能敏感点很多。不是所有场景都适合：小规模 1 对 1 信令就够了；超过 5 路以上 720p 视频转发，Go 的 GC 和内存拷贝容易成瓶颈。
- 避免深拷贝 RTP 包：
pkt.Clone()看似安全，实则分配新内存；优先用pkt.Payload的切片视图做零拷贝转发 - 每个
PeerConnection默认启用RTCPeerConnectionState监听，但状态变更频繁（如connected→connecting→connected）可能触发大量 goroutine，建议加限流或 debounce -
OnTrack回调拿到的*webrtc.TrackRemote是只读的，转发前需调用track.ReadRTP()拉数据，别误以为能像 WebSocket 那样“推送” - TURN 流量走 Go 服务中转？别这么做。TURN 本身已是中继，再让 Go 接收再转发，等于双跳，延迟翻倍还增加丢包概率
前端连不上 Go 信令服务？先查这三件事
90% 的连接失败跟跨域、协议或证书无关，而是基础配置漏掉。
- 检查 WebSocket 地址是否带
wss://：Chrome 强制要求 HTTPS 页面只能连 WSS，HTTP 页面连 WS；混合协议会静默失败，控制台只报WebSocket connection to 'ws://...' failed - 确认
http.Serve是否启用了 CORS：即使信令不涉及 HTTP 请求，WebSocket 握手仍是 HTTP Upgrade 请求，没配Access-Control-Allow-Origin会导致 403 - 看
webrtc.PeerConnection创建时的Configuration：如果 Go 服务监听在0.0.0.0:8080，但前端连的是localhost:8080，STUN 返回的公网 IP 候选者可能无法回连，此时要配iceTransportPolicy: "relay"强制走 TURN
WebRTC 的坑不在代码行数，而在路径选择——比如该用信令就别硬上 SFU，该配 TURN 就别卡在 STUN 上反复调试。真正难的是判断哪一层出了问题，而不是怎么写那几行 pc.SetRemoteDescription()。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
