不能，WebRTC只传输原始字节流，需手动序列化HTML字符串（如outerHTML）并通过RTCDataChannel发送，接收方用DOMParser或innerHTML渲染，但存在脚本执行、CSS失效、事件丢失等限制。
WebRTC 能直接传 HTML 吗？不能，但可以传 HTML 对应的数据
webrtc 本身不传输 html 文档或渲染结果，它只传输原始字节流（arraybuffer、blob、rtcdatachannel 中的字符串或二进制），所以想“传 html”，本质是把 document.documentelement.outerhtml 或服务端返回的 html 字符串当作普通数据发过去，再由对方用 innerhtml 或 domparser 渲染。
常见错误现象：Failed to execute 'write' on 'Document': Cannot write into a document from an asynchronously-loaded external script——这是试图在 iframe 或新窗口里直接 document.write() 已加载完成的页面导致的；还有人误以为 RTCPeerConnection 能自动同步 DOM，其实它连 JS 执行环境都不碰。
- 必须手动序列化：用
document.documentElement.outerHTML获取完整 HTML 字符串，或用new XMLSerializer().serializeToString(document.documentElement)更稳妥（兼容 SVG 等） - 若 HTML 含相对路径（如
<img src="logo.png">），接收方需确保资源可访问，否则显示空白；建议转为 data URL 或提前约定静态资源 CDN 域名 - 超过 64KB 的 HTML 字符串别走
RTCDataChannel.send()默认模式，要设ordered: false+maxPacketLifeTime，否则可能因重传卡住
用 RTCDataChannel 发 HTML 字符串的最小可行写法
RTCDataChannel 是 WebRTC 中唯一适合传 HTML 字符串的通道，它不像音视频轨道那样需要编解码协商，开箱即用，但初始化时机和状态检查极易出错。
使用场景：远程协作编辑器预览、低带宽下轻量级页面快照同步、无服务端中转的 demo 分享。
- 创建前必须等
peerConnection.signalingState === "stable"，否则createDataChannel()可能静默失败 - 发送方要监听
dataChannel.readyState === "open"再发，不能一创建就.send()；常见错误是没等 ready 就发，控制台无报错但对方收不到 - 接收方用
dataChannel.onmessage = e => { const html = e.data; }拿到字符串，注意e.data类型可能是string或Blob，需用typeof e.data === "string"判断 - 示例发送逻辑：
const dc = pc.createDataChannel("html");<br>dc.onopen = () => {<br> dc.send(document.documentElement.outerHTML);<br>};
HTML 渲染到接收方页面时的三个关键限制
接收到 HTML 字符串后，直接 document.body.innerHTML = html 看似简单，但会触发脚本执行、样式重载、事件丢失等一系列副作用，实际线上几乎不可用。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
性能影响：大 HTML（>1MB）直接 innerHTML 会导致主线程卡顿数秒；兼容性影响：Safari 对 DOMParser 解析含 <template> 或模块脚本的 HTML 支持滞后。
- 禁止执行内联脚本：用
DOMParser解析再手动移除<script>标签，或用{ script: "remove" }配置（仅 Chromium 支持） - CSS 不会自动生效：解析出的
link和style标签需手动插入document.head，且link[rel=stylesheet]加载是异步的，得监听onload - 事件绑定丢失：原 HTML 中的
onclick="foo()"或addEventListener不会复现，必须在插入后重新绑定，或改用事件委托
为什么不用 WebRTC 传整个网页？因为有更合适的替代方案
如果目标是“让对方看到一样的网页”，WebRTC 不是首选。它没有页面生命周期管理、不处理 history API、无法同步滚动/焦点/输入光标，而且 NAT 穿透失败率在企业网络中仍达 15–30%。
容易被忽略的地方：WebRTC 连接建立耗时通常 800ms–2s，而一次 HTTP GET 返回 HTML 可能只要 200ms；若 HTML 含 10 个外部资源，WebRTC 方案还得额外协调这些资源的传输方式，复杂度指数上升。
真要同步页面，优先考虑：fetch() 拉 HTML + Service Worker 缓存资源；远程调试协议（Chrome DevTools Protocol）；或用 SharedWorker + postMessage 协调多个标签页——WebRTC 在这里只是个高成本的备选，不是银弹。
