深入剖析HTML多媒体：video标签的骨架结构-html教程-PHP中文网

必须包含可解码资源（src或source）、controls属性（提供交互入口）、降级文本（如“your browser does not support the video tag”）三部分，缺一不可。

深入剖析html多媒体：video标签的骨架结构

video 标签必须包含哪些基础部分才能正常工作

只写 <video></video> 是无效的——它不会加载、不会显示、也不会报错，只是个空容器。真正起作用的最小结构必须满足三个硬性条件：有可解码的资源、有用户交互入口、有降级兜底。

常见错误是以为加了 src 就够了，但 Safari 对没有 controls 且没用 JS 控制的 <video></video> 会直接拒绝播放（尤其 iOS）；而纯靠 autoplay muted 又可能被 Chrome 静音策略拦截，导致“无声播放”或根本不动。

src 属性或至少一个 <source></source> 子元素（二者选一，但推荐后者）
显式声明 controls（开发调试阶段别省，否则你无法判断是代码问题还是策略拦截）
在 <video></video> 开闭标签之间写一段纯文本，如 Your browser does not support the video tag.（不是可选，是必须——否则无障碍和旧浏览器完全无反馈）

为什么比src更可靠，以及怎么写才不被浏览器跳过

直接写 src="video.mp4" 看似简单，但一旦 MP4 编码不兼容（比如用了 H.265 或 High Profile），整个视频就卡死；而用 <source></source> 能让浏览器主动探测、跳过不可解码项，容错率高得多。

关键不是“多写几个格式”，而是顺序和 type 的准确性。浏览器按 DOM 顺序逐个尝试，遇到第一个能解码的就停，后面全忽略。所以 MP4 必须放最前，且 type="video/mp4" 不能写成 video/mpeg 或漏掉 video/ 前缀——哪怕文件名是 .mp4，type 错了也会被跳过。

html-deploy

使用 htmlcode.fun 将 HTML 内容或文件部署到网页，适用于用户要求“部署到网页”“托管此 HTML”“生成此前端...的实时链接”等场景。

下载

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></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 和容器宽高比控制画面裁剪更可靠。