最稳定流畅的方案是用<video><source>双格式配合preload="metadata"；单src易因Content-Type错误、iOS不支持H.265、Chrome有声autoplay限制而失败；实操应优先<source>、配MP4+WebM、服务端正确设MIME、自动播放必加muted并监听canplay事件。
直接用 <video> 或 <audio> 标签嵌入，配合 preload="metadata" 和双格式 <source>，是目前最稳定、最流畅的方案；iframe 嵌入第三方视频虽省事，但首屏加载慢、控制权弱、移动端常卡顿。
为什么 <video src="xxx.mp4"> 有时不播放？
单 src 属性看似简单，但实际容易失败：服务端未返回正确的 Content-Type（比如返回 text/plain 而非 video/mp4），浏览器会静默拒绝解码；iOS Safari 对 H.265（HEVC）完全不认，仅靠 MP4 无法兜底；Chrome 在无用户交互时拒绝有声 autoplay，报错 DOMException: play() failed because the user didn't interact with the document first。
实操建议：
- 永远优先用
<source>替代单src，至少提供video/mp4+video/webm两套源 - 在服务器配置中确认
.mp4返回video/mp4，.webm返回video/webm - 如需自动播放，必须加
muted，且不要在load后立刻play()，应等canplay或loadeddata事件触发
preload 设成 "none" 还是 "metadata"？
preload 不是“越早加载越好”。设为 "auto" 会让浏览器拉取整个视频文件，首屏白屏时间长、流量浪费大；设为 "none" 则用户点播放前毫无准备，点击后明显卡顿。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 绝大多数场景用
preload="metadata"：只请求头信息（时长、宽高、编码格式），100–300ms 内完成，不影响首屏渲染 - 仅当视频极短（preload="auto"
- 移动端务必加
playsinline，否则 iOS Safari 会强制全屏，打断页面流
iframe 嵌 YouTube 视频为什么常卡顿？
iframe 是黑盒加载，你无法控制其内部资源调度。YouTube 的嵌入页本身含广告脚本、推荐逻辑、分析埋点，首帧渲染常超 2s；更关键的是，它默认启用 loading="eager"，即使视频在视口下方也会提前加载；部分安卓 WebView 对 iframe 中的 autoplay 支持极差，甚至不触发 canplay 事件。
实操建议：
- 若必须用 iframe，手动加
loading="lazy"（注意：仅 Chromium 119+ 和 Safari 17.4+ 支持） - 移除所有非必要
allow权限，如allow="geolocation"，减少沙箱初始化开销 - 用 IntersectionObserver 监听进入视口后再动态插入 iframe，避免初始加载
poster 图片和 controls 怎么配才不翻车？
poster 不是可选项——没有它，视频加载期间是一片黑或空白，用户会误以为失败；而 controls 缺失则等于放弃所有基础交互，连暂停都做不到。
实操建议：
-
poster必须是同域图片，且尺寸严格匹配视频宽高比（推荐 16:9 或 4:3），否则拉伸失真 - 不要用 base64 编码的
poster，Base64 图片无法被浏览器缓存，每次刷新都重载 -
controls属性不可用 CSS 隐藏再自定义控件——屏幕阅读器会跳过整个<video>，违反无障碍要求
最容易被忽略的是 MIME 类型校验和用户手势约束：服务端配置错误会导致视频“看起来能加载但就是不动”，而任何绕过用户交互的自动播放尝试，在现代浏览器里都会被拦截，且错误提示藏在 Promise reject 里，不 catch 就看不到。
