preload="auto"是低端机上loop能触发的前提，因低端机内存和解码能力弱，仅此策略可保障元数据与首帧音频稳定加载，确保ended或timeupdate事件可预测；副作用是首次加载体积略大，但对1–5秒ui音效影响极小。
preload="auto" 是低端机上 loop 能触发的前提
低端机内存和解码能力弱，preload="none" 或 preload="metadata" 会导致 timeupdate 事件稀疏甚至中断，循环跳转时机错乱。实测中只有 preload="auto" 能保障元数据+首帧音频稳定加载，让 ended 或 timeupdate 有可预测的触发基础。副作用是首次加载体积略大，但对 1–5 秒背景音效（如 UI 提示音）影响极小，远优于循环失败带来的体验断层。
MP3 在低端 Android 机上 loop 卡顿，优先换 .ogg
低端机普遍使用老旧 WebKit 内核或定制 WebView，MP3 解码器对循环点识别不准，实测间隙常达 200–500ms，听起来像“卡了一下”。.ogg（Vorbis 编码）在同等硬件下间隙通常 ffmpeg -i in.mp3 -c:a libvorbis -q:a 4 -vn out.ogg，并确认原始音频首尾波形对齐。
监听 ended 时必须检查 readyState，否则静默失败
低端机缓冲慢、readyState 容易卡在 HAVE_CURRENT_DATA 或更低，直接 audio.currentTime = 0 可能无效且无报错。必须加判断：
audio.addEventListener('ended', () => {
if (audio.readyState >= audio.HAVE_FUTURE_DATA) {
audio.currentTime = 0;
audio.play().catch(e => console.warn('loop play failed:', e));
}
});
若连续两次 ended 触发时 readyState 都不足，应降级为原生 loop 或提示用户网络不佳。
避免在低端机上用 Web Audio API 做无缝循环
Web Audio API 虽然精度高，但在低端机上首次 decodeAudioData() 可能阻塞主线程 >300ms，且 AudioContext resume 需用户手势，与原生 audio 标签行为不一致。对背景音效这类低复杂度需求，JS + ended + .ogg 组合已足够，强行上 Web Audio 反而增加崩溃风险和内存压力。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
