HTML5 play() 方法是否可用，需通过其返回的 Promise 状态判断：resolve 表示可播放，reject 且 name 为 'NotAllowedError' 表示策略拦截，必须在用户交互回调中调用并处理重试。
HTML5 play() 方法是否可用，不能只看浏览器版本
现代浏览器基本都支持 play()，但是否能**实际调用成功**，取决于上下文策略而非单纯 API 存在性。直接检测 HTMLMediaElement.prototype.play 是否为函数，只能说明语法层面存在，无法反映真实可执行性——比如在无用户手势（click/tap）触发的场景下，Chrome 和 Safari 会静默拒绝并抛出 NotAllowedError。
真正需要检测的是：「当前媒体元素在当前上下文中能否立即播放」。
用 play() 的返回 Promise 状态判断是否真支持
play() 自 HTML5.2 起返回一个 Promise，这是唯一可靠、标准化的运行时检测方式。成功 resolve 表示允许播放；reject 且 reason.name === 'NotAllowedError' 表示策略拦截；其他错误（如网络失败、格式不支持）则需单独处理。
- 必须在用户交互回调中调用（如
button.addEventListener('click', ...)），否则 Promise 几乎必 reject - 不要仅检查
typeof el.play === 'function'，这在 iOS Safari 10+ 和 Chrome 66+ 中恒为 true，但调用仍可能失败 - 避免在
autoplay属性设为 true 时依赖该检测——很多浏览器会忽略autoplay，但不抛错，导致误判
const video = document.querySelector('video');
button.addEventListener('click', () => {
const p = video.play();
p.then(() => {
console.log('✅ 可播放');
}).catch(err => {
if (err.name === 'NotAllowedError') {
console.log('❌ 被策略阻止：缺少用户手势或静音限制');
} else {
console.log('⚠️ 其他错误：', err);
}
});
});
iOS Safari 和 Android Chrome 的特殊限制要单独应对
iOS Safari 要求视频满足 muted + playsinline 才能在非全屏下自动播放；Android Chrome 则对 autoplay 更宽松，但仍要求用户至少触发过一次交互（哪怕只是 touchstart）。这些不是「不支持 play()」，而是「策略级限制」。
立即学习“前端免费学习笔记（深入）”；
- 检测前确保
video.muted = true，否则 iOS 上play()Promise 几乎必然 reject - 添加
video.setAttribute('playsinline', '')，否则 iOS 可能强制跳转全屏再失败 - 不要在页面 load 后立刻调用
play()，即使加了setTimeout也不行——必须绑定到明确的用户事件
服务端或构建时无法做运行时检测，别白费力气
没有 JS 运行环境（如 SSR 渲染、静态 HTML 预生成）时，所有「兼容性检测」都是无效的。所谓「UA 判断 iOS/Chrome 版本」早已不可靠：iOS 15+ 对 muted autoplay 支持变化频繁，Chrome 90+ 引入了更细粒度的权限控制，UA 字符串无法映射到具体策略行为。
唯一可行路径是：前端在用户首次交互后，用真实的 play() Promise 做试探，并根据结果降级（如显示「点击播放」按钮、加载 poster 图、提示静音等）。
最常被忽略的一点：很多开发者以为「检测通过就一劳永逸」，其实用户中途切走标签页、系统开启低电量模式、甚至视频源切换后，play() 都可能再次失败——得把 Promise 检测逻辑封装成可重试的工具函数，而不是只跑一次。
