preload="auto"未触发请求是因浏览器主动降级：页面无焦点、省电模式、元素未挂载DOM、src动态设置或服务端缺少Accept-Ranges头；iOS Safari恒将auto降级为metadata，仅取元信息。
preload="auto" 为什么没触发请求？
写了 preload="auto" 却没看到网络请求，不是代码写错，而是浏览器主动降级或抑制了预加载。常见原因包括：
• 页面刚加载、audio 元素还没获得用户焦点（Chrome/Edge 默认延迟加载）
• 设备开启省电模式或 iOS 的 Low Data Mode（Safari/Chrome 自动切为 metadata）
• audio 元素尚未插入 DOM，或 src 是 JS 后续动态设置的（preload 不触发初始加载）
• 服务端响应头缺失 Content-Length 或返回 Accept-Ranges: none（部分浏览器放弃分段请求）
metadata 和 auto 在移动端实际表现一样？
是的，iOS Safari 基本无视 preload="auto"，一律按 metadata 处理——只拉取前几 KB 获取时长、采样率等元信息，不下载音频帧数据。这意味着：
• 进度条能正常显示（有 duration）
• 首次点击播放仍有明显延迟（需重新拉流）
• 流量消耗低，适合弱网或移动场景
• 如果你依赖「秒开」音效（比如游戏反馈），metadata 不够用，必须主动调用 load()
怎么让背景音效真正预载完成？
单靠 preload 属性不够，强依赖场景必须配合 JS 主动控制：
• 确保 audio 元素已挂载到 DOM（display: none 可以，但不能在 DocumentFragment 里）
• 手动设 preload="none" → 赋值 src → 调用 load() → 监听 canplaythrough 事件
• 注意：loadedmetadata 只表示元信息就绪；canplaythrough 才代表足够数据可连续播放
• 若已进入 loadedmetadata 状态，再次调用 load() 无效
autoplay + muted 能绕过自动播放限制吗？
可以，但仅限「静音自动播放」这一条路径：
• autoplay + muted 在多数桌面和 Android 浏览器中能成功触发播放
• iOS Safari 要求用户首次交互后才能取消静音，所以静音播放是唯一可靠起点
• 但背景音效往往需要声音，因此更稳妥的做法是：先静音 autoplay，再用按钮触发 audio.muted = false; audio.play()
• 务必用 .catch() 捕获拒绝错误，例如 DOMException: play() failed because the user didn't interact with the document first
立即学习“前端免费学习笔记（深入）”；
真正影响预载效果的，不是属性写法是否“正确”，而是 DOM 状态、用户交互时机、服务端响应头这三者的组合。尤其在移动端，preload 更像一个建议，而不是开关。
