autoplay属性仅请求自动播放，能否成功取决于muted、用户交互等运行时条件；静音（muted）是绕过限制最有效方式，需搭配playsinline和preload="metadata"；用户点击后须在事件回调内先play()再设muted=false。
autoplay 属性本身不能绕过浏览器限制，它只是“请求”自动播放；真正能否播，取决于 muted、用户交互状态、设备类型和媒体参与度（MEI）等运行时条件。
为什么加了 autoplay 还是不播？
现代浏览器（Chrome、Safari、Firefox）默认阻止带声音的自动播放，不是 bug，是策略。常见现象包括：
- 页面一打开，
完全没反应，控制台也无报错 - 视频首帧显示为静态图，
controls按钮可见但播放按钮灰色不可点 - 移动端（尤其是 iOS）即使加了
autoplay和muted，仍可能被强制全屏或静音失效
根本原因：浏览器把“自动播放”拆成两个独立判断——是否允许播放 + 是否允许发声。二者必须同时满足才成功。
muted 是最简单有效的绕过方式
只要视频初始静音，几乎所有主流浏览器都允许 autoplay 执行。但要注意细节：
-
muted必须是布尔属性，写成muted或muted=""都行，但muted="false"无效 - 不要依赖 JS 后续再设
video.muted = false—— Safari 会拒绝解除静音，除非发生在用户交互回调内 - 搭配
playsinline可避免 iOS 强制全屏，否则即使静音也会跳转到原生播放器 -
preload="metadata"能减少白屏时间，尤其对大视频或 HLS 流很关键
推荐写法：
<video autoplay muted playsinline controls preload="metadata"><source src="demo.mp4" type="video/mp4"></source></video>
用户点击后才开声音，怎么安全切换？
想在静音自动播放后，让用户点一下就恢复有声，得在交互事件里做两件事：
- 先调用
video.play()（哪怕它已播着，这是 Safari 的激活要求） - 再设
video.muted = false，且必须在同一个事件处理函数内完成 - 捕获
.catch()，因为部分用户可能已禁用媒体权限，此时play()会 reject - 避免在
scroll或mousemove里触发——这些不算“强交互”，Chrome 不认可
示例：
const video = document.querySelector('video');
document.addEventListener('click', () => {
video.play().then(() => {
video.muted = false;
}).catch(e => {
console.warn('开声失败，可能是权限问题', e);
});
});
iOS 上的音频元素更难搞，别只盯 video
HTML5 audio 在 iOS 上有额外限制：首次交互后，每个 audio 元素都需单独“激活”。常见坑点：
- 只对一个
audio调用play()，不能让其他同页面的audio获得播放权 -
play().then(pause())是必须步骤，仅load()不够 - 不能用
setTimeout延迟激活——必须紧接在用户事件回调内同步执行 - HLS 或 MSE 流媒体（如 hls.js）需等
Hls.Events.MEDIA_ATTACHED后再激活，否则play()会失败
复杂点在于：这个激活逻辑要覆盖所有可能用到的音效、背景音乐、提示音，漏掉一个，后续就再也播不出声。别指望一次交互全局生效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
