preload="metadata" 仅加载音频文件开头若干KB以提取时长等元数据，不触发完整下载；但若文件结构缺失关键头信息（如MP3无Xing头）、moov box位置不当或服务端不支持Range请求，duration仍为NaN。
preload="metadata" 到底加载了什么
它只请求音频文件的开头一小段（通常是前几 KB），用于提取时长、采样率、声道数、编码格式等元数据，不会触发完整下载，也不代表能立即播放。浏览器具体读多少由实现决定，Chrome 通常读 ~64KB，Safari 可能更少；如果文件头部不含时长（如某些 MP3 缺少 Xing/VBRI header 或 FLAC 无 SEEKTABLE），duration 仍会是 NaN。
为什么设置了 metadata 还是 duration 为 NaN
元数据可读性依赖文件本身的结构完整性，不是 preload 属性能强制解决的：
- MP3：缺少 VBR 头（Xing 或 VBRI）时，浏览器无法推算总时长，即使 preload="metadata" 也返回
NaN - MP4/AAC：若 moov box 在文件末尾（常见于未优化的 FFmpeg 输出），浏览器读完开头几 KB 也拿不到时长信息
- WebM/Opus：一般支持较好，但若 muxer 未写入 Duration 元素，同样失败
- 服务端响应头缺失
Accept-Ranges: bytes，会导致浏览器放弃 range 请求，退化为 full load 或直接失败
如何验证 preload 是否生效
别只看 Network 面板的“size”，重点看请求的 Range 请求头和响应状态码：
- 打开 DevTools → Network → Filter 输入
media或文件名 - 刷新页面，找到该音频请求，确认它是
206 Partial Content而非200 OK - 查看 Request Headers，应含类似
Range: bytes=0-65535 - 对比
preload="none"和"metadata"的请求字节数差异——后者明显更小（通常 ≤ 128KB）
如果看到完整文件被拉取（size 接近文件总大小），说明 preload 被忽略，常见原因是：autoplay 属性存在（现代浏览器会自动提升 preload 级别）、或用户已交互过且浏览器策略升级为 auto。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
metadata 和 auto/none 的实际影响差异
三者对资源、性能、用户体验有实质性区别，不能只看语义：
-
preload="none"：不发任何请求，duration始终为NaN，调用play()才开始加载，首播延迟高 -
preload="metadata"：发一次小范围 Range 请求，获取基础信息，duration有可能可用，UI 可提前渲染进度条（但需监听loadedmetadata事件） -
preload="auto"：行为不可控——浏览器可能加载前 10%、整个文件，甚至根据网络类型（如 Data Saver 模式）完全禁用，且容易触发预加载带宽占用
真正可控的“仅元数据”只有 metadata，但它不是银弹：文件结构不友好、服务端不支持 range、或用户快速点击播放，都可能导致你拿到的仍是 NaN。最稳的方式，是在后端提供独立的 JSON 元数据接口，前端先 fetch 它再设置 audio.src。
