preload="auto" 并不能保证整首音频预加载，因浏览器依带宽、内存、用户设置等自主截断；需用 fetch+Blob+createObjectURL 绕过限制，但 iOS Safari 仍要求首次播放由用户手势触发。
preload="auto" 并不能保证后台静默预加载整首音频——浏览器是否真正下载、下载多少、是否缓存，完全由其自主策略决定，且现代浏览器（Chrome、Firefox、Safari）普遍会忽略 preload="auto" 的“全量预加载”意图，尤其在移动设备或节电模式下。
为什么 preload="auto" 常常不加载整首？
这是设计使然，不是 bug。规范明确说明：preload="auto" 仅表示“作者建议浏览器尽可能多地预获取媒体资源”，但浏览器有权根据带宽、内存、用户设置（如“节省数据”）、是否在后台标签页等条件动态截断加载。实测中，Chrome 通常只请求前几秒（Content-Range: bytes 0-16383/...），然后暂停；Safari 更激进，可能只拉取元数据（Content-Range: bytes 0-1999/...）就停。
想静默加载整首？用 fetch() + Blob + URL.createObjectURL()
绕过 <audio> 的预加载限制，主动发起完整请求并缓存到内存：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
const audio = document.querySelector('audio');
fetch('/path/to/audio.mp3')
.then(res => res.blob())
.then(blob => {
const url = URL.createObjectURL(blob);
audio.src = url;
// 此时 audio.readyState === 4（HAVE_ENOUGH_DATA），已可立即播放
});
- 必须使用
fetch()（而非XMLHttpRequest），才能拿到Blob且支持流式读取与完整响应 -
URL.createObjectURL()创建的地址是内存引用，不触发二次网络请求 - 该方式不受
preload属性影响，也不依赖用户交互（无需用户点击后才加载） - 注意：大音频文件会占用内存，iOS Safari 对 Blob URL 生命周期较短，页面切换后可能失效
移动端 Safari 的特殊坑：即使 fetch 完整，也可能无法自动播放
iOS Safari 要求音频首次播放必须由用户手势触发（click、touchend），即使 src 已就绪。常见错误是：
立即学习“前端免费学习笔记（深入）”；
- 在
fetch回调里直接调用audio.play()→ 报错NotAllowedError: The request is not allowed by the user agent - 解决办法：把
play()绑定到真实的用户事件上，哪怕只是静音播放一次 - 示例：
button.addEventListener('click', () => audio.play().catch(e => console.warn('autoplay blocked'))) - 后续调用
play()不再受阻（只要未被中断）
真正的难点不在“怎么加载”，而在“加载完怎么让它随时可播”——尤其是跨平台兼容性。iOS 的 autoplay 策略、Android Chrome 的后台标签页节流、Firefox 的隐私模式拦截，都会让看似简单的预加载变得高度上下文相关。动手前先用 Network 面板确认实际请求范围，比盲信 preload 更可靠。
