preload属性对按钮触发的音视频无效，因其仅在元素首次解析时生效；动态创建音视频元素时需用<link rel="preload">提前声明资源，并注意as、type、CORS及缓存配置。
preload 属性对按钮触发的音视频根本不起作用
HTML 的 preload 属性只在元素**首次解析并加入 DOM 时生效**，它影响的是浏览器是否提前请求、解码或缓冲资源。但如果你是点击按钮后才动态创建 <audio> 或 <video> 元素（比如 document.createElement('audio')），那 preload 在此时设置为 "auto" 也**无法让浏览器提前加载**——因为资源 URL 还没确定，浏览器连请求都发不出。
真正有效的预加载方式：用 link rel="preload"
想让按钮一按就“秒播”，必须在页面加载早期（甚至 DOMContentLoaded 前）就让浏览器发起音视频资源请求。唯一可靠的方式是用 <link rel="preload"> 提前声明：
<link rel="preload" href="/sounds/click.mp3" as="audio" type="audio/mpeg"> <link rel="preload" href="/videos/intro.mp4" as="video" type="video/mp4">
注意要点：
-
as必须准确填写"audio"或"video"，否则浏览器不会按媒体类型优化优先级和解码策略 -
type强烈建议带上，避免 MIME 类型不匹配导致预加载被忽略 - 不要等 JS 执行完再插入
<link>，最好直接写在<head>里，或至少在DOMContentLoaded前完成注入 - 多个文件就写多条
<link>，不要试图用一个preload覆盖全部
按钮点击时如何复用已预加载的资源
预加载只是“把文件下到内存缓存”，不代表能直接播放。你需要确保播放逻辑复用同一 URL，并避免重复创建实例：
立即学习“前端免费学习笔记（深入）”；
- 用
new Audio('/sounds/click.mp3')创建实例时，浏览器会从 HTTP 缓存或内存缓存中快速读取，无需网络等待 - 如果反复创建新
Audio实例，每次调用.play()前仍需触发解码——可考虑复用单个实例并调用.currentTime = 0重置 - 对于
<video>，若需首帧秒出，建议加preload="metadata"（仅预加载元数据）+poster占位，再配合<link preload>下载主体文件 - 不要在
onclick里写fetch(...).then(res => res.arrayBuffer())再喂给AudioContext.decodeAudioData()——这绕过了所有浏览器原生缓存和优化路径
容易被忽略的兼容性与陷阱
看似简单，实际几个细节会直接让预加载失效：
- HTTP 缓存头不匹配：如果服务器返回
Cache-Control: no-cache或max-age=0，<link preload>下载的内容可能不进内存缓存，下次Audio初始化仍走网络 - CORS 限制：跨域音视频必须在
<link>上加crossorigin属性，否则预加载会被静默丢弃 - 移动端 Safari 对
preload="auto"和自动播放限制极严，即使预加载完成，.play()仍可能被拒绝——务必监听play()的 Promise 拒绝，降级为用户手势触发的play() - MP3/MP4 文件若未正确编码（如未将关键帧放在开头），即使预加载完成，seek 到 0 仍可能卡顿——可用
ffprobe -v quiet -show_entries format=start_time /file.mp3检查起始时间是否为 0
预加载不是加个属性就完事，它是“请求时机 + 缓存控制 + 播放路径”三者咬合的结果。漏掉任意一环，按钮点下去还是卡顿。
