浏览器根本没执行autoplay，因chrome≥66、safari≥11等主流浏览器默认拦截非静音且无用户交互的自动播放请求，仅将其作为策略判定输入项，不触发播放逻辑。
写了 autoplay 却没播，不是你漏了属性，是浏览器根本没执行它——现代所有主流浏览器（Chrome ≥66、Safari ≥11、Firefox、Edge）都已默认拦截非静音、无用户交互的自动播放请求。
video.autoplay 属性在 Chrome/Firefox 中为何静默失效
Chrome 和 Firefox 不再把 autoplay 当作“执行指令”，而是仅作为策略判定的输入项。它只参与“是否允许静音自动播放”的判断，不触发任何播放逻辑。常见现象包括：video.paused 始终为 true、readyState 停在 0 或 1、控制台干净无报错。
-
autoplay单独存在时，浏览器直接跳过，不调用play()，也不抛异常 - 即使加了
muted，若视频尚未加载元数据（readyState ），仍可能卡住首帧 -
preload="metadata"能加快元数据加载，但不能替代用户交互对有声播放的硬性要求 - Chrome 的媒体参与指数（MEI）只对已互动站点动态放宽策略，新访客首次访问仍受限
iOS Safari 下 autoplay + muted 完全无效的真正原因
iOS Safari 根本不解析 autoplay 属性本身——无论是否加 muted，它都会忽略。必须靠 JS 显式调用 video.play()，且该调用必须发生在用户手势事件（如 click、touchstart）的同步上下文中。
- 漏掉
playsinline或webkit-playsinline：视频会强制全屏，播放流程中断 - 用
touchend替代touchstart：iOS Safari 对touchend的用户激活（user activation）认定不稳定，优先用touchstart -
video元素初始被transform: scale(0.99)或opacity: 0影响：部分 iOS 版本会触发策略回退，导致内联失败 - 动态创建
video时，muted = true必须在play()前设置，顺序反了即无效
video.play() 被拒绝的典型错误和修复点
手动调用 video.play() 是目前最可靠的方式，但它极易失败。关键不是“怎么调”，而是“什么时候调、怎么兜底”。
- 必须在用户真实交互事件回调中**同步执行**，不能包在
setTimeout、Promise.then、fetch回调或scroll里 - 调用前检查
video.readyState >= 2，否则可能静默失败或抛NotAllowedError -
play()返回 Promise，务必加.catch(e => console.warn("播放被拒", e))；常见错误信息是"The request is not allowed by the user agent" - iOS Safari 下，若在播放开始后立即设
video.muted = false，Safari 17+ 会中断当前播放；应延迟一小段时间（如setTimeout(() => video.muted = false, 100)）并捕获失败
微信 WebView 和 Android X5 内核的特殊行为
微信内置浏览器（Android/iOS）使用 X5 内核，其 autoplay 行为与标准 Chromium 不一致，尤其在静音组合上更保守。
- Android 微信可能允许
muted + autoplay，但 iOS 微信几乎总是强制要求用户点击后才调用play() - X5 内核对
playsinline支持不完整，部分版本下需额外加x5-video-player-type="h5-page"和x5-video-player-fullscreen="false" - 服务端响应头若未正确设置
Content-Type: video/mp4，X5 可能降级为下载行为，导致黑屏无提示 - 不要依赖
Permissions-Policy: autoplay=()响应头——它对主文档完全无效，只影响 iframe 嵌入内容
最易被忽略的一点：autoplay 的成败不取决于你写了几个属性，而取决于 video 元素是否处于可播放状态（DOM 已挂载、可见、未被隐藏）、是否完成元数据加载、以及用户手势是否被浏览器认定为有效激活——这三个条件缺一不可，且无法通过调试器直接观测中间态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
