本文直击前端调用摄像头时视频画面“存在却不可见”的核心原因——并非编解码器问题，而是异步时机错误与 DOM 初始化顺序不当导致 srcObject 未正确绑定。
本文直击前端调用摄像头时视频画面“存在却不可见”的核心原因——并非编解码器问题，而是异步时机错误与 dom 初始化顺序不当导致 `srcobject` 未正确绑定。
在 Web 开发中，使用 navigator.mediaDevices.getUserMedia() 接入用户摄像头是一个高频需求，但开发者常遇到一种令人困惑的现象：控制台无报错、元素检查可见
标签占位矩形（甚至背景色生效），但实际画面完全空白。许多开发者会本能怀疑是视频编码格式（如 VP8/H.264 兼容性）或浏览器限制所致——但根据
MDN
和
CanIUse
数据，现代浏览器对 getUserMedia 输出的 VP8 流支持完善，
编解码器几乎不可能是根本原因
。真正的问题往往藏在代码执行时序中。
? 根本症结：异步 Promise 与 DOM 加载时机错配
原始代码中，navigator.mediaDevices.getUserMedia(constraints) 返回一个 Promise，其 .then() 回调被包裹在 DOMContentLoaded 事件监听器内：
复制 document.addEventListener("DOMContentLoaded", function() {
video = document.getElementById("playback");
video.srcObject = stream; // ← 此处永远不会执行！
});
⚠️ 问题在于：getUserMedia() 的 Promise
通常在 DOMContentLoaded 事件触发之后才 resolve
（尤其在首次请求权限时需用户交互）。这意味着 addEventListener("DOMContentLoaded", ...) 注册的回调已失效，video.srcObject = stream 语句从未执行——视频元素始终处于无媒体源状态，自然不可见。
此外，原始代码还存在几处易被忽略的缺陷：
else(console.log("!OK getUserMedia")) 缺少 return，后续逻辑仍会继续执行；
.catch() 中错误变量名写错（e → 应为 error）；
width/height 属性值使用百分比（"60%"）在 标签中无效（必须为像素数值或 auto）；
未处理用户拒绝授权等常见异常场景。
✅ 正确实践：先等 DOM 就绪，再请求媒体流
推荐采用 async/await + DOMContentLoaded 事件驱动的方式，确保 DOM 已就绪、元素可访问，再安全发起媒体请求：
复制
? 关键注意事项
尺寸单位务必用像素
： 是无效的，应改用 CSS 或内联 width="640" 等具体像素值；
添加 muted 和 autoplay
：现代浏览器对自动播放有严格策略，音频未静音时 autoplay 会被阻止，导致视频黑屏；
不要手动设置 codec
：getUserMedia() 不接受 codec 字段约束（如 codec: 'h264'），该参数仅适用于 RTCPeerConnection 等 WebRTC 场景；
错误处理要具体
：优先捕获 NotAllowedError（用户拒绝）、NotFoundError（无设备）、NotReadableError（设备被占用）等标准异常，便于定位真实问题；
HTTPS 必须启用
：getUserMedia() 在非 localhost 的 HTTP 环境下将被浏览器直接拒绝（安全策略强制要求）。
? 总结：当摄像头画面“看不见”时，请优先检查
异步流程是否与 DOM 生命周期对齐
，而非怀疑编解码器。90% 的类似问题源于 srcObject 赋值时机错误。遵循“先确保元素存在，再请求流，最后绑定”的三步原则，即可稳定呈现实时视频流。
