必须由用户手势(如点击)触发 navigator.mediaDevices.getUserMedia(),否则 Chrome 会因安全策略拒绝调用并报 NotAllowedError;需 HTTPS(或 localhost)、正确绑定 video.srcObject、检查设备可用性并前置权限判断。
navigator.mediaDevices.getUserMedia() 时页面无反应或报错多数情况下不是代码写错了,而是浏览器策略阻止了未安全上下文(non-secure context)下的摄像头访问。HTTP 页面直接调用 getUserMedia() 会静默失败或抛出 NotAllowedError 或 SecurityError。
localhost,它被浏览器视为安全上下文)allow="camera"
document.getElementById('startBtn').addEventListener('click', async () => {
try {
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
document.getElementById('video').srcObject = stream;
} catch (err) {
console.error('摄像头访问失败:', err.name); // 常见:NotAllowedError、NotFoundError、SecurityError
}
});
NotAllowedError: Permission denied
这不是权限没点“允许”,而是调用时机不合法。Chrome 要求媒体请求必须由用户手势(click、tap、keydown 等)直接触发,不能包裹在 setTimeout、Promise.then 或事件委托链过深的回调里。
DOMContentLoaded 或 load 事件中自动调用async/await 链间接触发(比如先 await 一个 API,再调用 getUserMedia)mediaDevices API) 不显示画面常见原因是未正确绑定流对象,或视频元素未设置 autoplay 和 muted(尤其在移动端 Safari 和新版 Chrome 中,有声音的自动播放会被阻止,进而影响视频流渲染)。
是移动端必需属性组合video.srcObject = stream,而不是 video.src = URL.createObjectURL(strea
m)(后者已废弃且内存泄漏风险高)stream 确实包含视频轨道:stream.getVideoTracks().length > 0
不能只靠 try/catch,需前置检测环境支持与设备存在性。有些设备(如某些 Windows 笔记本)摄像头硬件存在但驱动未启用,getUserMedia 仍会失败。
if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia)
await navigator.mediaDevices.enumerateDevices(),找 kind === 'videoinput'
enumerateDevices() 也需要用户授权后才返回真实设备列表,首次调用仍需用户交互触发async function checkCameraAvailable() {
if (!navigator.mediaDevices?.enumerateDevices) return false;
try {
const devices = await navigator.mediaDevices.enumerateDevices();
return devices.some(d => d.kind === 'videoinput');
} catch (e) {
return false; // 权限未授或策略拦截
}
}
实际项目中最容易被忽略的是「用户交互触发」这一硬性要求——哪怕逻辑完全正确,只要不是由一次明确的点击发起,Chrome 就会拒之门外。别试图绕过,这是强制设计。