video 标签默认不预加载，preload 设为 "auto" 才可能提前拉流
浏览器对 <video></video> 的预加载行为是保守的，尤其在移动网络或低配设备上，默认往往等同于 preload="metadata" —— 只拿封面和时长，不下载视频主体。卡顿常从第一帧就开始，根源就在这儿。
实操建议：
-
preload值选"auto"（不是"true"或"yes"，这些无效）；但注意：iOS Safari 无视该属性，只在 Wi-Fi 下才可能预加载，这点必须接受 - 如果内容敏感或流量成本高，可降级为
preload="metadata"+ 用户 hover 时用 JS 主动调用load()，避免白屏等待 -
preload="none"在首屏视频里基本等于自废武功，除非是折叠区域里的备用资源
HTTP 范围请求（Range）没开，seek 和缓冲会反复重连
视频拖拽（seek）、后台缓冲、断点续传全依赖服务端支持 Range 请求。如果 Nginx/Apache 没配，或 CDN 缓存了整个文件而非分片响应，浏览器只能重新 fetch 全量，卡顿+耗流量。
验证方法：用浏览器 DevTools 的 Network 面板看视频请求的响应头，必须含 Accept-Ranges: bytes；请求头里应有 Range: bytes=0- 或类似片段。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- Nginx 加配置：
add_header Accept-Ranges bytes;，并确保没禁用range模块（默认开启） - 静态文件部署到对象存储（如 S3、OSS）时，确认其原生支持
Range；部分私有 COS 若关了“分段下载”，需手动打开 - 不要用
Content-Encoding: gzip压缩 MP4 文件——二进制视频不适用 gzip，反而破坏Range对齐，导致 416 错误
canplaythrough 事件太晚，用户已看到卡顿才触发
靠监听 canplaythrough 再显示播放按钮或取消 loading 状态，往往来不及。这个事件表示“按当前带宽估算能播完”，但估算不准，且触发时机晚于实际可播点（比如 canplay 或 loadeddata）。
实操建议：
- 首次加载优先监听
loadeddata（首帧解码完成）来隐藏 loader，比等canplaythrough快 1–3 秒 - 若需判断是否真够流畅，可用
video.buffered.end(0) - video.currentTime > 5（缓冲区领先当前时间 5 秒以上），在timeupdate里轻量轮询 - 别在
canplaythrough里做 heavy work（如渲染字幕轨道），它可能被多次触发，或在低内存设备上根本不会触发
HLS 或 MSE 方案下，bufferLength 和 maxBufferLength 配得太小
用 hls.js 或自研 MSE 播放器时，缓冲策略由 JS 控制。默认 maxBufferLength: 30（秒）看似够，但在弱网下，如果 bufferLength（当前缓冲秒数）低于 10 就开始加载，容易频繁触发小片段请求，加剧卡顿。
实操建议：
- 把
maxBufferLength提到60，同时设liveSyncDurationCount: 3（HLS 直播用），让缓冲更“厚”一点扛抖动 - 避免
enableWorker: false（尤其在安卓 WebView 中），JS 解析 TS 片段会阻塞主线程，视觉上就是卡 - MP4 分片（fMP4）比传统 TS 更省 CPU，但要求服务端输出
moov在前（用ffmpeg -movflags +faststart重写）；否则首帧延迟严重
缓冲慢的本质不是“网络差”，而是“浏览器不知道要什么、服务端给不了、播放器不敢多存”。三个环节里任意一个掉链子，用户就会卡在 loading 圈里。最容易被忽略的是服务端 Range 支持和 MP4 的 faststart 优化——这两项改完，很多“玄学卡顿”直接消失。
