不需要，且不能主动设为 null；createOffer 前唯一强制要求是 RTCPeerConnection 已创建并已添加 track 或配置 transceiver，同时 iceServers 必须有效。
createOffer 调用前必须先设置 localDescription 为 null 吗？
不需要，而且不能主动设为 null。调用 createOffer() 前唯一强制要求是：RTCPeerConnection 实例已创建、且（通常）已添加至少一个 track 或配置了 offerToReceiveAudio/Video（旧 API）或使用 addTransceiver()（推荐）。如果连接处于 "closed" 或 "failed" 状态，createOffer() 会直接 reject 并抛出 InvalidStateError。
常见错误现象：DOMException: InvalidStateError: Cannot create an offer without a remote description when iceTransportPolicy is "relay" —— 这其实是个误导性错误信息，真实原因是 ICE 传输策略为 "relay" 时，若未提前设置 STUN/TURN 服务器，createOffer() 可能因无法初始化 ICE 而失败，和 remoteDescription 无关。
- 确保
RTCPeerConnection构造时传入了有效的iceServers配置（哪怕只含一个 STUN server） - 避免在
pc.oniceconnectionstatechange还没进入"checking"前就急着调用createOffer() - 不手动设置
pc.localDescription或pc.remoteDescription为null；它们应始终由setLocalDescription()/setRemoteDescription()控制
createOffer 的 constraints 参数里该填什么？
现代 WebRTC 应尽量避免使用过时的布尔型约束（如 {offerToReceiveAudio: true}），这些在 Chrome 117+ 已废弃。正确做法是用 addTransceiver() 显式声明媒体能力，再调用无参 createOffer()。
如果仍需兼容旧逻辑或做临时控制，唯一安全的 constraints 是 {voiceActivityDetection: false}（禁用 VAD，防止静音时丢包被误判为断连），其他字段如 iceRestart、offerToReceiveXxx 已被移除或忽略。
立即学习“前端免费学习笔记（深入）”；
- 要发起带音频+视频的 offer：先
pc.addTransceiver("audio")+pc.addTransceiver("video")，再await pc.createOffer() - 要发起仅音频 offer：只加 audio transceiver，video 不加，也不调用
getUserMedia -
iceRestart: true仅在已存在连接且需强制刷新 ICE 候选时使用，会触发新 gather，不是常规流程
生成 offer 后为什么 setLocalDescription 失败？
最常见原因是传入的 RTCSessionDescription 对象格式不对，或者 connection 处于非法状态。错误信息通常是：TypeError: Failed to execute 'setLocalDescription' on 'RTCPeerConnection': The provided value is not of type '(RTCSessionDescriptionInit or RTCSessionDescription)' 或 InvalidModificationError。
关键点：你必须把 createOffer() 返回的 RTCSessionDescription 实例（含 type 和 sdp 字段的对象）原样传给 setLocalDescription()，不能只传 sdp 字符串，也不能手动 new 一个对象。
- ✅ 正确：
const offer = await pc.createOffer(); await pc.setLocalDescription(offer); - ❌ 错误：
await pc.setLocalDescription({sdp: offer.sdp, type: "offer"});（缺少原型链，部分浏览器拒绝） - ❌ 错误：
await pc.setLocalDescription(offer.sdp);（类型不匹配） - 调用
setLocalDescription()后立即读pc.localDescription可能还是null，需等 Promise resolve 才真正生效
SDP 生成后要不要手动修改内容？
绝大多数场景下不要碰。现代浏览器生成的 SDP 已默认启用 Opus、VP8/VP9/H.264（按设备支持）、DTLS-SRTP、BUNDLE 等最佳实践。手动删行（如去掉 a=rtcp-fb）、改 codec 顺序、硬编码 extmap，极易导致协商失败或媒体卡顿。
唯一可接受的轻量调整是：在 setLocalDescription() 前对 offer.sdp 字符串做正则替换，例如屏蔽特定编解码器（如禁用 H.264）或强制使用 stereo 音频：
const offer = await pc.createOffer();
const sdp = offer.sdp.replace(/a=rtpmap:(\d+) H264\/\d+/g, '');
await pc.setLocalDescription({type: offer.type, sdp});
但要注意：这种改写绕过了 WebRTC 内部的 codec negotiation 逻辑，可能让远端无法 decode，务必配合远端 SDP 检查与 fallback 测试。
真正需要定制 SDP 的场景极少，比如嵌入式设备适配或特殊 NAT 穿透策略——这时候应该优先考虑改 iceTransportPolicy 或 STUN/TURN 配置，而不是动 SDP 文本。
