你以为接摄像头只能靠 getUserMedia？Chrome 151 用一个 HTML 标签把这件事彻底原生化了

用户拒绝了摄像头，接下来怎么办？

这件事，getUserMedia 从来没给过好答案。

传统流程是这样的：页面调用 getUserMedia()，浏览器弹出系统权限对话框，用户一点「拒绝」，这个决定就锁死了。之后除非用户手动去浏览器设置里翻找，否则你的网页永远拿不到摄像头——即使他只是不小心点错了。

这叫「permission hole」（权限陷阱）。数据显示：用户第一次拒绝后，只有大约 10% 能靠传统提示成功恢复权限。

三个主流产品的 Origin Trial 数据把这个问题的严重性量化了：

• Cisco：用上新元素后，拒绝后恢复率从 10% 跳到 65%
• Zoom：usermedia 让摄像头/麦克风捕获错误减少了 46.9%
• Google Meet：「麦克风不工作」反馈下降 17%，权限恢复成功次数增加了 131%

Chrome 151（2026 年 7 月稳定版）给出的答案是一个 HTML 标签：<usermedia>

这是 Capability Elements（能力元素）系列的第二弹。第一弹是 Chrome 144 的 <Permissions> 标签。思路是一致的：把原本靠 JS 触发的权限请求，变成浏览器认识的用户主动操作。

用这个标签，权限管理从你的 JS 代码里消失了，浏览器自己当门卫。

怎么用

第一步，加标签，指定要什么媒体：

<usermedia id=”cam” sink=”video#remote” type=”video”></usermedia>
<video id=”remote” autoplay></video>

第二步，监听事件：

const cam = document.getElementById(“cam”);
cam.onstream = (e) => {
document.getElementById(“remote”).srcObject = e.stream;
};
cam.onerror = (e) => console.error(“摄像头出错”, e.error);
cam.oncancel = () => console.log(“用户取消了”);

没了。没有 navigator.mediaDevices.getUserMedia()，没有回调地狱，浏览器直接把 MediaStream 送到你的 onstream 里。

为什么数据这么好看

<usermedia> 改变了交互位置。标签是一个用户主动点击的元素，不是脚本后台触发的事件。浏览器认得这个行为，知道用户是真的想用摄像头，于是能给出更有上下文的提示和更顺畅的恢复路径——不必跳出页面去系统设置里翻找。

防止滥用

Chrome 给 <usermedia> 加了严格的样式约束：对比度不低于 3:1、不能设透明度、宽高和字号有最小值、transform 只能做 2D 平移和等比缩放。想做一个隐藏的摄像头捕捉按钮？浏览器会直接拒绝渲染。

渐进增强

如果用户装的是不支持 <usermedia> 的浏览器，这个标签会被当作普通的 HTMLUnknownElement，子元素正常渲染，页面可以回退到传统 getUserMedia() 写法。

迁移路径

把触发调用的按钮换成 <usermedia> 标签，把 getUserMedia().then(stream => …) 改成 onstream = (e) => { … }。现有逻辑几乎不用动。

2026 年第三季度，摄像头和麦克风的网页接入方式正在被重新定义。不是加了一个新 API，而是把「权限管理」这件事从应用层搬到了浏览器层——就像当年 <input type=date> 让浏览器自己处理日期选择一样。

你的音视频功能，准备好接入了。