现代浏览器要求用户手势（如click、touchstart）且视频已静音（muted=true）才能成功调用play()，否则抛出NotAllowedError；需在手势事件回调中立即调用，不可延迟或异步执行。
大多数现代浏览器对 play() 函数的支持已趋一致，但自动播放策略差异极大——不是“能不能用”，而是“什么时候能静默触发”。Chrome、Firefox、Safari 都要求用户手势（如 click、tap）后才能调用成功，否则会抛出 NotAllowedError。
为什么 play() 在 Chrome/Firefox 中突然不工作了
2018 年起，Chrome 强制启用“autoplay policy”，Firefox 70+ 和 Safari 11+ 跟进。核心规则是：没有用户交互上下文的 play() 调用会被拒绝，哪怕视频已加载完成、muted 属性已设为 true。
- 常见错误现象：
Uncaught (in promise) DOMException: play() failed because the user didn't interact with the document first. - 即使你写了
video.play().catch(e => console.log(e))，也得在click、touchstart等事件回调中调用，不能放在DOMContentLoaded或setTimeout里 -
muted是绕过策略的必要条件（尤其 Chrome），但不是充分条件：必须同时满足“有用户手势”+“已设muted=true”才大概率成功
如何安全触发 play() 兼容所有主流浏览器
关键不是“降级兼容”，而是“按策略适配”。以下写法在 Chrome 110+、Firefox 120+、Safari 17+ 均可稳定运行：
const video = document.querySelector('video');
video.muted = true; // 必须提前设置，不能在 play() 后再设
// 在用户点击后立即调用
button.addEventListener('click', () => {
video.play()
.then(() => console.log('play succeeded'))
.catch(err => console.warn('play failed:', err.name));
});
- 不要等
canplay或loadeddata再绑定事件——手势上下文必须在调用前存在 - Safari 对
play()返回的 Promise 更敏感，务必加.catch()，否则可能静默失败 - 移动端需注意：
touchstart比click更可靠（iOS Safari 的 click 有 300ms 延迟，可能丢失上下文）
play() 失败时的 fallback 方案
当自动播放被拒，用户又没点按钮，只能引导交互或降级显示控制条：
- 检测失败后显示“点击播放”遮罩层，避免白屏或卡顿假象
- 不要反复重试
play()—— 浏览器不会因重试而放宽策略 - 若业务强依赖静音自动播放（如信息亭 kiosk），可考虑用
替代（部分旧版 Safari 对 audio 的限制略宽松），但不可依赖 - WebRTC 场景下，
play()行为与媒体轨道绑定更紧，需确保srcObject已赋值且 track 未被stop()
真正难的不是写对 play()，而是判断“此刻有没有合法的手势上下文”。很多 bug 来自把事件监听器绑在动态插入的元素上却忘了委托，或用了 addEventListener('click', handler, { once: true }) 却在 handler 里异步调用 play()——那一瞬间的上下文早就丢了。
