移动端audio autoplay基本无效，是iOS和Android浏览器的强制策略；必须满足muted且用户真实交互（如touchstart）才可能播放，iOS甚至忽略autoplay、只认事件回调中同步调用play()。
移动端 audio 的 autoplay 属性基本无效——这不是 bug，是 iOS 和 Android 主流浏览器（包括微信 WebView）的强制策略。想让它响，必须绕过策略，而不是“修复”属性。
为什么 autoplay 在 iOS Safari 和安卓 Chrome 里完全没反应
浏览器根本不会执行这个属性，除非满足两个硬性前提：媒体已静音（muted），且用户已发生真实交互（如 touchstart 或 click）。iOS Safari 甚至直接忽略 autoplay，哪怕加了 muted，也只认 JS 调用的 play()，而且必须在事件回调中同步执行。
常见现象包括：audio.paused 始终为 true、控制台无报错但也没声音、Network 面板显示音频已加载成功但就是不播。
-
autoplay不是“失效”，是被策略级静默跳过 - 微信 iOS WebView 对静音 autoplay 也常不买账，首次触摸仍是唯一可靠触发点
-
playsinline对video是必需的，对audio无影响，别乱加
用 touchstart 触发 play() 的实操要点
这是目前兼容性最广、落地最稳的方式，尤其适合 H5 活动页或轻量应用。
立即学习“前端免费学习笔记（深入）”；
- 监听
touchstart（不是click，iOS 上 click 有 300ms 延迟，可能错过首帧） - 调用
play()必须在事件回调内直接执行，不能包在setTimeout、Promise.then或异步加载完成钩子里 - 建议加
{ once: true }，避免重复绑定导致多次播放或 Promise 拒绝堆积 - 务必处理
play()的 Promise 拒绝：.catch(e => console.warn("play blocked:", e))，否则失败无声无息
示例代码：
const audio = document.querySelector('audio');
document.addEventListener('touchstart', () => {
audio.play().catch(e => console.warn('自动播放被拒:', e.name));
}, { once: true });
静音 + autoplay 组合能否绕过限制
在桌面 Chrome/Firefox 和部分安卓 WebView 中，<audio muted autoplay> 可能“看起来”生效，但 iOS Safari 仍会拒绝，且微信 iOS 环境下成功率极低。它不是可靠路径，仅可作为降级兜底。
-
muted是必要非充分条件：加了不一定播，不加一定不播（带声情况下） - 不要依赖
muted后立刻unmute()：iOS 下解除静音后需再次调用play()，且该调用仍需用户手势上下文 - 如果目标是背景音乐，建议默认关闭，提供显式“开启音效”按钮，而非强行自动播放
容易被忽略的加载与状态陷阱
即使触发逻辑正确，play() 仍可能失败——问题常出在资源未就绪或 DOM 状态异常。
-
audio.readyState < 2时调用play()很可能被拒，可在touchstart前设audio.preload = 'auto'，但不保证加载完成时间 - 确保
audio元素已插入 DOM 且src有效；Safari 对file://协议或 404 音频源会静默失败，控件都不渲染 -
<source>标签必须带type属性（如type="audio/mpeg"），否则 Safari 可能跳过该源 - 避免
display: none或visibility: hidden包裹audio，部分 WebView 会判定为不可播放状态
真正卡住人的，往往不是“怎么播”，而是“播之前有没有真正准备好”。动手前先打开 Network 面板确认音频请求返回 200，再看 Console 是否有 "The request is not allowed by the user agent" 这类提示——那才是策略拦截，不是加载问题。
