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，反而更危险

真正卡住开发的，往往不是 API 怎么写，而是用户点了按钮却没反应、点了允许却黑屏、或者 iOS 上点开就是全屏。这些都不是边缘 case，而是每天都在发生的兼容性现实。处理它们没有银弹，只有把权限流、设备枚举、错误捕获三者串成闭环，再针对 Safari 和微信做最小化兜底。