写过视频会议的人都踩过这个坑——用户拒绝摄像头权限后就直接放弃了，今天这件事被 Chrome 151 和一个测试方法从根上翻了

写过视频会议的人都踩过这个坑——用户拒绝摄像头权限后就直接放弃了，今天这件事被 Chrome 151 和一个测试方法从根上翻了

视频会议应用有个老大难：用户第一次点“加入会议”，顺手把摄像头权限拒绝了，之后这个按钮再怎么点都没反应，只能眼睁睁看着用户关掉页面走人。

这个问题折磨了视频会议团队很多年。传统方案是 getUserMedia()，一个 JS 调用 + 浏览器弹出权限框，流程在浏览器手里，开发者能做的有限。用户拒绝之后，浏览器把重置入口埋进了系统设置深处——Layers 深处，没有哪个用户会真的去找。

两个改变正在同时发生。

第一个是 Chrome 151 的 <usermedia> 元素。 这是 Capability Elements 套件的第二个成员，取代 getUserMedia() 的 JS 调用，用一个声明式 HTML 标签直接承载权限请求。浏览器接管整个流程：意图捕获、权限弹窗、MediaStream 传递，全部原生处理。开发者只需要写 <usermedia> 标签，配置约束条件，监听 onstream 事件。

更重要的是，它把权限恢复这件事彻底原生化了：用户拒绝后再次点击标签，浏览器直接在页面内触发恢复流程，不需要跳设置页。

Origin Trial 数据验证了效果：

• Cisco：用户拒绝后重新授权的成功率，从 ~10% 提升到 65% 以上
• Zoom：摄像头/麦克风捕获错误下降 46.9%
• Google Meet：“麦克风无法工作”反馈减少 17%，权限恢复成功率提升 131%

第二个改变是 SPA Soak Test 的工程化落地。 一项针对 500 个 React、Vue、Angular 仓库的静态分析发现，其中 86% 在某处挂上了 listener、timer 或 subscription，却从不移除。SPA 的问题是页面从不刷新，内存只进不出——内存泄漏是 SPA 的家常便饭，但传统 E2E 测试每个用例跑全新的 browser context，根本测不出来。

Playwright 浸泡测试解决了这个问题：同一个 browser context 重复跑同一套用户操作，对比 DOM 节点数和 listener 计数的变化趋势。200 次循环配合虚拟时钟加速，可以压缩覆盖真实场景约 100 分钟的运行状态。

关键指标只有两个：listener 数量不增长，DOM 节点数增长不超过允许阈值（通常 100）。

npm 上有现成的包 playwright-soak-test，三行代码接入现有 Playwright 套件。建议放进夜间 CI 任务，而不是每个 PR 都跑——因为单次耗时以分钟计，基线建立需要预热循环，结果波动也较大。

import { test } from 'playwright-soak-test';

test('dashboard drawer does not leak memory', async ({ page, soak }) => {
  await page.goto('/dashboard');
  await soak.run(async () => {
    await page.getByRole('button', { name: 'Report' }).click();
    await page.getByRole('button', { name: 'Close' }).click();
  });
});

这两个改变本质上解决的是同一类问题：用户操作的可逆性和系统状态的健康度。<usermedia> 让用户拒绝后还能回来，Soak Test 让内存泄漏在夜间被发现而不是等用户来报 Bug。

下一步：

1. 如果你的产品有视频/音频功能，升级到 <usermedia>，保留 getUserMedia() fallback
2. 找一个“状态应当回到原点”的核心用户流程（比如打开关闭抽屉），用 playwright-soak-test 跑一次看看基线

这两个改动都不大，但都是那种“用户没感觉你做了，但不出问题的时候就知道好了”的工程化细节。