你说要用摄像头，浏览器跳出来的那个框，今天把这件事彻底变了

你说要用摄像头，浏览器跳出来的那个框，今天把这件事彻底变了

用户点完按钮，等了三秒，弹出来的提示根本不在他点的那个位置——点的是视频通话按钮，跳出来的权限框在屏幕左上角。等他回过神来点错了，权限就变成了”拒绝”。下一次再想启用？去浏览器设置里找那个藏在 URL 栏后面的小锁。绝大部分用户到这一步就放弃了。

这件事让大量视频功能死在产品 onboarding 阶段。过去十年，我们一直在用 getUserMedia() 做媒体捕获，这个 API 本身没问题，但它把”什么时候弹提示”这件事完全交给了浏览器。浏览器觉得该弹就弹，用户可能早就忘了自己点的是什么。而一旦点错——拒绝之后重新授予的比率，行业里长期只有 10% 左右。

Chrome 151 给了另一个答案：一个 HTML 元素，<usermedia>，把权限请求变成声明式、浏览器可控、带恢复路径的东西。

一行标签，替代整个 getUserMedia 流程

以前要写这样的代码：

navigator.mediaDevices.getUserMedia({ video: true, audio: true })
.then(stream => { video.srcObject = stream; })
.catch(err => { console.error(err.name); });

现在可以这样：

<usermedia id=”media-ctrl” autoplay>
<button>开启摄像头</button>
</usermedia>

<script>
const el = document.getElementById(“media-ctrl”);
el.setConstraints({
video: { width: 1280, height: 720 },
audio: { echoCancellation: true }
});

el.addEventListener(“stream”, e => {
videoPreview.srcObject = e.target.stream;
});
el.addEventListener(“error”, e => {
console.error(“获取失败:”, e.target.error?.name);
});
el.addEventListener(“cancel”, () => {
console.log(“用户取消了权限请求”);
});
</script>

<usermedia> 本身是一个浏览器原生的权限控件，用户点击它触发权限请求时，提示是在用户点击上下文里弹出的——不是随机的浏览器时机，是用户刚刚点过的地方。这听起来是一个很小的改变，但背后的数据说明了一切。

真实生产数据，改变了什么

Chrome 151 源试用期间，Cisco、Zoom 和 Google Meet 三家把这件事跑了一遍：

• Cisco：之前拒绝过权限的用户，重新授予率约 10%；用了 <usermedia> 之后跳到 65% 以上
• Zoom：摄像头和麦克风捕获错误减少了 46.9%
• Google Meet：「麦克风不能用」相关反馈减少了 17%，最初拒绝权限的用户成功恢复授权的比例提升了 131%

这不是 A/B 测试里常见的 3%、5% 的提升——是从根本上修好了一个之前几乎修不好的用户流失漏斗。

渐进增强，写起来比看起来更安全

<usermedia> 目前只有 Chrome 151 支持。迁移策略是标准的能力检测写法：

if (“HTMLUserMediaElement” in window) {
document.getElementById(“media-ctrl”).addEventListener(“stream”, handleStream);
} else {
document.getElementById(“fallback-btn”).addEventListener(“click”, () => {
navigator.mediaDevices.getUserMedia({ video: true, audio: true })
.then(handleStream);
});
}

不支持的浏览器会把 <usermedia> 当作 HTMLUnknownElement 处理，直接渲染子元素——这里用 <button> 做兜底按钮，逻辑上等于什么都没破坏。

安全上还有一个细节：<usermedia> 有严格的样式限制，防止出现伪造的权限按钮诱导用户点击。

更大的方向：Capability Elements

<usermedia> 是 Chrome Capability Elements 系列的第二个成员，第一个是 Chrome 144 的 <pdf-viewer>。这整条路线图的意图是：把原本需要 JavaScript 调用浏览器底层能力的场景，变成声明式、由浏览器统一管理用户体验的东西。

如果这个方向成立，接下来还有 <video> 和 <audio> 单独的场景化元素在路线图上。

下一步

如果你现在有视频通话、屏幕录制、KYC 身份核验这类功能在产品里，第一步是加能力检测：

const supportsUserMedia = “HTMLUserMediaElement” in window;

有就替换，没有就保留原逻辑。权限这个环节修好之后，这类功能的转化率很可能会有一次明显改善。