弹幕提示音必须由用户手势触发，不能依赖弹幕渲染时机；需用节流防抖、复用audio实例、双格式音频及视觉降级确保兼容性。
弹幕本身不支持直接嵌入或触发音频，所谓“弹幕提示音”必须靠 JavaScript 主动控制播放，且不能依赖弹幕 DOM 出现时机来调用 audio.play() —— 因为此时页面大概率无用户交互上下文，会立即被浏览器拦截。
为什么弹幕出现时 audio.play() 总是失败
现代浏览器（Chrome 94+、Safari、Edge）强制要求：首次带声音的音频播放必须发生在用户手势（click、touchstart、keydown）回调内。弹幕通常是通过定时器、WebSocket 消息或 requestAnimationFrame 动态插入的，这些都属于“非用户交互触发”，audio.play() 会返回被拒绝的 Promise，并抛出 DOMException: play() failed because the user didn't interact with the document first。
- 即使你把
<audio></audio>标签写在弹幕容器里，也不改变播放上下文 -
autoplay+muted对弹幕无效——它只影响页面加载时的初始播放，且无法在弹幕动态渲染后“补播” - 移动端（尤其是 iOS Safari）限制更严：首次成功播放必须带
muted=true，之后才能设muted=false并响声
真正能响的两种可靠时机
必须把音频触发锚定在明确的用户动作上，而不是弹幕渲染事件。常见可行路径：
-
用户点击弹幕区域本身：给弹幕
<div class="danmaku"> 绑定 <code>click，在回调中调audio.play().catch(...) -
用户点击全局“开启提示音”开关：比如一个设置按钮，首次点击时播放一次静音音频（
audio.muted = true），解锁音频能力；后续所有弹幕提示音都可正常发声 -
用户主动聚焦弹幕输入框：监听
input或textarea的focus事件，同样可用于激活音频上下文 - 用
audio.readyState === 4和audio.ended判断是否可播，避免重复调play() - 对同一类型弹幕（如“高亮欢迎”）加时间窗口防抖：例如 3 秒内只允许响一次，用
setTimeout+ 时间戳控制 - 优先复用同一个
Audio实例，不要每次 new：const beep = new Audio('/sound/beep.mp3')提前声明，反复beep.currentTime = 0后再play() - 若需多音效（欢迎音、警告音、点赞音），每个音效单独实例 + 单独防抖逻辑，避免互相干扰
- 每次
audio.play().catch(e => { /* 视觉强化 */ })必须有 fallback：比如让弹幕文字变红、加抖动动画、闪烁页面 title - 用
navigator.userAgent粗筛 iOS Safari，对它默认跳过play()，直接走视觉反馈 - 提供「静音」开关，但开关状态要持久化到
localStorage，下次打开仍生效 - 音频文件务必提供 MP3 + OGG 双格式，用
<source></source>回退，否则 Firefox 用户可能全程静音
注意：不要在 danmakuElement.addEventListener('animationend', ...) 里尝试播放——动画结束不是用户手势，照样被拦。
如何让提示音不卡顿、不堆积
弹幕高频刷屏时，如果每条都调 play()，轻则声音重叠混乱，重则触发浏览器资源保护直接静音。必须做节流和状态管理：
兼容性与降级必须写死在代码里
别指望所有用户都能听到声音。iOS Safari 可能完全禁用 Web Audio，部分企业环境禁用所有音频，甚至用户已手动关闭网站通知声音权限。降级不是“可选项”，是必填逻辑：
最常被忽略的一点：音频文件体积要压到 100KB 以内（单声道、22050Hz、64kbps），否则首条弹幕触发时还在加载，play() 就会因 readyState 直接失败——而这个失败往往没 catch，导致你以为“功能坏了”，其实是加载慢。
