音频重复播放问题源于状态失控，需用单例Audio+布尔锁防重；iOS需静音文件首播激活上下文；循环播放须单次绑定ended监听并校验readyState。

audio 元素重复播放的典型现象

点一次按钮，音频却播两遍；快速连点后控制台报 DOMException: play() failed because the user didn't interact with the document first；或播放中途卡住、声音重叠、ended 事件触发多次。这不是代码写错了，而是没管状态——浏览器不会自动帮你排队、去重、防抖。

用单个 Audio 实例 + 状态锁防重复

别建多个 new Audio()，也别每次点击都 new 一个。复用同一个实例，配合布尔锁控制流程：

• isPlayingOrLoading 初始设为 false，点击按钮时先判断：为 true 就直接 return
• 设为 true 后再调 audio.pause() → 更新 src → 调 audio.play()
• play() 成功后监听 loadeddata 或 canplay 再重置锁；失败则在 error 回调里重置
• 同时监听 ended 事件，但内部也要检查 isPlayingOrLoading，避免手动切换和自动循环打架

iOS Safari 下重复失败的根本原因

不是 JS 写得不够勤快，是 iOS 播放上下文没激活。首次 play() 被拒后，后续所有调用（包括你加了锁的）都会继续失败，直到上下文建立。

Html2md

使用 Readability + Turndown 将 HTML 页面转换为干净的、Agent 友好的 Markdown。去除导航栏、广告、页脚、Cookie 横幅、社交按钮等干扰元素。支持 URL...

下载

• 必须在页面初始化时用一个 0.1s 静音.mp3 主动触发一次 play().then(() => audio.pause())
• 不能靠 muted=true 绕过——iOS 下 muted 无效
• 不能等用户点按钮才第一次调 play()，否则第一个真实音频大概率被拦
• 这个静音文件要放在数组第一个位置，或单独提前加载，确保它比业务音频更早 ready

JS 控制循环时怎么避免“越播越快”

很多人用 ended 事件做循环，但反复绑定、不清理旧监听器，会导致 currentTime = 0 执行多次，音频跳来跳去。

立即学习“前端免费学习笔记（深入）”；

• 只绑定一次 ended 监听器，用闭包或模块变量管理是否启用循环逻辑
• 设置 currentTime 前务必检查 audio.readyState >= audio.HAVE_FUTURE_DATA，否则可能静默失败
• 不要在 ended 里直接调 play()，而是调 audio.play().catch(...) 并处理拒绝——移动端常因策略中断
• 如果只是想“播完回到开头”，loop 属性够用；但只要涉及用户手动切换、暂停恢复、跨音频状态同步，就必须用 JS 控制，且要亲手管好每个状态跃迁

真正容易被忽略的是：状态锁和播放上下文激活必须在所有音频操作之前就位，而不是等出问题再补。 一旦某个 play() 被策略拦截，整个音频实例就进入半失效状态，后续所有逻辑都会变得不可预测。