调用 MediaDevices.getUserMedia() 不报错需满足 HTTPS/localhost 环境且由用户手势触发；传入明确约束对象（如 {video: true}）；用 .catch() 处理 NotAllowedError 或 NotFoundError。
MediaDevices.getUserMedia() 怎么调用才不会报错？
调用 getUserMedia() 前必须满足两个硬性条件：页面运行在 https://（或 localhost），且用户已主动触发（比如点击按钮）。直接在页面加载时自动调用会失败，浏览器会静默拒绝并抛出 NotAllowedError 或 SecurityError。
- 权限请求必须是用户手势（
click、tap）后发起，不能放在setTimeout或load事件里“绕过” - 约束对象要写清楚，比如只想要视频就传
{ video: true }，不要传空对象{}—— 某些旧版 Chrome 会当作请求音频+视频，然后因缺少麦克风权限而失败 - 记得处理拒绝情况：
navigator.mediaDevices.getUserMedia(...)返回 Promise，.catch()中检查err.name是NotAllowedError（用户点拒）还是NotFoundError（没摄像头）
如何把摄像头流显示在
拿到 MediaStream 后不能直接赋给 src，得用 URL.createObjectURL() 生成临时 URL。这个 URL 只在当前文档生命周期内有效，页面关闭或显式释放前不会自动销毁，不手动清理会导致内存泄漏。
const video = document.getElementById('myVideo');
navigator.mediaDevices.getUserMedia({ video: true })
.then(stream => {
video.srcObject = stream; // ✅ 推荐：现代标准，无需 createObjectURL
// video.src = URL.createObjectURL(stream); // ❌ 已废弃，且需手动 revoke
});
-
video.srcObject = stream是当前唯一推荐方式，兼容 Chrome 53+、Firefox 50+、Safari 11+ - 如果要用
src属性（比如某些老框架强制要求字符串 src），必须配对调用URL.revokeObjectURL(video.src)，通常在stream.getTracks().forEach(t => t.stop())后执行 - 别忘了加
autoplay和muted（尤其音频流），否则 Safari 和新版 Chrome 可能因策略阻止自动播放
MediaRecorder API 录制出来的 blob 为什么打不开？
常见问题是录制时没指定 mime type，导致生成的 Blob 缺少正确 type，下载后系统无法识别。Chrome 默认用 video/webm，但 Firefox 可能用 video/webm;codecs=vp9，而移动端 Safari 根本不支持 MediaRecorder（截至 iOS 16.5）。
- 显式声明 mimeType 更稳妥：
new MediaRecorder(stream, { mimeType: 'video/webm;codecs=vp8' }) - 录制结束后的
blob要用URL.createObjectURL(blob)才能赋给的src；直接blob.toString()没意义 - 注意
dataavailable事件可能触发多次，blob是分片的，得用数组收集再new Blob(chunks, { type: mimeType })合并 - 想录 MP4？别指望
MediaRecorder原生支持 ——video/mp4在绝大多数浏览器中仍不可用，得靠 FFmpeg.wasm 后处理
AudioContext 处理实时音频时延迟高、有杂音怎么办？
默认 AudioContext 使用系统默认缓冲区大小（常为 1024 或 2048 sample），导致明显延迟（>100ms）和偶发爆音。关键不是“怎么连节点”，而是“怎么压低延迟并稳住采样率”。
立即学习“Java免费学习笔记（深入）”；
- 创建时传入
{ latencyHint: 'interactive' }（Chrome/Firefox 支持），比默认值更激进地降低缓冲区 - 用
stream.getAudioTracks()[0]创建MediaStreamAudioSourceNode，别用createMediaStreamSource()配错上下文 - 避免在
audioprocess事件（已废弃）或ScriptProcessorNode中做重操作 —— 改用Worklet（AudioWorklet），但需提前注册，且不支持 Safari - 测试时关掉所有其他音频标签页，Chrome 的音频调度器在后台标签页会主动升延迟保续航
WebRTC 音视频链路本身就有不可忽略的固有延迟（编码、网络、解码），纯前端 JS 能优化的只是采集和渲染环节。真要低延迟，得从信令、编解码参数、STUN/TURN 服务器部署一起动刀，JS 层只是冰山一角。
