JavaScript音视频控制核心是HTMLMediaElement，须等loadedmetadata或canplay事件后操作；play()需处理Promise拒绝及muted绕过限制；优先用事件监听状态变化而非轮询；注意移动端playsinline、帧同步及内存泄漏问题。
JavaScript 操作音视频不是靠“教程式 API 列表”，而是围绕 HTMLMediaElement（即 <audio> 和 <video> 元素）展开的——所有核心能力都来自它，而非独立的 JS 类库。
如何正确获取并控制 <audio> 或 <video> 元素
必须等元素加载完成、且媒体元数据就绪后才能安全调用播放、暂停等方法。直接在 DOM 加载完就 play() 很可能失败（尤其移动端）。
-
canplay或loadedmetadata事件才是调用play()的合理时机，DOMContentLoaded不够 - 使用
document.querySelector('video')获取元素后，立刻检查video.readyState：0 表示无信息，1 表示已有元数据，2+ 才能可靠操作 - 若用
src动态赋值，需手动触发load()方法重新加载，否则事件不会重发
play() 失败的常见原因和绕过方式
现代浏览器普遍禁止自动播放含声音的媒体，play() 返回 Promise，reject 时会抛出 NotAllowedError。
- 用户未与页面交互（如点击、触摸）前，不能播放带音频的
<video>；但设muted属性后可绕过限制 -
<audio>即使muted，部分 iOS 版本仍禁播，需结合autoplay+muted+ 用户手势触发 - 不要忽略
play()的返回值：video.play().catch(e => console.warn('Autoplay prevented:', e))
监听状态变化比轮询更可靠
用事件代替定时器查 currentTime 或 paused——不仅省资源，还能捕获意外中断（如系统切后台、网络断开）。
立即学习“Java免费学习笔记（深入）”；
-
timeupdate：每 200–250ms 触发一次，适合更新进度条，但别在里面做重操作 -
pause/playing：比读paused属性更及时，尤其处理多端同步时 -
ended：播放自然结束时触发；注意循环播放要手动currentTime = 0再play()，否则不生效 -
error：必须监听，video.error是MediaError对象，code值为 1–4，对应不同错误类型
音视频同步与性能关键点
同一页面多个媒体元素同时播放容易卡顿，尤其是 Web Audio API 与 <video> 混用时。
- 避免频繁设置
currentTime（尤其小步长跳转），会引起解码重置，iOS 上尤为明显 - 用
video.requestVideoFrameCallback()替代requestAnimationFrame()做帧级同步，精度更高且省电 - Web Audio 中连接
MediaElementAudioSourceNode后，该节点生命周期绑定到元素，移除元素前务必disconnect()，否则内存泄漏 - 移动端请始终设
playsinline，否则 iOS 会强制全屏播放
真正难的不是调用哪个方法，而是判断「此刻能否调、该不该调、调了之后谁来兜底」——状态机意识比 API 熟练度更重要。
