audio标签直接src跨域MP3会静默失败，networkState为0、duration为NaN且无报错；必须通过同源代理中转并配置正确Content-Type与CORS头，同时绑定用户手势触发play()并捕获NotAllowedError。
audio 标签直接 src 跨域 MP3 会静默失败
浏览器根本不会尝试加载跨域音频，更不会报错——它只是跳过 src，最终 audio 元素停留在 networkState === 0（NETWORK_EMPTY），duration 为 NaN，控制台也无提示。这不是代码写错了，是 CORS 策略在底层拦截了资源请求。
必须用同源代理中转，且响应头要严格匹配
前端无法绕过跨域限制，唯一可靠路径是让后端做一层代理：你的服务器发起请求获取远程 MP3，再以正确头返回给前端。关键三点缺一不可：
-
Content-Type必须设为audio/mpeg（不是audio/mp3） -
Access-Control-Allow-Origin设为*或具体域名 - 避免额外重定向（302），否则浏览器可能丢弃 CORS 头
Node.js 示例中，用 fetch(remoteUrl).then(res => res.buffer()) 再 res.send(buffer) 是安全的；但直接 response.body.pipe(res) 需确保原始响应头不含冲突字段（如 Content-Encoding: gzip 未被解压就转发会导致播放失败）。
source 多格式 fallback 在跨域场景下照样失效
即使你写了多个 <source>，只要每个 src 都跨域且服务器没配 CORS，浏览器会逐个发起请求、全部 404，最后触发 error 事件，而不是“跳到下一个”。此时：
立即学习“前端免费学习笔记（深入）”；
- 别依赖
canplay或loadeddata—— 它们根本不会触发 - 必须监听
error事件：audio.addEventListener('error', e => console.warn('load failed:', e.target.error?.code)) - 错误码
MediaError.MEDIA_ERR_NETWORK（值为 2）即表示跨域或网络中断
iOS Safari 对跨域音频有额外静音锁定
即使代理解决了 CORS，iOS 上首次播放仍可能失败，因为 WebKit 要求用户手势（click/touchstart）后才能解锁音频能力。这意味着：
- 不能在
DOMContentLoaded里调play()，哪怕已加载完成 - 必须绑定一次用户交互，比如
document.body.addEventListener('click', initAudio, { once: true }) - 调用
play()后必须.catch(e => console.debug('iOS blocked:', e.name))—— 常见拒绝名是NotAllowedError
跨域音频真正的难点不在“怎么播”，而在“什么时候能播、凭什么能播”。代理解决的是网络层，iOS 手势+Promise 捕获解决的是策略层，漏掉任一环，页面就只剩一个哑巴 audio 元素。
