核心是正确处理 getUserMedia 的拒绝、降级、兼容与状态同步：需满足安全上下文、用户手势触发，合理设置 constraints，区分错误类型引导用户，安全渲染流并及时停止轨道，注意移动端静音、设备变化监听及隐私风险。
浏览器里调用摄像头和麦克风，核心靠 navigator.mediaDevices.getUserMedia()，但直接调用常失败——不是权限被拒，就是设备不可用，或 Promise 永远 pending。关键不在“怎么写”，而在“怎么处理拒绝、降级、兼容和状态同步”。
getUserMedia 调用失败的常见原因与修复
最常见的错误是未满足安全上下文要求（比如 HTTP 环境下直接访问），或用户点击前就发起调用（Chrome 74+ 强制要求用户手势触发）。另外，constraints 写错也会静默失败：
-
{ video: true, audio: true }是最简写法，但某些安卓 WebView 或旧版 Safari 会因缺少分辨率/帧率约束而拒绝 - 避免写
{ video: { facingMode: "user" } }却不加 fallback：若前置摄像头不可用，整个 Promise 就 reject，应改用{ video: { facingMode: { ideal: "user" } } } - 部分 iOS 16.4+ Safari 对
audio: true在无用户交互页面上直接返回NotAllowedError，必须绑定到click或touchstart事件中
如何正确处理权限拒绝与设备缺失
不能只依赖 catch 打印错误，要区分类型并引导用户操作：
-
NotAllowedError：用户点了“拒绝”或系统级禁用，需提示打开设置（可跳转navigator.permissions.query({ name: 'camera' })检查状态） -
NotFoundError：设备不存在（如无摄像头的台式机），应降级 UI（隐藏预览区域，显示“无可用视频设备”） -
NotReadableError：设备被占用（如 Zoom
正在使用），建议提示“请关闭其他使用摄像头的应用”
- 注意：Firefox 在用户选择“仅音频”后仍可能返回
video: false，但stream.getVideoTracks().length为 0，需手动判断轨道是否存在
拿到 MediaStream 后，如何安全渲染与控制
流对象本身不自动播放，也容易因页面切换、标签页失焦被浏览器暂停：
- 渲染视频：用
标签，设srcObject = stream，**不要用src+ URL.createObjectURL()**（已废弃且内存泄漏） - 停止流：调用
stream.getTracks().forEach(track => track.stop())，仅停video或audio轨道时，分别遍历getVideoTracks()/getAudioTracks() - 监听设备变化：
navigator.mediaDevices.addEventListener('devicechange', handler)，但该事件不告诉你增删了哪个设备，需重新 enumerateDevices() 对比 - 移动端自动静音问题：Safari/iOS 要求
加muted才能自动播放，否则需用户手动点一次
兼容性与生产环境注意事项
Edge 18 及更早版本用 navigator.getUserMedia（已废弃），现在基本可忽略；真正麻烦的是 Electron 和 Cordova 环境：
- Electron 22+ 默认禁用媒体设备，需在
webPreferences中显式开启webSecurity: false（不推荐）或配置permissions策略 - Cordova 需额外安装
cordova-plugin-media-capture或cordova-plugin-camera，纯 Web API 在 iOS Cordova 中多数失效 - WebRTC 带来的隐式后台采集风险：即使
display: none，只要srcObject已赋值，摄像头仍在工作——务必在不需要时显式 stop 轨道 - 隐私指示器（如 macOS 绿灯、Windows 摄像头图标）只响应真实硬件采集，mock stream（如
new MediaStream()）不会触发
最易被忽略的一点：getUserMedia 返回的 stream 不是“一次性快照”，它持续采集，且不同设备的默认参数（如分辨率、帧率、是否自动对焦）差异极大；如果你需要稳定画质，必须显式声明 width/height/frameRate，并接受浏览器最终协商结果——而不是假设传了就一定生效。
