写过视频功能的工程师大概都踩过这个坑——接个摄像头要写几十行 JS 补丁，今天 Chrome 151 把这件事用两个标签彻底原生化了

写过视频功能的工程师大概都踩过这个坑——接个摄像头要写几十行 JS 补丁，今天 Chrome 151 把这件事用两个标签彻底原生化了

写过视频功能的工程师大概都踩过这个坑：每次需要摄像头或麦克风，都要先写一个按钮，再写 navigator.mediaDevices.getUserMedia()，再写一堆回调处理权限拒绝、设备不存在、用户点错、时间窗口错位。一坨样板代码换来的只是一个弹窗，用户还不一定在正确的时间看到它。

然后用户拒绝了一次，再也找不回来——因为从”拒绝”到”再次授权”，中间隔着浏览器设置里那个永远找不到的小锁图标。这就是所谓的”权限黑洞”：90% 拒绝过一次的用户从此再也不会回来。

Chrome 151 把这件事彻底变了。

<usermedia>：把权限请求变成浏览器自己的事

Chrome 151 引入了 <usermedia> HTML 元素——这是 Chrome”能力元素”系列的第二个成员（第一个是 Chrome 144 的 <homescreen>）。它把权限请求这件事从 JavaScript 调用直接转移到了浏览器原生界面：用户点击一个物理可见的标签，浏览器负责弹出权限对话框、负责管理权限恢复流程、负责把 MediaStream 送回给你的应用。

这个设计解决的不是”权限本身”，而是”谁在问、在什么情境下问”。

Origin Trial 数据来自 Cisco、Zoom 和 Google Meet 三家（引用自 Chrome for Developers 官方博客），效果相当直接：

• Cisco：用户从”拒绝”到”授予”的恢复率，从传统提示的 ~10% 跳到了 65% 以上
• Zoom：摄像头或麦克风捕获错误减少了 46.9%
• Google Meet：”麦克风无法运作”反馈减少了 17%，权限恢复成功率提升了 131%

对视频通话、KYC 验证、创作者工具这类”摄像头本身就是产品”的应用来说，这不是锦上添花，是直接提升转化率。

代码怎么写

传统 getUserMedia() 的写法：

// 先写按钮，再写函数
const start = () => {
  navigator.mediaDevices.getUserMedia({ video: true, audio: true })
    .then(stream => {
      videoPreview.srcObject = stream;
    })
    .catch(err => {
      if (err.name === "NotAllowedError") showRecoveryHint();
      else if (err.name === "NotFoundError") showDeviceHint();
      // ...
    });
};
btn.addEventListener("click", start);

<usermedia> 的写法：

<button>开启摄像头</button>
<usermedia id="cam" audio video>
  正在连接...
</usermedia>

const el = document.getElementById("cam");

// 交互前配置硬件偏好
el.setConstraints({
  video: { width: 1280, height: 720 },
  audio: { echoCancellation: true }
});

// 获取到流
el.addEventListener("stream", () => {
  videoPreview.srcObject = el.stream;
});

// 获取失败
el.addEventListener("error", () => {
  console.error("获取失败:", el.error?.name);
});

// 用户关闭了提示框
el.addEventListener("cancel", () => {
  console.log("用户取消了权限请求");
});

不需要回调，不需要管理 Promise，不需要判断 NotAllowedError / NotFoundError / OverconstrainedError。流直接挂在元素上，事件语义清晰。

不支持的浏览器会把 <usermedia> 当成 HTMLUnknownElement——你写在里面的”正在连接…”会正常显示，点击后回退到传统 getUserMedia() 流程。渐进增强，写法不变。

样式限制：防止钓鱼

浏览器对 <usermedia> 强制了样式安全约束，防止开发者通过视觉伪装骗取权限：

• 对比度：至少 3:1，防止弱对比度文字误导用户
• 尺寸限制：width、height、font-size 必须符合规范范围
• 不透明度：必须是完全不透明
• 变换限制：transform 只允许 2D 平移，且必须等比缩放——禁止用 scaleX(-1) 做镜像翻转诱导

说白了：你可以改颜色、改大小，但没办法把它伪装成系统对话框。

浏览器支持与落地策略

目前只有 Chrome 151 支持，Firefox 和 Safari 暂无计划。作为渐进增强处理即可，不影响现有功能。

三个下一步：

1. 现有项目：在视频/音频采集入口处加一个 <usermedia> 标签作为优化，原有 getUserMedia() 逻辑保留作为 fallback。两套并行，不影响当前功能。
2. 新项目：直接用 <usermedia> 作为主路径，getUserMedia() 作为兜底。等 Firefox/Safari 支持后，fallback 逻辑可以直接删掉。
3. 产品接入：如果你在做视频通话、KYC、avatar 录制这类”摄像头即核心”的产品，建议追踪一下当前的”权限拒绝→恢复”转化率，作为基线数据，用 <usermedia> 优化后再测一次对比。

一句话结论： 权限处理这件事，讨论的不应该是”要不要问用户同意”，而是”谁在问、在什么情境下问”。Chrome 151 把这个答案从 JavaScript 移到了浏览器，让用户在有上下文、有信任感的情境下做出决定。Chrome 151 only，先当渐进增强用着。