audio标签preload="metadata"仅加载元信息（时长、码率等），不下载音频主体；真要静默预加载全部音频，须用preload="auto"+muted+autoplay组合，并在canplaythrough后调用pause()。
audio 标签加 preload="metadata" 不等于静默预加载
直接写 <audio preload="metadata"></audio> 只会预加载时长、码率等元信息，不会下载音频主体——这常被误认为“静默预加载”，其实它根本没加载音频数据。真要静默预加载（即后台悄悄下完全部音频但不播放、不触发 play()、不响一声），必须配合 preload="auto" 和 muted + autoplay 的组合，并立刻暂停。
正确做法：用 preload="auto" + muted + autoplay + pause()
浏览器对 preload="auto" 的实际行为是“尽力预加载全部内容”，配合静音和自动播放能触发下载，再立即暂停就能实现「无声下载完成」的效果。关键点在于时机控制：
-
autoplay必须存在，否则 Chrome/Firefox 在多数场景下拒绝预加载主体（尤其移动端） -
muted是绕过静音策略的必要条件，否则autoplay会被拦截 -
pause()要在canplaythrough或loadeddata后调用，不能放onload或太早——否则可能只下了开头几秒 - 建议监听
canplaythrough事件，它表示“当前已加载足够多数据，可连续播放全程而无需缓冲”
示例代码：
<audio id="bgm" src="sound.mp3" preload="auto" muted autoplay></audio>
<script>
const audio = document.getElementById('bgm');
audio.addEventListener('canplaythrough', () => {
audio.pause(); // 确保此时已基本下完
audio.currentTime = 0; // 重置位置，避免后续 play() 从中间开始
});
</script>
为什么不用 preload="none" 或 JS fetch() + Blob？
这两种方式看似可控，但各有硬伤：
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
-
preload="none"：完全禁用预加载，后续play()会卡顿，且无法触发浏览器原生的 HTTP 缓存复用（比如同一音频在多个audio标签中重复使用） -
fetch()+Blob：需手动管理缓存、内存释放；Blob URL无法被浏览器音频解码器直接识别为“可流式播放资源”，部分安卓 WebView 会报DOMException: The element has no supported sources - 更重要的是：
fetch下载的二进制数据 ≠ 浏览器内部音频缓冲区。即使你存了Blob，调用play()时仍可能触发二次解码或缓冲，达不到“即点即播”效果
移动端兼容性与隐藏坑
iOS Safari 和 Android Chrome 对静音自动播放限制极严，哪怕加了 muted，首次用户交互前也可能不触发下载。应对策略：
- 不要依赖“页面一打开就静默预加载完成”，把预加载动作绑定到首个用户操作（如点击按钮、滚动到底部）更可靠
- 避免在
DOMContentLoaded中立即调用play()—— iOS 会直接拒绝并抛出NotAllowedError - 检查
audio.networkState：若为NETWORK_NO_SOURCE或NETWORK_EMPTY，说明资源未加载；NETWORK_LOADING表示正在下，NETWORK_LOADED才算真正就绪 - 某些安卓厂商浏览器（如华为、小米）会忽略
muted，需额外加volume=0并设loop防止因静音导致播放状态异常
静默预加载本质是借浏览器播放链路“骗”它提前下载，不是标准功能，所以边界行为多、平台差异大。最稳的做法，永远是让用户点一下再开始加载。
