autoplay 属性仅是播放请求，现代浏览器默认忽略，须配合 muted、playsinline 等属性并在用户交互后才能可靠生效；静音是前提，用户手势是关键，readyState≥2 和 playing 事件是验证依据。
autoplay 属性本身只是个“请求”——它告诉浏览器“我想一加载就播”，但现代浏览器（Chrome ≥66、Safari ≥11、Edge ≥79）默认会忽略这个请求，除非满足静音或用户交互等硬性条件。它不保证播放，也不绕过策略，只参与策略判定流程。
为什么写了 autoplay 还是不播
常见错误现象：视频标签写了 autoplay，页面刷新后完全没反应，控制台也无报错；或者在 iOS Safari 里直接全屏跳转、卡在黑屏。
- 不是 bug，是策略：浏览器主动拦截未静音且无用户手势的播放意图
-
autoplay单独存在时，Chrome/Safari 会静默丢弃，不触发play()，也不抛错 - 移动端（尤其微信 X5 内核、QQ 浏览器）甚至会忽略
muted+autoplay组合，除非配合playsinline和同步用户事件 - 服务端未配置 CORS、视频格式非 H.264 MP4、路径 404 等底层问题，也会导致
autoplay“失效”（实际是加载失败）
autoplay 必须和哪些属性一起用才有效
仅靠 HTML 属性生效的唯一可靠组合是：autoplay + muted + playsinline（+ webkit-playsinline）
-
muted必须是 HTML 属性（不能 JS 动态设），否则 Safari 12–15 可能拒绝 autoplay -
playsinline防止 iOS 全屏，同时 Android Chrome 也需要它保持内联行为 -
webkit-playsinline是旧版 iOS 兼容写法，建议保留（尤其需支持 iOS 10–12 的项目） -
preload="metadata"不影响 autoplay 权限，但能加快首帧渲染，减少白屏时间
示例正确写法：
立即学习“前端免费学习笔记（深入）”；
<video autoplay muted playsinline webkit-playsinline> <source src="hero.mp4" type="video/mp4"> </video>
有声播放必须等用户点击，但不能随便点
用户交互不是“任意点击都行”，而是必须满足浏览器认定的“user activation”上下文，否则 play() 仍会抛 NotAllowedError。
- 有效事件：同步触发的
click、touchstart（iOS Safari 对touchend支持不稳定，优先用touchstart） - 无效场景：放在
setTimeout、Promise.then、fetch回调、scroll或mousemove里调用play() - 首次交互后，可安全执行
video.muted = false→video.play()，此时有声播放被允许 - 不要用
volume = 0.001替代muted，Chrome 已将其视为等效静音，且部分版本仍拦截
怎么确认 autoplay 实际生效了
不能只看有没有报错，很多浏览器静默失败（readyState 不变、paused === true、也不触发 playing 事件）。
- 检查
video.readyState >= 2（表示已有足够数据可播放） - 检查
!video.paused，而非只看video.playing（该属性不存在） - 监听
playing事件比监听play更可靠，它表示真正进入播放状态 - 移动端建议加兜底逻辑：若
playing未触发，3 秒后显示“点击播放”按钮
检测示例：
video.play().catch(() => {}); // 先调用，不依赖返回值<br>video.addEventListener('playing', () => console.log('真·开始播了'));<br>setTimeout(() => {<br> if (video.readyState < 2 || video.paused) {<br> showPlayButton();<br> }<br>}, 3000);
最易被忽略的是 readyState 判断时机——play() 调用后立即查可能还是 0，得等加载完成；而 playing 事件才是最终确定信号。
