iOS Safari禁止自动播放音频，必须通过用户手势同步调用play()解锁；需先用muted属性静音初始化audio，再解除静音；Web Audio API也需在手势中初始化并resume AudioContext。
iOS Safari 默认禁止自动播放音频
iOS 的 WebKit 内核对 HTML5 有严格限制：未经过用户手势（如 tap、click）触发的音频，即使调用了 play()，也会静音且不报错。这是系统级策略，不是 bug，也绕不过去。
常见现象包括：
- 页面加载后立即
audio.play()→ 控制台无报错，但没声音 - 定时器（
setTimeout）延迟调用play()→ 同样无效 - 在
document.addEventListener('touchstart', ...)里调用 → 有效，但必须是**首次交互**后的同步调用
必须用用户手势触发 play() 才能解禁
只有在真实用户操作回调中，同步执行 play()，iOS 才会允许音频上下文进入“可播放”状态。注意“同步”二字——不能包在 Promise.then()、setTimeout(..., 0) 或异步事件里。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把
初始化放在body中，但先不调play() - 绑定一个显式按钮（哪怕透明），例如：
- 在
button.addEventListener('click', () => { audio.play().catch(e => console.warn('play failed:', e)); })中调用 - 成功后可记录状态，后续
play()就不再被拦截（只要没刷新页面）
audio 标签要加 muted 和 playsinline 属性
虽然 muted 看似矛盾（你要声音），但它其实是 iOS 解锁音频能力的“钥匙”之一：带 muted 的 可以在非手势上下文中自动播放（静音），从而激活音频上下文；之后再取消静音就能出声。
同时必须加 playsinline，否则 iOS 会强制全屏播放视频类音频（比如含视频轨道的 m3u8），导致行为不可控。
推荐写法：
后续 JS 中：
const audio = document.getElementById('bgm');
// 第一次用用户手势触发（可静音）
audio.play().then(() => {
audio.muted = false; // 解除静音
audio.play(); // 再次尝试播放（此时已有权限）
}).catch(e => console.error(e));
Web Audio API 在 iOS 上更可靠但有额外约束
如果项目已用或可改用 Web Audio（比如需要精确控制、混音、动态生成），它比 更容易获得播放权限，但仍需用户手势初始化 AudioContext。
关键点：
-
new AudioContext()必须在用户手势回调中调用，不能提前创建 - 首次
context.resume()也必须在手势回调中 —— 这才是真正的“解锁”动作 - 之后所有
bufferSource.start()都可用，无需再等手势 - 注意 iOS 15+ 对
AudioContext的 suspend 恢复更敏感，不要依赖后台定时恢复
简单验证是否就绪：
button.addEventListener('click', () => {
if (!window.ctx) window.ctx = new (window.AudioContext || window.webkitAudioContext)();
window.ctx.resume(); // 这行必须在 click 里
});
iOS 上 HTML5 音频最常被忽略的，不是怎么写 play()，而是没意识到“首次播放权限”和“后续播放能力”是两个阶段——前者必须靠真实点击，后者才能自由调用。很多方案失败，是因为把解锁逻辑藏在了异步链里。 
