多媒体标签优化核心在于格式兼容性、加载策略和可访问性三者的平衡，缺一不可——否则会导致safari静音失败、低网速卡死或屏幕阅读器跳过。
直接说结论：多媒体标签优化不是“加个controls就完事”，核心在于格式兼容性、加载策略和可访问性三者的平衡——漏掉任意一项，都可能在 Safari 上静音失败、在低网速下卡死，或被屏幕阅读器跳过。
为什么<video></video>加了src还是不播放？
常见现象：本地双击 HTML 文件能播，但部署到服务器后黑屏、无报错；或者只在 Chrome 播，Safari 报 NotSupportedError。
- 根本原因不是代码写错，而是 MIME 类型未被服务器正确识别——MP4 文件若返回
text/plain，浏览器直接拒收 -
src路径必须是相对路径（如./videos/intro.mp4）或绝对 URL，不能用 Windows 本地路径（如D:\project\video.mp4） - 移动端 Safari 默认禁用自动播放（即使写了
autoplay），必须搭配muted才生效；否则会静音且不触发播放 - 如果只提供一种格式（比如只放 MP4），Firefox 或旧版 Edge 可能完全不加载，因为它们不原生支持 H.264 编码
怎么用<source></source>真正解决格式兼容问题？
不是“多写几个 <source></source> 就万事大吉”，顺序和类型声明缺一不可。
- 浏览器按
<source></source>出现顺序尝试加载，第一个能解码的就用——所以把兼容性最广的格式（video/mp4）放前面，再跟video/webm -
type属性必须写准确，例如type="video/mp4"，不能写成type="mp4"或漏掉 - MP4 文件需用 H.264 + AAC 编码组合，否则即使扩展名是 .mp4，Safari 也可能拒绝播放
- WebM 推荐用 VP9 + Opus，体积小、开源，但 iOS 全系不支持 WebM 视频——别指望它在 iPhone 上 fallback
preload设成 "auto"反而拖慢首屏？
默认值是 metadata，但很多人盲目改成 auto以为能“预加载更快”，结果首页加载时间翻倍。
-
preload="auto"会让浏览器立即下载整个视频文件（哪怕用户根本没点播放），对首屏 LCP 和带宽敏感场景极不友好 - 首屏关键视频（如 banner 主视频）建议用
preload="metadata"+poster图，既显示占位图，又只拉取头帧信息 - 非首屏视频（如页面底部“相关视频”）应设
preload="none"，等用户滚动到视口再用 JS 触发加载 - 配合
<link rel="preload" as="video" href="xxx.mp4">可精准控制预加载时机，但仅对当前页面内明确需要的资源有效
alt、poster、track 这些“非功能属性”为什么不能省？
它们不控制播放，但决定内容是否真正可达——尤其当视频因网络/编码/策略失败时，这些就是最后的防线。
-
alt是<img>的标配，但<video></video>没有alt；替代方案是用poster图 + 内联文字说明（放在<video></video>标签内部的文本节点） -
poster不只是封面图，它在视频加载失败、格式不支持、JS 被禁用时，是唯一可见内容，务必提供语义化描述（如poster="screenshot-accessible.png"） - 字幕必须用
<track kind="subtitles"></track>，且srclang和label都要写全，否则屏幕阅读器无法切换语言 - 所有
<video></video>和<audio></audio>必须包裹在<figure></figure>中，并配<figcaption></figcaption>，这是 WCAG 2.1 AA 级可访问性硬性要求
最容易被忽略的是：视频尺寸没做响应式处理，width/height 写死像素值，导致在手机上横向溢出或比例畸变；更隐蔽的问题是，poster 图分辨率远高于实际显示尺寸，白白浪费带宽——优化从来不是单点动作，而是格式、加载、结构、可访问性的连环校验。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
