preload="metadata"是兼顾兼容性与响应速度的务实选择，仅加载时长、采样率等元数据，不下载音频体，play()时再按需加载主体；auto不保证预缓存，反而可能拖慢首屏、浪费带宽，且在iOS Safari和Android Chrome中常被节流或忽略。
audio preload 属性到底该设成 auto 还是 metadata
设成 auto 不等于“一定能缓存”，反而可能触发浏览器提前下载完整音频，拖慢首屏、浪费带宽；设成 metadata 才是兼顾兼容性与响应速度的务实选择——它只拉取时长、采样率等元数据，不加载音频体，play() 调用时再按需加载主体。
常见错误是以为 preload="auto" 就能“预热”音效，结果在弱网或低端设备上卡住 DOM 渲染，甚至被浏览器主动中止请求。移动端尤其明显：Safari iOS 和 Chrome Android 都对 auto 有更激进的节流策略。
-
preload="none"：适合纯手动触发、且音频非关键路径的场景（如表格行点击音效） -
preload="metadata"：推荐默认值，90% 以上交互类音频都适用（比如按钮反馈、列表项音效） -
preload="auto"：仅当音频是页面核心内容（如播客详情页主音频）、且你已确认用户带宽稳定时才考虑
为什么 src 动态赋值后 play() 会失败
不是缓存问题，而是浏览器要求 play() 必须在用户手势（click/touchend）同步上下文中调用。如果 src 改完后塞进 setTimeout、Promise.then 或事件回调里再 play()，大概率报错 DOMException: play() failed because the user didn't interact with the document first。
实操要点：
立即学习“前端免费学习笔记（深入）”；
- 确保
audio元素已挂载到 DOM，且src已写入（可检查audio.src是否非空） - 在 click/touchend 回调内直接调用
audio.play()，不要加任何异步包裹 - 必须监听
play()返回的 Promise，.catch(e => console.warn("play failed:", e))，否则静默失败 - 避免复用前一个未结束的播放实例——先
audio.pause()再audio.currentTime = 0，再play()
多个音频文件如何减少重复请求和内存占用
每个 audio 标签实例都会独立发起 HTTP 请求，即使 src 相同。浏览器不会自动复用已缓存的音频资源，除非你显式控制实例生命周期。
正确做法是全局只维护一个 audio 元素，通过切换 src 来复用它：
- 把
audio放在<body>底部，而非塞进每行表格或每个卡片内部 - 每次触发播放前，先
audio.src = newSrc，再audio.play() - 监听
canplay或loadeddata事件来判断是否就绪，而不是依赖preload值 - 服务端务必设置
Cache-Control: public, max-age=31536000，让音频文件走强缓存
CORS 和跨域音频文件的缓存陷阱
如果音频来自 CDN 或第三方域名，且响应头没带 Access-Control-Allow-Origin，即使文件已缓存，play() 仍会因 CORS 策略拒绝执行——浏览器缓存不绕过同源检查。
验证方式：打开 DevTools → Network → 找对应音频请求 → 查看 Response Headers 是否含 Access-Control-Allow-Origin: * 或具体域名。
临时绕过方法（仅开发）：audio.crossOrigin = "anonymous"，但前提是服务端已配好 CORS 头；生产环境必须由服务端修复，前端无法补救。
容易被忽略的是：某些 CDN 默认关闭音频 MIME 类型的 CORS 支持，需单独开启 audio/* 的跨域策略，不能只配 image/* 或通配 */*。
