autoplay属性在Chrome/Firefox中静默失效，因仅参与静音自动播放判定而不触发播放；iOS Safari完全忽略该属性，必须通过用户交互触发video.play()并满足playsinline、视口可见等条件。
autoplay属性在Chrome/Firefox中为何静默失效
浏览器根本没执行它——Chrome ≥66 和 Firefox ≥66 把 autoplay 当作策略输入项，而非播放指令。它只参与“是否允许静音自动播放”的判定，不触发任何播放逻辑。常见现象包括：video.paused 始终为 true、readyState 停在 0 或 1、控制台干净无报错。
必须同时带 muted 才可能被考虑；若视频尚未加载元数据（readyState < 2），即使属性全对也会卡在首帧。别指望 preload="auto" 救场——它只影响预加载，不解决策略拦截。
iOS Safari完全忽略autoplay属性
iOS Safari 不解析 autoplay 属性本身，无论是否加 muted，一律忽略。你写 <video autoplay muted> 和不写，效果一样。
唯一可行路径是 JS 显式调用 video.play()，且该调用必须满足三个硬性条件：
立即学习“前端免费学习笔记（深入）”；
- 发生在用户真实交互事件（
click或touchstart）的同步回调内，不能包在setTimeout、fetch.then或滚动监听里 -
video元素已设playsinline（iOS 必需），旧版还需补webkit-playsinline - 元素在视口内可见，且父容器未设
display: none或visibility: hidden
有声自动播放必须靠用户手势触发
所有主流浏览器（Chrome、Firefox、Safari、Edge）都要求：有声视频的首次播放必须由用户真实交互触发。这不是可选优化，而是强制策略。
实操要点：
- 监听
document.addEventListener('click', handler, { once: true })，在handler中调用video.play() -
video.play()返回 Promise，务必加.catch(e => console.warn("播放被拒", e))，典型错误是"The request is not allowed by the user agent" - 不要在播放刚启动时立刻设
video.muted = false——Safari 17+ 会中断播放；应延迟约100ms后再尝试，并捕获失败
移动端微信 WebView 的特殊行为
微信内置浏览器（Android/iOS）对 autoplay 的处理极不一致：
- Android 微信可能允许静音自动播放，但依赖 UA 和版本，不可靠
- iOS 微信几乎完全禁用 autoplay，连
play()调用也常被拒绝，尤其在非主域或 iframe 场景下 - 建议 UA 检测后降级：对微信环境直接隐藏自动播放逻辑，改用按钮引导
最易被忽略的是 iOS 上 playsinline 的缺失和用户交互时机的错位——漏掉任一，就等于整段逻辑白写。
