WebRTC实现点对点视频通话需理清三件事:本地音视频获取、两端连接建立、信令服务器传话;媒体流走P2P,信令必须经服务器。

WebRTC 实现浏览器间点对点视频通话,核心不是“写完就能通”,而是理清三件事:本地音视频怎么拿、两端怎么连上、中间谁来传话。它不依赖插件,但离不开服务端辅助——媒体流走 P2P,信令必须走服务器。
第一步:获取并显示本地音视频流
用 getUserMedia 请求摄像头和麦克风权限,拿到 MediaStream 后直接赋给 video 元素:
- 必须在 HTTPS 或 localhost 环境下运行,否则
navigator.mediaDevices为 undefined - 推荐显式声明约束,比如
{ video: true, audio: true };如只需视频,可设audio: false - 捕获失败时要处理拒绝权限或设备不可用的情况,避免静默失败
- 示例代码:
const stream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true });<br>document.getElementById('local-video').srcObject = stream;
第二步:创建并配置 RTCPeerConnection
RTCPeerConnection 是连接的中枢,负责协商、加密、NAT 穿透和传输。关键在于正确配置 ICE 服务器:
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图,自动匹配视觉风格。触发场景:文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 至少配一个公共 STUN 服务器(如
stun:stun.l.google.com:19302),用于获取公网 IP 和端口 - 若用户处于严苛 NAT 或企业防火墙后,需额外接入 TURN 服务器中转媒体流
- 创建实例时传入配置:
new RTCPeerConnection({ iceServers: [...] }) - 监听
onicecandidate事件,把生成的 ICE 候选地址通过信令发给对方 - 监听
ontrack事件,把远端流绑定到对应 video 元素:video.srcObject = event.streams[0]
第三步:借助信令服务器交换连接信息
两个浏览器彼此不知道对方地址和能力,必须靠第三方服务传递 SDP(会话描述)和 ICE 候选。这一步没有标准协议,常用 WebSocket 实现:
立即学习“前端免费学习笔记(深入)”;
- 发起方调用
createOffer()生成 offer,用setLocalDescription()保存,再通过信令发给接收方 - 接收方收到后,先用
setRemoteDescription(offer)解析,再调用createAnswer()回复 answer,并同样发回 - 双方各自设置对方的描述(
setRemoteDescription),连接即开始建立 - 消息类型建议区分:如
"offer"、"answer"、"candidate",便于前端路由处理
第四步:处理常见连通障碍
实际部署中,80% 的失败不在代码逻辑,而在网络环境:
- 本地测试可用
localhost,但跨设备必须走 HTTPS + 公网信令服务 - Chrome 和 Edge 默认支持良好;Safari 对
getDisplayMedia和某些编解码器有限制,需降级适配 - 移动端 iOS Safari 不支持后台音频播放,通话中切后台可能中断声音,需监听
visibilitychange提前处理 - 用户未交互前自动播放音频会被阻止,可引导点击按钮后再调用
startLocalAudio等方法


















