new Audio()比audio标签更适合按钮音效，因其不依赖DOM、规避autoplay拦截、支持touchstart可靠触发、WAV格式零延迟播放，且单例复用可避免卡顿。
audio标签在按钮音效里为什么不如new Audio()好用
直接用<audio>标签配controls或autoplay，本质是把它当播放器用，不是“点击即播”的工具。浏览器对autoplay拦截极严，哪怕加了muted，首次play()若不在用户手势同步调用栈里，依然会报NotAllowedError。更麻烦的是：<audio id="sfx">必须等DOM加载完、元素存在，才能document.getElementById('sfx').play()，而iOS Safari对标签内play()的触发时机更敏感，容易失败。
相比之下，new Audio('click.wav')不占HTML结构、JS层完全掌控生命周期、无需load()显式调用（WAV/Opus格式基本秒解码），复用也更干净。
click事件里调play()还是touchstart事件里调
移动端必须优先用touchstart。iOS Safari对click有300ms延迟，且某些WebView中click不被认可为“用户激活”手势，导致首次play()静默失败。而touchstart是更底层、更早触发的有效手势，能可靠解锁音频上下文。
- PC端可只绑
click，但统一写touchstart+click更稳妥 - 别用
touchend——它不被所有浏览器视为有效解锁手势 - 元素需有交互语义：加
role="button"或cursor: pointer，否则部分Android WebView可能忽略手势
音效文件选MP3、WAV还是Opus
WAV最稳，Opus次优，MP3慎用。WAV无压缩、免解码延迟，首次play()几乎零等待；Opus体积小、启动快，适合网络受限场景；MP3首播常卡顿，尤其在低端设备或弱网下，Safari还可能因ID3v2标签加载失败。
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
立即学习“前端免费学习笔记（深入）”；
- 若必须用MP3，用
ffmpeg -i in.mp3 -c copy -map_metadata -1 out.mp3清理元数据 - 文件路径404或跨域没配CORS时，
audio.networkState === 0，play()立刻reject - 别信
preload="auto"对new Audio()有效——它只对<audio>标签起作用
多个按钮共用音效实例时怎么避免卡顿和无声
反复new Audio()会快速堆积解码器实例，内存涨、卡顿明显。复用单例是底线，但仅设currentTime = 0还不够——解码未完成或前次播放未结束时，play()可能失败或延迟半拍。
- 提前创建：在
DOMContentLoaded里const clickSound = new Audio('click.wav'); - 每次点击前检查状态：
if (clickSound.readyState >= 2) { clickSound.currentTime = 0; clickSound.play().catch(() => {}); } - 高频点击可加30–50ms微延迟：
setTimeout(() => clickSound.play(), 30)，比纯同步更稳 - 不用监听
ended重置，currentTime = 0已足够；监听反而增加开销
真正难搞的是快速连点下的音频引擎缓冲节奏问题，这不是代码能彻底绕过的——Web Audio API + AudioBufferSourceNode才是终极解法，但对简单按钮音效来说，WAV + touchstart + 单例复用，已经覆盖95%场景。
