现代浏览器拦截 autoplay 的典型表现是视频静止在第一帧，需同时满足 muted、playsinline 和 webkit-playsinline 才能自动播放，且解静音必须在用户手势回调中执行。
autoplay 被浏览器拦截的典型表现
点开页面，<video></video> 标签加了 autoplay 和 muted，但视频就是不播——控制台没报错，DOM 里属性也正常，就是静止在第一帧。这是现代浏览器（Chrome、Edge、Safari）的默认策略：没有用户手势参与时，禁止自动播放非静音媒体。
必须同时满足 muted + playsinline 才能真自动播
光加 autoplay 不够，光加 muted 也不稳。iOS Safari 尤其严格：
-
muted是硬性前提，哪怕你后续用 JS 解除静音也不行——必须初始就静音 -
playsinline必须显式声明，否则 iOS 会强制全屏，且可能拒绝自动播放 - 部分安卓 WebView（如微信内置）还要求
webkit-playsinline
正确写法示例：
<video autoplay muted playsinline webkit-playsinline> <source src="video.mp4" type="video/mp4"> </video>
想取消静音？只能靠用户点击后手动调用 play()
自动播放阶段不能有声音，这是铁律。想恢复声音，得等用户真实交互（比如点击按钮）后再操作：
立即学习“前端免费学习笔记（深入）”；
- 不能在
DOMContentLoaded或load事件里直接video.muted = false - 必须在 click/touchend 等用户触发的回调中执行
video.play()，此时浏览器才允许解除静音 - 有些浏览器（如新版 Chrome）甚至要求该 click 事件是“可信任事件”，用
dispatchEvent模拟的无效
安全解静音示例：
button.addEventListener('click', () => {
video.muted = false;
video.play().catch(e => console.log('解静音失败:', e));
});
preload="auto" 有时反而坏事
preload 控制预加载行为，但设成 auto 可能触发额外资源请求，尤其在弱网或移动端，反而拖慢首帧渲染，甚至干扰 autoplay 流程：
- Chrome 对
preload="auto"+autoplay组合更敏感，容易因加载未完成而跳过自动播放 - 推荐改用
preload="metadata"，只加载头信息，足够支持自动播放逻辑 - 如果视频很小（preload，让浏览器自己判断
兼容性提示：Safari 13+ 对 preload 的处理更激进，none 可能导致首次播放卡顿，metadata 是较稳妥的平衡点。
自动播放不是开关问题，是用户意图识别问题。浏览器只信真实点击，不信任何“提前准备好的静音”或“延迟一秒再播”的取巧逻辑。最容易被忽略的，是把 play() 调用放在了异步回调里——比如 setTimeout 或 Promise.then 中，那它就不再是用户手势上下文了。
