audio标签不处理超大音频加载，卡顿主因是浏览器预加载、内存占用与首帧延迟；preload="none"常被忽略，需配合Range支持、格式转码（如MP3/Opus）、分段懒加载或MSE流式方案。
audio 标签本身不处理“超大体积音频”的加载策略，它只是容器；真正卡住的环节是浏览器预加载、内存占用和首帧延迟——直接写 src 会导致页面白屏、卡顿甚至崩溃。
为什么加了 preload="none" 还是卡
因为很多浏览器（尤其是 Chrome）会忽略 preload="none"，在解析到 audio 标签时仍尝试获取文件头信息（哪怕只 fetch 前几 KB）。超大文件（如 >100MB 的无损 FLAC 或长播客 WAV）会让 Network 队列阻塞、触发内存警告，甚至让整个标签进入 networkState === 0（空闲但不可用）状态。
- 必须显式设置
preload="none"，且不能依赖它“完全阻止请求”——这只是建议，不是指令 - 如果音频路径是相对路径（如
"./audio/long-podcast.flac"），而服务器没配好Content-Range支持，浏览器可能试图下载整个文件才能解码第一帧 - WAV/FLAC 等无压缩格式体积大、解码慢，
canplay事件可能等几十秒才触发，用户早关页面了
用 MediaSource Extensions (MSE) 实现流式加载
这是唯一能真正应对超大音频（GB 级）的方案：把音频切片，按需拉取、动态拼接。但注意，audio 标签原生不支持 MSE，你得用 AudioContext + MediaSource 手动接管解码流程。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 仅适用于 MP3、MP4（AAC）、WebM（Opus）等浏览器可增量解码的格式；WAV/FLAC 不行
- 必须后端支持 HTTP Range 请求（Nginx 默认开，Apache 需
mod_headers+Header set Accept-Ranges bytes） - 前端关键代码骨架：
const mediaSource = new MediaSource(); audio.src = URL.createObjectURL(mediaSource); mediaSource.addEventListener('sourceopen', () => { const sourceBuffer = mediaSource.addSourceBuffer('audio/mp4; codecs="mp4a.40.2"'); fetchChunk(0).then(buf => sourceBuffer.appendBuffer(buf)); });
更现实的替代方案：转封装 + 分段 + 懒加载
对绝大多数项目，“超大”其实指 50–500MB 的单文件音频。与其硬刚 MSE，不如降维处理：
立即学习“前端免费学习笔记（深入）”；
- 用
ffmpeg把原始文件转成 CBR MP3 或 Opus（体积压到 1/3～1/5），命令示例：ffmpeg -i long.wav -c:a libmp3lame -b:a 96k -ar 44100 output.mp3 - 用
ffmpeg -i input.mp3 -f segment -segment_time 300 -c copy part_%03d.mp3切成 5 分钟一段，生成part_001.mp3、part_002.mp3… - HTML 中不一次性加载全部，只放第一个分段的
src，后续用 JS 监听ended事件，动态切换audio.src到下一段 - 为防跨域或 MIME 问题，确保服务器返回
audio/mpeg（MP3）或audio/ogg（Opus），别用audio/mp3这种错误值
真正容易被忽略的是服务端配置：超大文件必须开启 Accept-Ranges，否则 MSE 和分段加载都会退化成全量下载；另外，不要指望用户耐心等 20 秒以上的 loadedmetadata，该给 loading 提示就给，该加进度条就加——audio 标签不会自动告诉你“正在缓冲第 37%”。
