chrome 66+ autoplay策略允许muted、高mei值或pwa添加到主屏幕时有声自动播放；需用户手势触发play()，web audio须调用resume()；iframe不直接破限，依赖父页面手势与allow="autoplay"声明。
关键判断：只要满足 muted、user gesture、MEI 阈值达标 三者之一，音频就能播；否则调用 audio.play() 会直接抛出 NotAllowedError: play() can only be initiated by a user gesture.
哪些情况能绕过限制直接播放？
Chrome 允许以下三种场景下的有声自动播放，无需用户点一下：
-
muted属性存在（哪怕只是临时加再立刻取消静音，部分版本仍可触发上下文激活） - 当前域名在该设备上已有足够高的媒体参与度（
MEI），可通过chrome://media-engagement/查看评分 - 页面是 PWA 并已添加到主屏幕（尤其在移动端，Chrome 会放宽策略）
为什么 audio.play() 在 onload 里总失败？
因为 DOMContentLoaded 或 window.onload 不构成可信用户手势。Chrome 只认明确由用户触发的事件回调，比如：
-
click、touchstart（注意：touchend在某些 Android 版本不被信任） -
keydown（仅限可触发输入的键，如Enter、Space） -
pointerdown（比mousedown更可靠，尤其在触屏设备）
常见错误是监听了 scroll 或 mousemove 后调用 play()——这些事件不被视为有效手势，浏览器直接拒绝。
Web Audio API 也被卡住？
是的，而且更隐蔽：AudioContext 在无用户交互时初始化即处于 suspended 状态，所有节点（OscillatorNode、BufferSourceNode）都发不出声。必须在手势回调中首次调用 audioContext.resume() 才能解挂。
示例：
let audioContext;
document.body.addEventListener('click', () => {
if (!audioContext) audioContext = new (window.AudioContext || window.webkitAudioContext)();
audioContext.resume().then(() => console.log('AudioContext resumed'));
});
漏掉 resume() 是 Web Audio 开发中最常被忽略的兼容性断点。
iframe 里放 audio 能破限吗？
不能直接破限，但可间接利用权限继承：
- 父页面有用户交互 → iframe 可通过
allow="autoplay"获得播放权限 - iframe 的
src必须是同源或显式声明allow="autoplay"，否则 Chrome 会忽略 - 跨域 iframe 即使加了
allow，若父页面未激活，依然受限
所以单纯把 <audio></audio> 塞进 iframe 并不会 magically 工作，必须配合顶层手势传递。
play()，不同 Chrome 小版本行为不一致。建议始终以「首次播放必经用户点击」为底线设计，其他都是临时适配。
