video标签本身可播放高清视频，关键在于分辨率适配、加载策略（如preload="metadata"）和错误降级三方面稳定，需合理选用MP4/WebM格式、规范type属性、避免相对路径过深，并注意移动端全屏与CSS渲染兼容性。
video 标签本身就能撑起高清视频播放窗口，不需要额外框架或 SDK。关键不是“能不能播高清”，而是“怎么让高清不卡、不闪、不白屏”——分辨率适配、加载策略、错误降级这三件事得稳住。
高清视频的 src 和 source 怎么选格式与路径
直接用 src 属性最简单，但兼容性差；用多个 <source> 才能覆盖主流浏览器。MP4（H.264+AAC）是必选项，WebM（VP9+Opus）作为次选，Ogg 基本可弃用。
- 高清 ≠ 大文件：1080p 视频优先用 H.264 High Profile 编码，码率控制在 4–6 Mbps，比盲目堆分辨率更省带宽
-
<source>的type必须写全 MIME 类型，比如type="video/mp4"，漏掉会触发 fallback 文本而不是下一源 - 路径别用相对路径嵌套太深，如
./videos/lesson01/1080p.mp4，容易因路由跳转丢失上下文；推荐统一放在/assets/videos/下 - 移动端 Safari 对 WebM 支持依然有限，iOS 用户大概率 fallback 到 MP4，所以 MP4 必须可用且首帧快
preload 设成 "metadata" 而不是 "auto"
课程类高清视频单集常超 100MB，preload="auto" 会让浏览器一进页面就预加载整个文件，用户还没点播放，流量和首屏时间全被吃掉。
-
preload="metadata"只拉取时长、宽高、封面帧，几 KB 就搞定，currentTime和duration都能读到 - 如果页面有自动播放需求（比如首页 banner），必须加
muted，否则 Chrome 和 Safari 直接拒绝play() - 别信“
preload="none"最省流量”——它会导致点击播放后黑屏等待数秒，体验断层更伤用户留存
全屏按钮点击后 requestFullscreen() 失败的常见原因
不是代码没写，而是触发时机或元素状态不对。浏览器对全屏 API 的限制比想象中严格。
立即学习“前端免费学习笔记（深入）”；
- 必须在用户手势（
click或touchend）回调里调用，不能包裹在setTimeout或异步 Promise 里 -
video元素不能是display: none或visibility: hidden状态，哪怕只隐藏 1ms，requestFullscreen()就静默失败 - iOS Safari 不支持对
video元素调用requestFullscreen()，它只认dialog或整个body；真要兼容，得用dialog包一层再全屏 - 调用前先检查
video.readyState >= 2（HAVE_CURRENT_DATA），否则可能报InvalidStateError
高清画面在移动端变形、拉伸或黑边的 CSS 写法
不是所有“100% 宽度”都等于“铺满视口”，尤其在 iOS Safari 和部分安卓 WebView 中，object-fit 行为不一致。
- 固定宽高比用
aspect-ratio: 16 / 9（现代浏览器），fallback 用 padding-top 百分比技巧 -
object-fit: cover是首选，确保高清内容不被压缩；fill会拉伸，contain留黑边 - 别给
video设width: 100%; height: 100%，父容器若没明确尺寸，它会塌缩；改用width: 100%; aspect-ratio: 16/9; - Android 微信内置浏览器对
aspect-ratio支持差，需加min-height: 50vh防止过小
高清播放窗口最难的不是分辨率数字，而是让每个环节——从 HTTP 请求头里的 Accept-Ranges 支持，到 video 元素的 canplaythrough 事件时机，再到用户手指松开那一刻的 requestFullscreen 响应——全部咬合到位。漏掉任意一环，高清就只剩“高”字，没“清”。
