现代浏览器默认拦截非静音、无用户交互的自动播放，autoplay属性仅参与策略判定而不触发播放；ios safari完全忽略该属性，必须在用户手势事件中同步调用play()并确保muted设置正确、样式不影响内联播放。
写了 autoplay 却没播，不是代码写错了，是浏览器根本没执行它——现代所有主流浏览器（Chrome ≥66、Safari ≥11、Firefox、Edge）都已默认拦截非静音、无用户交互的自动播放请求。
autoplay 属性在 Chrome/Firefox 中为何静默失效
autoplay 在 Chrome 和 Firefox 中已不触发播放逻辑，只作为策略判定的输入项。它仅参与“是否允许静音自动播放”的判断，不调用 play()，也不抛错，控制台干净得像什么都没发生。
- 常见现象：
video.paused始终为true、readyState停在0或1、进度条不动 - 即使加了
muted，若视频尚未加载元数据（readyState ），仍可能卡在首帧 -
preload="metadata"能加快元数据加载，但不能绕过用户交互对有声播放的硬性要求
iOS Safari 完全忽略 autoplay 属性
iOS Safari 根本不解析 autoplay 属性本身——无论是否加 muted，它都会跳过。必须靠 JS 显式调用 video.play()，且该调用必须发生在用户手势事件（如 click、touchstart）的同步上下文中。
- 漏掉
playsinline或webkit-playsinline：视频强制全屏弹出，流程中断 - 用
touchend替代touchstart：iOS Safari 对touchend的用户激活（user activation）认定不稳定，优先用touchstart - 动态创建
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)）并捕获失败
真正容易被忽略的是：即使所有属性都写对了，只要 video 元素初始被 transform: scale(0.99) 或 opacity: 0 影响，部分 iOS 版本就会触发策略回退，导致内联失败——这类样式问题不会报错，却让整个自动播放链路静默崩塌。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
