不是必须，但不配 reliable 参数等于埋雷；默认 true（有序可靠），实时数据应显式设 {ordered: false, maxretransmits: 0}，否则弱网下重传卡死发送、bufferedamount 暴涨断连。
RTCDataChannel 创建时必须配好 reliable 参数吗？
不是必须，但不配等于埋雷。默认 reliable: true（SCTP 有序可靠传输），但如果你传的是实时日志、游戏状态帧这类“过期即丢”的数据，应该显式设为 { ordered: false, maxRetransmits: 0 }。否则浏览器会默默重传失败包，卡住后续消息，尤其在弱网下表现明显。
常见错误现象：dataChannel.send() 突然卡住、onbufferedamountlow 不触发、发送端 bufferedAmount 持续上涨到几 MB 后断连。
-
reliable: false时，ordered和maxRetransmits必须至少指定一个，否则 Chrome 会静默忽略创建请求 - Firefox 对
maxRetransmits: 0支持更稳；Chrome 在某些版本中需配合ordered: false才真正禁用重传 - 若要兼容老版本 Safari（≤16.4），避免用
maxPacketLifeTime，它只在较新 Safari 中生效
send() 失败时为什么没报错，也收不到 onerror？
RTCDataChannel.send() 是同步调用，但底层是异步写入 SCTP 缓冲区。它只在缓冲区满或连接已关闭时同步抛错（如 InvalidStateError），其余大部分错误（如网络中断、对方断连）根本不会触发 send() 报错，而是让 bufferedAmount 堆积，最终导致 onclose。
真正能感知传输失败的只有两个时机：对方调用 close()、连接状态变成 "failed" 或 "closed"。
- 务必监听
dataChannel.onclose和peerConnection.onconnectionstatechange，不要依赖send()的返回值 - 发送关键消息前检查
dataChannel.readyState === "open"，但注意：这个状态可能滞后于真实网络状态 1–2 秒 - 对重要消息实现应用层确认机制（例如发完后等对方回
"ACK:${msgId}"），WebRTC 本身不提供 ACK
大文件分块传，chunk 多大才安全？
单次 send() 最大安全尺寸是 64KB（65536 字节）。虽然规范说上限约 16KB，但实测 Chrome/Firefox 在 64KB 内基本稳定；超过后容易触发 TypeError: Failed to execute 'send' on 'RTCDataChannel': Data cannot be sent because the underlying data transport is not ready，尤其在移动端。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
这不是理论限制，而是 SCTP 的 MTU 和拥塞控制共同作用的结果。别信“只要小于 65536 就行”——还要预留协议头和加密开销。
- 推荐 chunk 大小设为
32768（32KB），留足余量 - 用
FileReader.readAsArrayBuffer()读取文件，避免 base64 膨胀导致超限 - 发送前检查
dataChannel.bufferedAmount （1MB），超了就 <code>await new Promise(r => dataChannel.onbufferedamountlow = r)等待 - 别用
Blob.slice()直接传 Blob，某些旧版 Safari 会静默失败；统一转成ArrayBuffer
如何判断数据通道真的通了，而不是假连？
仅靠 dataChannel.readyState === "open" 或 peerConnection.connectionState === "connected" 不够。WebRTC 可能在 ICE 连接成功、SCTP 握手未完成时就触发这些事件，此时 send() 仍会失败。
真正可靠的握手信号，是双方都成功收发过一条测试消息，并确认内容一致。
- 在
dataChannel.onopen后立刻发一条短字符串（如"PING"），并等待对方回"PONG" - 加超时：3 秒内没收到 PONG，视为通道未就绪，触发重试或降级逻辑
- 别复用信令通道做这个检测——信令走 WebSocket，和 DataChannel 是两条独立路径，通信令 ≠ 通数据
- 移动端尤其要注意：iOS Safari 有时会在后台标签页中暂停 SCTP 流，
onopen触发后首次send()仍可能失败，建议首条消息带重试
实际跑通 WebRTC DataChannel，难点不在 API 调用顺序，而在于你是否愿意为每条 send() 检查状态、为每个 chunk 加边界校验、为每次 open 做双向 ping。这些细节不写进文档，但漏掉一个，线上就会出现“看起来连上了，就是传不了数据”的幽灵问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
