html音频事件无法跨端统一，应组合监听timeupdate、兜底状态判断、锚定用户手势；ended不可靠需配合currenttime检测；play()必须catch错误且仅在用户交互后调用。
HTML 音频播放事件做不到“各端统一触发”，因为浏览器对事件的触发时机、顺序、甚至是否触发，本身就不一致。真正的兼容做法是：不依赖单一事件，而是组合监听 + 状态兜底 + 用户手势锚定。
ended 事件在 iOS Safari 和 Android WebView 中行为差异大
你写 audio.addEventListener('ended', () => { audio.currentTime = 0; audio.play(); })，在 Chrome 桌面可能无缝循环，但在 iOS Safari 上大概率失败——它常在音频真正结束前就触发 ended，或根本没触发；Android 低版本 WebView 则可能压根不抛该事件。
- 不要把逻辑全押在
ended上，必须搭配timeupdate做兜底判断：当audio.currentTime >= audio.duration - 0.1时主动重播 - iOS Safari 中，
duration可能为NaN或Inf，需先等loadedmetadata事件后再读取 - Android WebView（尤其 4.4–6.0）中
ended触发不可靠，建议用setTimeout在预计结束时间后 100ms 补一次play()
play() 返回的 Promise 拒绝必须显式捕获
所有现代浏览器（含微信 iOS WebView）调用 play() 后都返回 Promise，但拒绝原因五花八门：NotAllowedError（无手势）、AbortError（资源中断）、NotSupportedError（格式不支持）。不 .catch() 就等于放弃调试入口。
- 每次调用
audio.play()必须接.catch(e => console.warn('play rejected:', e.name)) - 常见错误名有：
"NotAllowedError"（用户未交互）、"NotSupportedError"（canPlayType返回空字符串）、"AbortError"（网络中断或解码失败） - 不要在
DOMContentLoaded或load事件里调play()，100% 被拒；唯一安全时机是用户真实点击/触摸后的回调内
timeupdate 触发频率和精度跨平台不一致
timeupdate 在桌面 Chrome 中约每 200–250ms 触发一次，在 iOS Safari 中可能稀疏到 500ms 以上，且首次触发延迟更长。直接靠它做帧级同步（如歌词高亮）必然错位。
- 别在
timeupdate回调里频繁操作 DOM（如更新进度条文本），应节流或用requestAnimationFrame批量处理 - 需要亚秒级精度时，改用
audioContext.currentTime（Web Audio API），但注意 iOS 要求audioContext.resume()必须在用户手势回调中执行 - 判断“是否正在播放”的安全写法是：
!audio.paused && !audio.ended，而不是只看audio.paused === false
canplaythrough 不能当作“可播”信号来用
这个事件本意是“足够数据支撑全程播放不卡顿”，但现实中它在 Safari（尤其 iOS）上触发极不稳定，有时永不触发；Chrome 中又可能在缓冲未满时就误报。把它当播放起点，等于把控制权交给浏览器的随机性。
- 真正可靠的“可播”标志是
loadedmetadata：此时duration、readyState、buffered都已可用 - 如果要等缓冲充足再播，用
progress事件配合audio.buffered.end(0) >= audio.duration * 0.8判断更可控 - 移动端（尤其 4G 网络）慎用
preload="auto"，它会让canplaythrough更难触发，且增加首屏耗时
最易被忽略的点是：事件监听必须在音频资源加载完成前就绑定。如果你等 loadedmetadata 后才加 ended 监听，iOS 上可能错过第一次结束；而如果在 new Audio() 实例化后立刻监听，又可能因资源未加载导致事件丢失。稳妥做法是——元素声明即监听，不等任何前置条件。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
