preload="auto"加重卡顿因浏览器保守处理、移动端中断重请求；推荐metadata+JS可控load；MSE可编程缓冲，需检查支持性、设sequence模式、用playbackQuality检测卡顿；HLS/DASH分片宜4–6秒并关键帧对齐。
为什么 preload 设为 "auto" 反而加重卡顿
浏览器对 preload="auto" 的实际处理很保守：它可能只预加载前几秒，或在带宽受限时完全跳过，甚至触发多次小段请求，加剧 TCP 连接震荡。移动端尤其明显——用户切到后台后，预加载常被中断，再切回时仍要重请求。
实操建议：
- 多数场景改用
preload="metadata"，只取时长、尺寸、首帧，启动快且不占带宽 - 若确定用户大概率完整观看（如教学视频页），可配合 JS 在页面可见后主动调用
video.load()，比纯 HTML 预加载更可控 - 避免在
标签里写preload="auto"同时又设autoplay，部分 iOS 版本会直接拒绝加载
如何用 mediaSource 实现真正可调的缓冲策略
原生 的缓冲行为不可编程，想精细控制起始缓冲量、暂停后是否丢弃已缓存数据、网络恢复时的追赶逻辑，必须走 MSE（Media Source Extensions）路径。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 初始化前检查支持性：
if ('MediaSource' in window)，Safari 15.4+ 和 Chrome/Edge 新版本才稳定支持 AV1/H.265 的 MSE - 设置
sourceBuffer.mode = 'sequence'可让浏览器按 append 顺序播放，避免因时间戳跳变导致的卡顿重同步 - 监听
sourcebuffer.updating和video.waiting事件，在卡顿时主动abort()当前 buffer 并追加新分片，比等自然恢复快 200–500ms
video.buffered 不是实时缓冲区快照，别拿它做“是否卡住”的唯一判断
video.buffered 返回的是已成功解码并入队的区间集合，不是网络层已下载但未解码的原始数据。当视频启用了硬件解码或存在 B 帧依赖时，buffered 可能长时间不变，但播放依然流畅；反之，若解码器卡在某帧，buffered 看似连续，画面却已停滞。
更可靠的卡顿检测组合：
- 用
video.getVideoPlaybackQuality()查droppedVideoFrames和corruptedVideoFrames，Chrome/Firefox 支持，数值突增即表明解码或渲染瓶颈 - 结合
performance.now()记录timeupdate事件间隔，连续两次间隔 > 200ms 就标记疑似卡顿 - 服务端埋点补充：通过
video.networkState === NETWORK_LOADING+ 请求耗时，区分是网络抖动还是 CDN 节点异常
HLS/DASH 的分片大小和码率切换点怎么影响首屏与抗抖动能力
不是分片越小越好。1s 分片虽降低首屏延迟，但 HTTP 请求密度翻倍，弱网下 TLS 握手和队头阻塞开销反而拖慢整体吞吐；而 10s 分片在 2Mbps 波动网络中，一次丢包可能导致整片重传，卡顿感知更强。
生产环境推荐配置：
- HLS：主码率流用 4–6s 分片，辅以 2s 的低码率备用流（
EXT-X-STREAM-INF中声明），供快速降级 - DASH：
SegmentTemplate@duration设为 4000（ms），配合minBufferTime="1.5"，既保缓冲余量，又避免初始加载过久 - 所有分片必须启用
keyframe alignment（关键帧对齐），否则码率切换时易出现花屏或跳帧，看起来像卡顿
真正难的是动态码率策略——CDN 返回的 Content-Length 和真实下载速度之间存在不可忽略的延迟，单纯看 video.buffered.end(0) 做升降级，容易频繁抖动。得结合客户端测速 + 服务端下发的 QoE 模型参数，才能稳住体验。
