卡顿主因是缓冲跟不上播放进度，需优化预加载策略、确保服务端支持Range请求、提升缓冲水位、适配终端解码能力。
卡顿主要来自缓冲跟不上播放进度，不是单纯“网速慢”，而是浏览器没拿到足够数据、或拿得不及时。核心思路是让缓冲更早启动、更稳推进、更准预判。
预加载策略要分场景配对
preload 不是越激进越好，得看用途：
- 首屏自动播放视频（如广告页）：用 preload="metadata" + muted autoplay，只取头信息，快且省流量；iOS Safari 也认这个组合
- 用户明确点击才播的视频（如详情页）：hover 时用 JS 调
load()，避免白屏等待；preload 可设为 "none"，完全按需触发 - 内网或 Wi-Fi 环境下的关键引导视频：可试 preload="auto"，但别依赖它在移动端生效——Safari 会无视，Chrome 移动端也常降级为 metadata
服务端必须支持字节范围请求（Range）
没有 Range，拖拽、后台缓冲、断点续传全失效，浏览器只能反复重下整个文件。
- 用 DevTools Network 面板检查视频请求响应头：必须含 Accept-Ranges: bytes，且拖拽时返回状态码 206 Partial Content
- Nginx 示例配置：
add_header Accept-Ranges bytes;，确认 range 模块未被禁用（默认开启） - 对象存储（如 OSS、S3）要确认原生开启“分段下载”；私有 COS 若关了该功能，需手动打开
- 切记：不要对 MP4 做 gzip 压缩——破坏二进制对齐，直接导致 416 错误
缓冲水位要设得够厚、够早
纯 <video></video> 标签靠浏览器自动管理缓冲，但默认太保守；用 hls.js 或 MSE 自研方案时，缓冲策略完全可控。
- 监听 loadeddata 替代 canplaythrough 显示播放按钮，快 1–3 秒——首帧解码完成就可操作，不用等“估算能播完”
- 用
video.buffered.end(0) - video.currentTime > 5在timeupdate中轻量判断是否缓冲充足，比 canplaythrough 更实时 - hls.js 场景下，把 maxBufferLength 提到 60 秒，bufferLength 触发加载的阈值调高（比如 15 秒），减少弱网下频繁小片段请求
- HLS 直播加 liveSyncDurationCount: 3，让缓冲区更“扛抖动”
视频资源本身得适配终端能力
再好的缓冲策略也救不了硬解失败的视频——卡顿常始于解码器罢工。
- 编码用 H.264 Main Profile，Level ≤ 3.1，iOS 和多数 Android 解码器都稳
- 关键帧间隔（GOP）控制在 1–2 秒（30fps 下即 30–60 帧），避免黑屏等 IDR 帧
- MP4 容器中 moov box 必须前置：用 ffmpeg 加
-movflags +faststart修复 - 提供多档分辨率（如 480p/720p），JS 根据
screen.width和navigator.connection.effectiveType动态换 src，不强塞 4K 给低端机
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
