preload="metadata"是最稳妥的默认选择，它仅拉取时长、宽高、封面帧等元信息，不下载音视频帧，需服务端支持accept-ranges: bytes且视频经faststart优化，ios safari恒按此执行。

preload 不是开关，配对了也不等于生效——它只是建议，真正起作用的是 DOM 状态、服务端响应头、用户交互时机和浏览器 UA 策略。

preload="metadata" 是最稳妥的默认选择

多数场景下，preload="metadata" 能在省流量、快响应、UI 可用三者间取得平衡：只拉取时长、码率、是否含封面等元信息，不下载音频帧数据。尤其当你需要显示进度条或时长（controls 属性开启时），这是浏览器实际倾向走的路径，哪怕你写了 preload="auto"。

• iOS Safari 恒等于 metadata，写 auto 反而误导自己
• 服务端必须返回 Accept-Ranges: bytes，否则浏览器可能被迫下载前几 MB 才能读到时长（常见于 Nginx 默认配置或 FFmpeg 未加 -movflags +faststart）
• 监听 loadedmetadata 事件才是确认元信息就绪的唯一可靠方式，别信 readyState 或 Network 面板里“没看到请求”就断定失败

preload="none" 并不阻止所有请求

设成 preload="none" 是告诉浏览器“暂不加载”，但 Chrome 等桌面浏览器在用户首次点击 play() 前，仍可能悄悄拉取前几 KB（如 ID3 头或 AAC ADTS 帧），只为缩短首播延迟。这不是 bug，是 UA 的主动优化。

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

• 该行为在后台标签页、Low Power Mode、Data Saver 开启时会被抑制
• 微信 X5 内核更激进：哪怕 preload="none"，只要调用 play()，就立即发起请求并缓存前 1–2MB
• 若音频体积小（

preload="auto" 在哪些情况根本不起作用

写了 preload="auto" 却没发请求，大概率不是代码错了，而是环境压制了它：

• 页面刚打开、tab 未激活、或无用户交互焦点（Chrome/Edge 默认延迟加载）
• 设备开启 Low Power Mode（iOS）或 Data Saver（Android Chrome），自动降级为 metadata
• audio 元素还在 DocumentFragment 里没插入 DOM，或父容器 visibility: hidden
• 服务端响应头缺失 Content-Length 或返回 Accept-Ranges: none，浏览器放弃分段预取
• 设置了 autoplay —— 多数桌面浏览器会忽略 preload 值；但 iOS Safari 禁止自动播放，此时 preload="auto" 也无效

真要预加载，光写 preload 属性远远不够

强依赖快速就绪的场景（比如游戏音效、通知提示音），必须组合干预：

• 确保 audio 已插入 DOM（display: none 可以，但不能未挂载）
• 手动设置 preload="none" → 赋值 src → 立即调用 load() → 监听 canplaythrough
• 配合 <link rel="preload" as="audio" href="xxx.mp3"> 提前声明资源优先级（注意：as 必须是 audio，type 强烈建议带上）
• 动态改 preload 值（比如从 none 改成 auto）不会触发重加载，必须重设 src 或显式调用 load()

真正难的不是写对属性值，而是判断当前环境是否允许加载、何时加载、加载了多少——这些都得靠事件监听和网络面板交叉验证，不能只信 HTML 里的那行字。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！