audio加载慢主因是服务端不支持Range请求或preload被浏览器无视，需JS主动load()并监听canplaythrough，同时服务端必须返回Accept-Ranges: bytes。
audio 标签加载慢，90% 不是代码写错了，而是 preload 属性被浏览器无视了，或者服务端不支持 Range 请求导致 seek 卡顿。光改 HTML 属性基本没用，得从 JS 控制 + 服务端配合两头抓。
preload="auto" 为什么根本没发请求？
因为浏览器压根不认这个值——尤其在 iOS Safari、Chrome 省电模式、Firefox 隐私模式下，preload="auto" 直接被降级为 none，network 面板里连请求都看不到。readyState 长期卡在 0（HAVE_NOTHING）就是典型表现。
- 移动端 Safari 对
preload极其保守：无论设成auto还是metadata，它只加载元数据（时长、码率），且不会预取音频帧 - 页面未挂载到
document.body（比如还在DocumentFragment里）、或父容器display: none，preload完全不触发 - 服务端响应头缺失
Accept-Ranges: bytes，部分浏览器会跳过预取，直接等用户点播放才开始拉 - 动态设置
src后，preload值不会重新生效；必须手动调audio.load()
怎么让音频真正在后台静默加载？
靠 HTML 属性不行，得用 JS 主动触发并监听真实就绪状态。关键不是“设了什么”，而是“什么时候调、怎么判断”。
- 确保
audio已插入 DOM（哪怕visibility: hidden或position: absolute） - 先设
preload="none"，再赋值src，然后立刻调audio.load() - 监听
canplaythrough事件（表示缓冲足够播完），比loadeddata更可靠 - 如果已进入
loadedmetadata状态，再次.load()不会重发请求；需先清空src再重设 - 示例：
const audio = document.querySelector('audio');<br>audio.preload = 'none';<br>audio.src = '/sound/alert.mp3?ts=' + Date.now();<br>audio.load();<br>audio.addEventListener('canplaythrough', () => {<br> console.log('已缓冲足够，可随时播放');<br>});
拖进度条（seek）卡顿的根本原因是什么？
不是前端代码问题，而是服务端没配好 HTTP Range 支持。浏览器 seek 时发的是带 Range: bytes=xxx- 的请求，期望返回 206 Partial Content；如果服务端只返回 200 OK，浏览器只能中断重连，造成 1–3 秒卡顿。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
立即学习“前端免费学习笔记（深入）”；
- Nginx 需确认响应头含
Accept-Ranges: bytes；本地开发用 Pythonhttp.server不支持 Range，得换serve或live-server - Flask/FastAPI 要启用
conditional=True（FastAPI 中用Response(headers={"Accept-Ranges": "bytes"})不够，得用FileResponse自动处理） - CDN 或对象存储（如 S3、Cloudflare R2）要检查是否透传
Accept-Ranges头，有些默认过滤掉 - MP3 文件若无 ID3v2 尾部或 VBR 头信息，
duration可能为NaN，即使元数据加载成功也影响 seek 精度
服务端和 CDN 配置哪些项最关键？
客户端再努力，服务端拦着照样白搭。重点不在“加功能”，而在“别拦着”——很多问题其实是响应头被删、Range 被禁、缓存策略冲突造成的。
- 必须返回
Accept-Ranges: bytes，且不能是none或空值 -
Content-Length要准确，否则部分浏览器拒绝预取 - 带 token 的 URL 要注意缓存策略：
Cache-Control: no-cache会让预加载失效；建议用immutable+ 文件名哈希 - 如果音频走 CDN，确认它没把
Range请求转成完整 GET（常见于老旧配置） - 调试方法：
curl -I https://example.com/audio.mp3检查响应头，再curl -H "Range: bytes=0-1023" https://example.com/audio.mp3看是否返回206
真正影响首播延迟的，从来不是你写了哪个 preload 值，而是 DOM 是否挂载、用户是否已有交互、服务端是否支持 Range、网络是否被省电模式限制——漏掉其中任一环，auto 就等于 none。最容易被忽略的是：本地开发服务器默认不支持分段请求，但你可能一直没意识到这点。
