html5 webrtc视频流传输需经历设备采集、连接协商、网络穿透、媒体流转四步；本地捕获须显式约束、区分错误、用srcobject；rtcpeerconnection需stun/turn配置、addtrack、状态监听；信令交换是必经桥梁，需有序传递offer/answer及candidate；远端渲染应监听ontrack、动态反馈网络与状态。
HTML5 WebRTC 视频流捕获与传输不是“打开摄像头就能发”，而是由设备采集、连接协商、网络穿透、媒体流转四步紧密咬合构成的技术链。其中任何一环配置不当，都会导致黑屏、无声音、连接失败或高延迟。
本地视频流捕获要兼顾兼容性与控制力
现代浏览器统一使用 navigator.mediaDevices.getUserMedia() 获取流，但实际使用中需注意：
- 必须显式声明约束条件，例如
{ video: { width: 1280, height: 720, frameRate: 30 }, audio: true }，避免默认低分辨率或静音拒绝； - 权限拒绝（
NotAllowedError）和设备占用（NotFoundError）要区分提示，不能只依赖catch打印错误； -
srcObject是唯一推荐写法，URL.createObjectURL()已废弃，且存在内存泄漏风险； - 移动端需额外处理横竖屏适配与自动播放策略（iOS Safari 要求
playsinline+ 用户手势触发）。
RTCPeerConnection 配置决定连接成败
这个对象是 WebRTC 的中枢，不是“创建即连通”，它的初始化和生命周期管理直接影响 P2P 是否能真正建立：
使用HTML,CSS,JavaScript开发Android应用程序 英文文字pdf版附源文件
下载
如果你了解HTML，CSS和JavaScript，您已经拥有所需的工具开发Android应用程序。本动手本书展示了如何使用这些开源web标准设计和建造，可适应任何Android设备的应用程序 - 无需使用Java。您将学习如何创建一个在您选择的平台的Android友好的网络应用程序，然后转换与自由PhoneGap框架到一个原生的Android应用程序。了解为什么设备无关的移动应用是未来的潮流，并开始构建应用程序，提供更
- ICE 服务器至少配一个 STUN（如
stun:stun.l.google.com:19302），否则内网用户几乎无法发现彼此； - 仅靠 STUN 不足以穿透对称型 NAT，生产环境必须部署 TURN 服务（如 coTURN），并加入配置；
- 添加轨道用
addTrack(track, stream)，比旧式addStream()更精细，支持单独禁用音频/视频轨道； - 务必监听
iceConnectionState和connectionState，用于判断连接是否真正就绪（"connected"或"completed"），而非仅靠ontrack触发就认为已通。
信令交换不是可选模块，而是必经桥梁
两个浏览器彼此“不认识”，无法直接通信，必须通过第三方信令通道协调连接参数：
- 发起方调用
createOffer()→setLocalDescription()→ 发送 offer 给对方； - 接收方收到后先
setRemoteDescription(offer)→createAnswer()→setLocalDescription(answer)→ 发回 answer； - 双方持续监听
onicecandidate，把每个非空 candidate 通过 WebSocket 或其他方式实时转发给对方； - 信令本身无标准协议，可用 Socket.IO、SSE 或自研轻量 HTTP 接口，关键是保证消息有序、不丢失、有超时重试机制。
远端流渲染与状态反馈要面向用户体验
连接成功只是开始，稳定呈现和及时反馈才是可用性的关键：
- 监听
ontrack（不是已废弃的onaddstream），它按轨道触发，适配单流或多流场景； -
event.streams[0]即为远端 MediaStream，直接赋给remoteVideo.srcObject； - 建议叠加加载状态（如 spinner）、静音/关闭摄像头图标、网络质量指示（基于
getStats()中的bytesReceived、packetsLost等指标）； - 断连时主动触发
close()并清理srcObject = null，防止残留流占用设备。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
