WebRTC本质是逻辑点对点通信，依赖STUN/TURN穿透NAT，但不绕过服务器；受安全上下文、主线程、自动播放策略及WebView兼容性限制；连不上主因ICE候选失败，需配STUN/TURN并确保信令可靠。
WebRTC 本质就是点对点，但“点对点”不等于“绕过服务器”
WebRTC 协议栈设计目标确实是建立浏览器之间的直接数据通道，RTCPeerConnection 的核心行为就是尝试 P2P 连接。但现实网络中，绝大多数用户处于 NAT 或防火墙后，无法直接互通，所以必须依赖 STUN/TURN 服务器协助穿透——这些服务器只参与连接建立（信令和 ICE 候选交换）和中继转发，并不解析或干预媒体流内容。也就是说：连接路径可能是 P2P，也可能是 relay，但整个通信模型仍被定义为“点对点”，因为没有中间代理重写或转封装流。
HTML 中调用 WebRTC 会触发哪些实际限制？
浏览器对 RTCPeerConnection 的使用施加了明确运行时约束，不是所有“能写 JS”的地方都能跑通：
-
getUserMedia()必须在安全上下文（https://或localhost）中调用，http://页面直接抛NotAllowedError -
RTCPeerConnection实例无法在非主线程（如 Web Worker）中创建，new RTCPeerConnection()会报DOMException: Failed to construct 'RTCPeerConnection': Not supported in this context' - 自动播放策略影响
video元素：即使srcObject已绑定MediaStream，未与用户手势（如click）关联的play()调用大概率静音或被暂停 - 部分 Android WebView（尤其旧版）不支持
RTCRtpSender.replaceTrack()或对 H.264 编码支持不完整，需降级到 VP8 或检测getCapabilities('video')
为什么你写的 WebRTC 页面在某些网络下完全连不上？
这通常不是代码逻辑问题，而是 ICE 连接协商失败的具体表现。关键排查点集中在候选地址生成和可达性上：
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 没配 STUN 服务器 → 所有候选都是
host类型，在双 NAT 场景下必然失败；至少加一个公共 STUN（如stun:stun.l.google.com:19302） - 需要中继但没配 TURN → 当双方都只有
reflexive或host候选且不可达时，连接卡在checking状态；此时必须部署私有 TURN（如 Coturn）并传入用户名/密码 - 防火墙主动丢弃 UDP 包 → 强制回退到 TCP relay（需 TURN 支持
transport=tcp）或改用iceTransportPolicy: 'relay'限定只走中继（牺牲延迟换连通） -
iceCandidate事件未正确发送给远端 → 信令通道（WebSocket / HTTP）丢包、顺序错乱、未 await 信令发送完成就调用addIceCandidate()，都会导致候选缺失
HTML 层能绕过 WebRTC 的 P2P 限制吗？
不能。HTML 和 DOM 是宿主环境，不参与 WebRTC 协议栈实现；所有限制来自浏览器内建的 WebRTC 引擎（如 Chromium 的 webrtc.org 后端）。你无法通过改 <video muted autoplay> 属性绕过安全上下文要求，也不能用 iframe sandbox 解除 getUserMedia 权限。唯一可控的是：用信令服务协调连接流程、用 RTCPeerConnection 配置项（如 iceServers、bundlePolicy）适配网络条件、用 getStats() 监控真实传输路径（是否用了 relay、丢包率、jitter）。
立即学习“前端免费学习笔记（深入）”；
真正容易被忽略的是：WebRTC 的“点对点”是逻辑模型，不是物理保证；而 HTML 只负责把媒体流挂到页面上——它既不加速穿透，也不缓和限制，只是那个安静展示画面和声音的窗口。
