HTML5媒体API是直播互动平台的底层支撑，而非锦上添花：它通过video/audio标签、JavaScript控制接口（play/pause/timeupdate等）、MSE动态拼接fMP4片段、WebSocket实时交互协同，实现低延迟、高兼容、强容错的“获取—传输—显示—互动”闭环。
HTML5 媒体 API 是构建直播互动平台的底层支撑，不是“锦上添花”，而是决定能否播得稳、卡不卡、互动跟不跟得上的关键环节。它不单指 `
核心在于媒体元素与浏览器原生能力的深度协同
直播不是普通视频点播，对实时性、容错性、手势触发和跨端一致性要求极高。HTML5 媒体 API 提供的 `
- 自动播放必须配合
muted属性才能在多数移动端生效；用户首次手势（click/touch）后才可取消静音并调大音量 -
canplaythrough事件比loadeddata更可靠，表示缓冲足够支持连续播放，适合在此时展示“开始观看”按钮或进入互动逻辑 -
timeupdate频率高但不可控，适合做弹幕时间轴对齐、字幕同步；而seeking/seeked则用于处理拖拽跳转后的状态恢复 - 所有
play()调用需包裹.catch()，捕获 “DOMException: play() failed” 类错误——这是现代浏览器对自动播放策略的强制拦截，不是代码 bug
Media Source Extensions（MSE）是低延迟直播的技术支点
HLS（.m3u8）虽兼容好，但固有延迟常达 10–30 秒；真正接近实时（2–5 秒）的直播体验，必须靠 MSE 动态拼接视频片段。它允许 JavaScript 控制底层媒体缓冲区，把从 WebSocket 或 Fetch 流式获取的 fMP4 片段喂给 `
- MSE 不是直接播放 URL，而是创建
MediaSource实例，绑定到video.src，再通过SourceBuffer追加二进制数据 - 需严格按 fMP4 的 moof+mdat 结构解析分片，且时间戳（PTS/DTS）必须连续，否则会触发
onerror或卡顿 - 安卓 Chrome 和桌面端支持成熟；iOS Safari 对 MSE 支持有限，仍需 fallback 到 HLS
- 搭配 HTTP/2 分块传输或 WebSocket 二进制帧推送，能显著降低首屏时间和卡顿率
WebSocket 是互动能力的神经中枢
媒体播放解决“看”，WebSocket 解决“说”。它与媒体 API 协同工作：当视频渲染的同时，消息通道保持全双工连接，支撑弹幕、点赞、投票、礼物动画等高频低延迟交互。
立即学习“前端免费学习笔记（深入）”；
- 弹幕需结合
video.currentTime计算入场位置，用 requestAnimationFrame 控制滚动节奏，避免丢帧 - 点赞数变更、礼物动效触发，应与
timeupdate或自定义事件解耦，避免阻塞渲染主线程 - 网络中断时，WebSocket 的
onclose可触发降级提示；重连后需同步最新状态（如当前在线人数、最新弹幕 ID），而非简单重发历史 - 服务端应按房间/用户维度做消息广播裁剪，避免将无关弹幕推送给非当前观众
兼容性与降级是工程落地的硬门槛
没有“一刀切”的方案。真实场景中，需按设备和浏览器能力动态选择路径：
- iOS Safari：优先 HLS（
application/vnd.apple.mpegurl），禁用 MSE；自动播放必静音；全屏需手动调用webkitEnterFullscreen() - 安卓 WebView：部分定制内核不支持 MSE 或 WebRTC，需检测
window.MediaSource并 fallback 到 HLS + 定时轮询 - PC 端 Chrome/Firefox：MSE + fMP4 是首选；WebRTC 可用于超低延迟（
- 弱网环境：监听
video.networkState和readyState，在NETWORK_NO_SOURCE或HAVE_NOTHING时显示加载态，并尝试切换低码率流
