onplaying事件在媒体已解码并真正输出声音帧时触发，而非用户点击播放或play()调用成功时；它适用于音画同步、播放延迟记录等需物理发声时刻的场景，普通UI状态更新应使用onplay。
onplaying 事件不是“开始播放”的可靠判断点
onplaying 在音频/视频**已解码并真正输出声音帧**时触发，但它不等于“用户点了播放”或“play() 被成功调用”。它比 onplay 更晚，且可能因缓冲不足、设备延迟等被推迟甚至不触发。很多开发者误把它当“播放启动信号”，结果 UI 同步错乱、状态判断失准。
什么时候该监听 onplaying，而不是 onplay
只有在需要响应“媒体内容实际发声”这一物理时刻时才用 onplaying，比如：
- 同步音画（如 Web Audio API 精确对齐）
- 记录真实播放延迟（对比
play()调用时间戳） - 启动依赖真实音频流的处理逻辑（如音频分析、实时变声）
普通播放按钮状态切换、进度条激活、UI 文字更新，请用 onplay —— 它在 play() 被接受后立即触发，更符合用户操作意图。
监听 onplaying 的正确写法和常见坑
必须确保元素已加载就绪，否则 onplaying 可能永远不触发：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 不要直接写
audio.onplaying = () => {...}就调play()；先等canplay或loadeddata事件 - 移动端 iOS Safari 对
onplaying触发更保守，有时需配合audio.readyState === 4手动校验 -
onplaying不会冒泡，也不能用addEventListener('playing', ...)的捕获模式生效 - 如果音频被静音（
muted = true），onplaying仍会触发 —— 它只管“是否在播放”，不管“是否听得见”
稳妥示例：
const audio = document.querySelector('audio');
audio.addEventListener('canplay', () => {
audio.play().catch(() => {});
});
audio.addEventListener('playing', () => {
console.log('音频已开始输出声音帧');
// 此处可启动音频可视化或时间轴同步
});
为什么你看到的 onplaying 示例经常“不工作”
典型失效场景：
- 在
DOMContentLoaded里直接绑定onplaying并立刻play()→ 元素还没加载，play()失败，onplaying永远不会来 - 用
autoplay+onplaying试图绕过用户手势限制 → 现代浏览器（Chrome/Safari）会拦截带声音的自动播放，onplaying根本不触发 - 监听了
onplaying却没处理onpause/onended→ 用户暂停后状态未重置，下次点击行为异常
onplaying 是个精细信号，不是播放控制主干。把它当“确认声波已出设备”的最后校验点，而不是流程起点。
