getUserMedia调用失败主因是权限、环境或触发时机不当：必须由用户手势（如click）触发，仅限HTTPS（localhost例外），且需处理facingMode兼容性与音频权限策略。
getUserMedia 调用失败，大概率不是代码写错了，而是权限、环境或触发时机没对——它根本不会在非用户手势下执行，也不会在 HTTP 页面里工作。
必须由用户点击触发，不能 onload 自动调用
浏览器强制要求 getUserMedia 必须由明确的用户交互（如 click、touchend）发起，否则直接抛出 NotAllowedError。页面加载完就 await navigator.mediaDevices.getUserMedia(...)？必然失败。
常见错误现象：
- 控制台报错
NotAllowedError: Permission denied或NotAllowedError: The request is not allowed by the user agent or the platform in the current context - iOS Safari 完全静默失败，连错误都不抛
实操建议：
- 按钮必须真实可点（不能
display: none或opacity: 0伪装） - 避免在
setTimeout或异步回调里间接调用；确保调用栈顶层是用户事件处理器 - 移动端尤其注意：微信内置浏览器对非直接点击更敏感，建议用
button而非div绑定事件
HTTPS 是硬门槛，localhost 是唯一例外
getUserMedia 在所有现代浏览器中被严格限制为仅允许在安全上下文（secure context）中运行。这意味着：
- 生产环境必须部署在 HTTPS 协议下
-
http://localhost和http://127.0.0.1被豁免，但http://localhost:8080也行，http://mydev.local不行 - HTTP 页面即使加了
localhost域名别名，只要协议是http，一律拒绝
如果你看到 SecurityError: Only secure origins are allowed，不用查代码，先改协议。
facingMode 不是万能开关，设备支持度差异大
想切前后摄像头？写 { video: { facingMode: 'environment' } } 看似简单，但实际行为高度依赖设备和浏览器：
- iOS Safari：只识别
'user'和'environment'，且不保证一定成功切换（尤其旧机型） - Android Chrome：基本可靠，但部分厂商定制浏览器会忽略该约束
- PC 浏览器：多数只返回默认摄像头，
facingMode可能被完全忽略
更稳妥的做法：
- 先用
enumerateDevices()拿到设备列表，再按label或deviceId显式指定 - 但注意：
enumerateDevices()必须在已获得一次getUserMedia权限后才返回完整label，否则label为空字符串 - 不要假设所有设备都支持
facingMode；降级逻辑要写：fallback 到自动选择或提示用户手动切换
audio: false 并不能彻底禁用麦克风权限请求
即使你只想要视频，写 { video: true, audio: false }，某些浏览器（尤其是 Safari）仍可能弹出“是否允许访问麦克风”提示——这不是 bug，是其隐私策略的一部分。
原因在于：部分设备的摄像头与麦克风硬件绑定，系统层无法单独授权视频流；或者浏览器实现将音视频权限视为原子单元。
应对方式：
- 如果业务确定不需要音频，仍保留
audio: false，但 UI 上需提前告知用户“将请求摄像头权限（可能包含麦克风）” - 若发现用户因误拒麦克风而连带拒绝视频，可尝试分两次请求：先
{ video: true }，再按需补{ audio: true } - 绝对不要在
constraints中传audio: undefined或省略字段——这等价于audio: true，反而更危险
