Chrome桌面端autoplay必须静音才能“无声自动播放”，这是2018年起实施的严格策略：仅允许静音且无用户交互时自动播放，有声播放必须依赖用户手势触发。
Chrome桌面端的autoplay属性本身不触发播放，是否静音才决定能否“无声自动播放”——这是浏览器策略强制的结果，不是HTML规范或代码写法的问题。
为什么autoplay在桌面Chrome里必须静音才能生效
Chrome从2018年起默认启用严格自动播放策略，核心逻辑是：autoplay仅在满足“静音+无用户交互”时被允许；一旦有声，就必须等待用户点击、触摸等手势（user-gesture）才能启动。这不是bug，而是基于MEI（媒体参与度）和隐私安全的主动限制。
- 即使
<video autoplay muted>写了muted，若页面加载后JS又设vdo.muted = false且未触发play()在用户手势内，仍会失败 - 桌面端不会像移动端那样根据MEI阈值放宽限制，除非用户已对该域名有过明确交互（如点过播放按钮）
-
autoplay属性在HTML中只是“建议”，最终是否执行由浏览器策略层拍板，开发者无法绕过
autoplay + muted 仍失败的常见原因
写了autoplay muted却没播，往往不是漏了属性，而是被运行时状态覆盖或策略拦截：
- 视频资源加载失败（
networkState === 0或readyState < 4），play()被拒绝但控制台可能不报错 - 父容器
display: none或visibility: hidden，Chrome认为元素不可见，拒绝自动播放 - 使用
srcObject（如来自getUserMedia）时，autoplay属性完全无效，必须显式调用play()且需在用户手势内 - iframe嵌入的跨域视频，若未加
allow="autoplay"，即使主页面静音也无法播放
如何验证当前页面是否满足静音自动播放条件
别靠猜，直接查浏览器底层判断依据：
- 打开
chrome://media-engagement/，确认当前域名的MEI值是否≥0.5（桌面端通常需要这个阈值才可能有声自动播） - 在控制台运行
document.hasFocus()，返回false说明页面未激活，autoplay大概率被忽略 - 检查
<video>元素的paused、muted、readyState三者是否全为true/true/4 - 监听
play事件和error事件，失败时打印video.error，常见值如DOMException: The play() request was interrupted
真正可控的替代方案：避免依赖autoplay属性
把播放控制权收回来，比反复调试autoplay更可靠：
- 初始加载时设
vdo.muted = true并调用vdo.play()，成功后再根据AudioContext.state判断是否可取消静音 - 用
IntersectionObserver监听视频进入视口，再触发play()，比autoplay更符合用户预期 - 对关键视频，用
click或touchstart绑定一次性的play()，确保在用户手势上下文中执行 - 服务端注入
preload="metadata"+ 客户端延迟play()，能显著提升首次播放成功率
最常被忽略的一点：Chrome对autoplay的判定发生在元素插入DOM后的微任务阶段，如果视频节点是动态appendChild进来的，且没有muted属性或父容器不可见，策略会直接跳过——这时候连静音都不会给你机会。动手前先看computed style和offsetParent，比改autoplay参数有用得多。
