poster属性仅在视频未加载或加载失败时显示，一旦元数据就绪即被替换；不显示常见于autoplay触发延迟、资源404、格式不兼容、图片过大或source未声明type等加载策略问题。
poster 属性确实是视频加载前最直接、最轻量的视觉占位方案，但它不是“封面图”那么简单——它只在 video 元素尚未开始加载或加载失败时生效，一旦视频元数据就绪（哪怕还没播放），poster 就自动隐藏，且无法通过 CSS 控制显隐逻辑。
为什么 poster 有时不显示？
常见原因不是写法错，而是浏览器加载策略干预：
- 设置了
autoplay或muted且用户交互未触发时，部分浏览器（如 Chrome）会延迟加载元数据，导致poster短暂闪现后黑屏，而非稳定停留 -
src指向的视频 URL 返回 404 或跨域拒绝，poster可能根本不渲染（Safari 尤其敏感） - 使用了
source多格式嵌套但没配type，浏览器无法预判能否解码，可能跳过poster渲染阶段 -
poster图片本身加载慢或尺寸过大（>200KB），在视频元数据到达前已超时被丢弃
poster 和骨架屏怎么选？
二者定位不同，不是替代关系：
-
poster是单张静态图，适合视频内容明确、首帧即代表主题的场景（如产品介绍、课程封面） - 骨架屏是结构化占位，适合视频区域嵌套在复杂布局中（比如卡片流里的
video），需维持整体高度/圆角/边距一致性 - 若视频加载耗时长（>1.5s），仅靠
poster会让用户误以为卡死；此时应在video外层包裹.skeleton-video容器，用 CSS 动画模拟“正在缓冲”状态 - 服务端渲染（SSR）页面中，
poster无法解决首屏 FOUC（Flash of Unstyled Content），必须配合内联骨架 HTML +visibility: hidden初始态
如何让 poster 更可靠？
关键不在加属性，而在控制加载时机和 fallback 路径：
立即学习“前端免费学习笔记（深入）”；
- 始终为
poster提供 WebP 格式 + 尺寸压缩（建议 ≤ 640×360，≤80KB），避免 Base64 内联（增大 HTML 体积，阻塞解析） - 不要依赖
preload="metadata"强制触发poster，它和autoplay冲突，且 Safari 对该值支持不稳定 - 监听
video的error和stalled事件，在 2s 内未进入loadedmetadata状态时，手动切换到骨架屏容器 - 对移动端，可加
decoding="async"到poster的img标签（如果用 JS 动态插入），避免解码阻塞主线程
真正容易被忽略的是：当视频源来自 CMS 或用户上传时，poster 往往缺失或尺寸失配，此时硬编码 poster 属性反而导致布局塌陷。更稳妥的做法是用 aspect-ratio 锁定容器比例，再让 poster 作为可选增强项存在。
