必须包含可解码资源（src或source）、controls属性（提供交互入口）、降级文本（如“Your browser does not support the video tag”）三部分，缺一不可。
video 标签必须包含哪些基础部分才能正常工作
只写 <video></video> 是无效的——它不会加载、不会显示、也不会报错，只是个空容器。真正起作用的最小结构必须满足三个硬性条件：有可解码的资源、有用户交互入口、有降级兜底。
常见错误是以为加了 src 就够了，但 Safari 对没有 controls 且没用 JS 控制的 <video> 会直接拒绝播放（尤其 iOS）；而纯靠 autoplay muted 又可能被 Chrome 静音策略拦截，导致“无声播放”或根本不动。
-
src属性或至少一个<source>子元素（二者选一，但推荐后者） - 显式声明
controls（开发调试阶段别省，否则你无法判断是代码问题还是策略拦截） - 在
<video>开闭标签之间写一段纯文本，如Your browser does not support the video tag.（不是可选，是必须——否则无障碍和旧浏览器完全无反馈）
为什么比src更可靠，以及怎么写才不被浏览器跳过
直接写 src="video.mp4" 看似简单，但一旦 MP4 编码不兼容（比如用了 H.265 或 High Profile），整个视频就卡死；而用 <source> 能让浏览器主动探测、跳过不可解码项，容错率高得多。
关键不是“多写几个格式”，而是顺序和 type 的准确性。浏览器按 DOM 顺序逐个尝试，遇到第一个能解码的就停，后面全忽略。所以 MP4 必须放最前，且 type="video/mp4" 不能写成 video/mpeg 或漏掉 video/ 前缀——哪怕文件名是 .mp4，type 错了也会被跳过。
立即学习“前端免费学习笔记（深入）”；
- MP4 文件必须用 H.264 Baseline 或 Main Profile + AAC-LC 编码，否则 iOS Safari 拒绝播放
- WebM 推荐 VP9 + Opus，Chrome/Firefox/Edge 原生支持，Safari 16.4+ 才支持 VP9
- Ogg 已基本淘汰，Firefox 也逐步弱化支持，除非要兼容 2015 年前的老设备，否则可删
-
media属性仅控制是否下载资源，不影响播放格式选择，别指望它做“响应式格式切换”
poster 和 preload 的真实行为差异，别被文档误导
poster 不是“封面图”，而是“首次渲染占位图”：它在 <video> 元素创建后立刻显示，直到第一帧视频数据就绪才消失。如果视频加载慢或失败，poster 会一直挂着——所以它得是静态图，别用 base64 大图拖慢首屏。
preload 更常被误解为“预加载多少”，实际它只是给浏览器的提示，浏览器有权无视。实测中：metadata 确实只拉头部信息（快），auto 在移动端常被强制降级为 metadata（省流量），none 也不保证绝对不加载——比如加了 autoplay，浏览器就可能忽略 preload="none"。
- 设
preload="metadata"+controls是最稳组合：快出控件、不卡主线程 -
poster路径必须可访问，404 会导致 poster 区域空白（不是 fallback 文本顶上） - 不要给
preload设值后又用 JS 调load()——重复触发加载逻辑，可能引发双请求
移动端全屏与内联播放的坑，尤其是微信和 iOS
iOS Safari 默认全屏播放，加 playsinline 才能内联；但微信 iOS 客户端默认禁用该属性，必须额外加 webkit-playsinline 和 x5-video-player-type="h5" 才生效。安卓微信则依赖 x5-video-player-type 和 x5-video-player-fullscreen 控制横竖屏行为。
这些属性不是标准 HTML，是厂商私有扩展，不写不会报错，但写了也不一定生效——比如 x5-video-orientation="portraint" 在新版微信里已失效，现在靠 CSS object-fit 和容器宽高比控制画面裁剪更可靠。
- 真机测试必做：iOS Safari、微信 iOS、微信安卓、Chrome Android 各跑一遍
-
playsinline和webkit-playsinline必须同时存在，缺一不可 -
x5-系列属性只在 QQ 浏览器和微信内置浏览器生效，其他环境忽略，不用删但别依赖 - 全屏退出后，iOS 可能残留黑屏或尺寸错乱，需监听
webkitendfullscreen事件手动重置
