Safari不响因未声明MIME类型，需用<source>显式指定type；200状态不代表可播，须检查Content-Type响应头；play()需用户手势触发且元素可见；离线时仅preload="metadata"可靠；务必真机测试。
audio 标签只写 src 属性为什么在 Safari 里不响
因为 Safari（尤其是 iOS）根本不会尝试加载没声明 type 的 <source>，哪怕路径完全正确、文件就在同一目录下。它不是“播不了”，而是“压根不认这个源”。Chrome 可能碰巧成功，但那是运气，不是规范。
必须用 <source> 显式声明 MIME 类型：
-
MP3对应type="audio/mpeg"（不是audio/mp3） -
OGG对应type="audio/ogg"，且音频编码需为 Vorbis（Opus 在部分旧 Safari 中不可靠） -
WAV对应type="audio/wav"，仅作短提示音兜底，别放第一位
顺序很重要：浏览器按 DOM 顺序逐个尝试，把兼容性最广的 MP3 放最前，WAV 放最后。
为什么 Network 面板里音频请求状态是 200 却 still 没声音
200 只代表 HTTP 请求成功，不代表浏览器解码器接受了它。关键要看响应头里的 Content-Type —— 如果服务器返回的是 text/plain 或空着，浏览器会当普通文本扔掉，连错误都不报。
立即学习“前端免费学习笔记（深入）”；
本地开发时，双击 HTML 文件走 file:// 协议，Chrome/Firefox 直接屏蔽音频加载，控制台可能静默失败。必须用本地服务：
- Python 用户：
python3 -m http.server 8000 - Apache 用户：在
.htaccess加AddType audio/mpeg .mp3 - Nginx 用户：在
types块加audio/mpeg mp3;
检查方式：打开 Network 面板 → 点击音频请求 → 查看 Response Headers → 确认 Content-Type 值准确匹配后缀和编码。
JS 调用 play() 报 NotAllowedError 怎么办
这不是代码写错了，是浏览器策略强制拦截。现代浏览器（包括微信 iOS）要求首次有声播放必须由用户真实手势触发，比如点击、触摸、键盘输入。DOMContentLoaded、setTimeout、甚至 click 事件冒泡到 document 都不算数。
安全写法只有这一种：
- 删掉
autoplay属性 - 绑定明确的用户操作，例如：
document.querySelector('#playBtn').addEventListener('click', () => audio.play().catch(e => console.warn('play rejected:', e))) - iOS 还额外要求：元素不能被
display: none、opacity: 0或视口外遮挡，否则即使点过也静音
静音自动播（autoplay muted）虽在桌面端较稳，但 iOS Safari 仍可能因未获手势授权而失败 —— 别依赖它。
preload 和 canplay 事件在离线或移动端有多坑
preload="auto" 在 iOS 上基本被忽略；在离线环境里，它会让浏览器尝试加载整段音频，一旦文件稍大或路径微偏，就卡死：控件不渲染、duration 为 NaN、play() 静默失败。
离线场景唯一可靠的是 preload="metadata"：只拉取头信息（时长、采样率），保证控件立即出现，后续播放再按需加载。但注意：
-
canplay不等于“音频体已就绪”，它只表示元数据加载完成；真正要确保可播，iOS 必须等canplaythrough或手动监听loadeddata - 不要在
load回调里直接play()，iOS 不认这种上下文 - 设置
currentTime必须分平台：iOS 等canplay后设，Android 可设完立刻play()
最容易被忽略的一点：所有这些策略差异，在桌面 Chrome 里几乎都表现良好 —— 所以务必在真机（尤其 iOS Safari）上验证，而不是只信本地开发效果。
