HTML调用navigator.mediaDevices.getUserMedia()被拒绝的常见原因：HTTP协议下一律拒绝（localhost除外），file://协议直接失败；用户手动阻止权限后需手动在地址栏锁图标中重设为允许。
HTML调用navigator.mediaDevices.getUserMedia()被拒绝的常见原因
直接失败不是因为HTML本身有问题，而是浏览器对getUserMedia()的权限策略非常严格：HTTP协议下一律拒绝访问摄像头，必须走HTTPS（本地localhost或127.0.0.1除外）。很多开发者在开发机上用file://打开HTML文件，结果控制台报NotAllowedError: Permission denied——这不是代码写错了，是协议不被允许。
另外，用户首次访问时弹出的权限提示如果被手动“阻止”或“静音”，后续再调用getUserMedia()会直接走catch分支，不会再次弹窗。此时需引导用户手动到浏览器地址栏点击锁形图标，把摄像头权限改回“允许”。
Chrome/Firefox/Safari对getUserMedia()的兼容性差异
Chrome 和 Firefox 支持较完整，但 Safari 17+ 才支持video: { facingMode: "user" }，旧版只认"user"字符串，不支持{ ideal: "user" }写法；而且 Safari 在 iOS 上默认禁用autoplay，即使拿到视频流，<video></video>也得显式调用play()，否则黑屏。
常见兼容写法建议：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 始终用
try...catch包裹getUserMedia()调用，不要依赖then/catch链式写法（Safari 16 有 Promise 状态异常） - 设备约束传参避免用
ideal，改用exact或直接字符串（如facingMode: "environment"） - 获取流后立即赋给
video.srcObject，不要用URL.createObjectURL()（已废弃且 Safari 不稳定）
页面加载后立刻调用摄像头导致白屏或卡顿
不是所有设备都能秒开摄像头，尤其低端安卓机或某些Chrome版本，从调用getUserMedia()到视频帧真正可渲染可能延迟300–800ms。如果<video></video>元素没设autoplay和muted，或者CSS没设width/height，容易出现空白、拉伸、或触发canplay事件后仍无画面。
实操要点：
-
<video></video>标签必须带autoplay muted属性，否则Chrome 70+ 会静音拦截 - 设置
video.style.width = "100%"; video.style.height = "auto"，避免因宽高未定导致渲染异常 - 监听
loadeddata事件而非canplay，前者表示首帧已解码完成，更可靠 - 加个简单loading状态，比如
video.addEventListener("loadeddata", () => loadingEl.style.display = "none")
HTTPS本地开发绕过证书错误的临时方案
用自签名证书跑HTTPS时，Chrome 可能直接拦截并显示“您的连接不是私密连接”，连调用getUserMedia()的机会都没有。这不是权限问题，是TLS握手失败。
快速绕过方式（仅限开发）：
- Chrome 地址栏输入
chrome://flags/#unsafely-treat-insecure-origin-as-secure，启用该flag，并把你的http://192.168.x.x:port加进下方输入框 - 或改用
localhost——哪怕你实际绑的是内网IP，只要DNS或hosts映射到localhost，就视为安全上下文 - Node.js 启服务时加
--unhandled-rejections=none可避免某些HTTPS异常中断流程（非必须，但能减少干扰）
真要上线，必须用Let’s Encrypt等可信证书，别指望用户点“高级→继续访问”。
