JavaScript操作音视频元素的关键在于状态与交互：play()需用户手势触发，静音可绕过限制；监听loadedmetadata而非canplaythrough；iOS忽略volume设置；MediaSource需URL.createObjectURL且readyState为open。
JavaScript 操作 和 元素本身不难，但真正卡住人的往往不是“怎么播”，而是“为什么没反应”“为什么报错”“为什么在手机上失效”。核心问题不在语法，而在媒体加载状态、用户手势限制和跨浏览器行为差异。
media 元素的 play() 方法为何经常静默失败
现代浏览器（Chrome、Safari、Firefox）强制要求：自动播放带声音的媒体必须由用户手势（如 click、touchstart）触发。直接在 DOMContentLoaded 或 load 里调用 play() 会抛出 DOMException: play() failed because the user didn't interact with the document first。
- 解决方案：只在显式用户操作回调中调用
play()，例如按钮点击、空格键按下 - 静音视频可绕过部分限制：设置
video.muted = true后，即使无手势也能调用play()（但仅限 muted + autoplay 属性组合） - 不要依赖
video.readyState === 4就立刻play()；需同时检查video.networkState === 0（NETWORK_EMPTY）是否已结束，否则可能因网络未就绪而失败
如何可靠监听媒体加载完成与可播放状态
canplay 和 canplaythrough 容易被误用。前者表示“至少一帧能解码”，后者才意味着“按当前带宽可连续播放到底”，但后者在移动设备上常因预估不准而永不触发。
- 优先监听
loadedmetadata：元数据（时长、尺寸、轨道）已加载，此时duration、videoWidth等属性才可信 - 用
waiting+playing组合判断缓冲是否卡住，比单纯等canplaythrough更实用 - 移动端 Safari 对
preload="auto"实际忽略，建议设为"metadata"，避免无意义请求
控制音量、静音与播放速率的兼容性要点
volume（0–1）、muted（布尔）、playbackRate（如 0.5、2）看似简单，但存在关键限制：
立即学习“Java免费学习笔记（深入）”；
-
volume在 iOS Safari 中始终被忽略（系统音量控制权在硬件侧），设置无效也不报错 -
playbackRate在部分 Android WebView 中不支持变速，且 Chrome 对的变速可能引发音频失真 - 修改
muted后需手动调用play()或pause()才会生效（尤其在 Safari 中） - 不要在
timeupdate里频繁读写currentTime，会导致卡顿；改用requestAnimationFrame节流
使用 MediaSource 动态追加音视频数据的硬门槛
MediaSource 是实现 MSE（Media Source Extensions）的基础，用于直播、自适应流或 WebAssembly 解码后喂数据，但它有严格前提：
- 元素必须已设置
src为URL.createObjectURL(mediaSource)，且不能是普通 URL -
mediaSource.readyState必须为"open"才能创建SourceBuffer；否则会报InvalidStateError - H.264/AAC 是最广泛兼容的编码组合；VP9/AV1 在 Safari 中完全不支持，
sourceBuffer.appendBuffer()前必须确保mime类型与isTypeSupported()返回一致 - 追加数据前需先
sourceBuffer.timestampOffset = currentTime对齐时间轴，否则播放会跳秒或卡死
最常被忽略的是：所有媒体操作都依赖于实际加载状态而非 DOM 是否存在。一个没设 src 的 元素，调多少次 play() 都只是静默失败——先确认 networkState !== 0，再查 readyState，最后动操作。
