HTML5原生video标签不支持自动画质调整，需开发者结合网络状况（如navigator.connection.downlink）、设备能力（DPR、屏幕尺寸、解码支持）及HLS/DASH协议实现动态切换，MP4多源方案须手动保存播放状态并精准恢复。
HTML5 原生 <video> 标签本身不支持自动画质调整，所谓“自适应”必须由开发者主动实现。核心逻辑不是靠浏览器判断，而是结合设备能力、网络状况与视频源策略做动态决策。
带宽是首要判断依据
仅看分辨率或 DPR 容易误判——高分屏设备若处于地铁弱网环境，加载 4K 视频反而卡顿。真正有效的起点是 navigator.connection.effectiveType（如 '4g'、'slow-2g'）和 downlink（单位 Mbps），它们能反映真实可用带宽：
-
downlink < 1→ 切换至 360p 或更低档位，优先保障可播 -
downlink ≥ 5→ 可启用 1080p@2x 或 4K 源（需确认设备解码能力） - 监听
connection.onchange事件，在网络切换时重新评估
设备能力需协同验证
DPR 和屏幕尺寸不能单独作为画质依据，但可辅助过滤无效选项：
-
window.devicePixelRatio ≥ 2且screen.width ≥ 1200→ 表明具备高分屏基础，才考虑加载 @2x 视频 - 避免在低端 Android 设备（如 Mali-400 GPU）上强行推送 4K，即使 DPR=2 也易解码失败
- 用
video.canPlayType('video/mp4; codecs="avc1.640033"')验证是否支持 High Profile 编码
播放器层要支持无缝切换
单纯替换 src 会导致黑屏、进度丢失。真正可用的自动调整需满足：
立即学习“前端免费学习笔记（深入）”；
- 使用 HLS 或 DASH 协议：浏览器原生支持 HLS（Safari），Chrome/Firefox 需 hls.js/dash.js；它们能按秒级切片动态选流，无感知过渡
- 若用 MP4 多源方案，必须保存
currentTime和paused状态，调用load()后等待loadedmetadata再恢复，且需兼容 Safari 的 seek 不稳定性 - 首帧加载用低清 poster + 静默预加载高清源，用户操作前完成缓冲，降低切换延迟
服务端配合提升鲁棒性
前端判断有局限，更可靠的方式是把关键参数传给服务端：
- 请求视频时带上
U-A、device-pixel-ratio（自定义 header）或 URL query（如?dpr=2&net=4g） - CDN 或业务后端根据这些信号返回最匹配的码率清单或直接下发适配后的流地址
- 避免前端硬编码所有分辨率路径，减少维护成本与 CDN 缓存碎片
