poster不能直接当可靠占位图用，它仅在loadedmetadata事件触发前显示，而该事件受网络、编码和浏览器策略影响，弱网下可能延迟消失，但首帧解码快时仍会一闪即逝。
poster 属性在弱网下是否真能当“占位图”用
不能直接当可靠占位图用。它只在 loadedmetadata 事件触发前显示，而这个事件的触发时机高度依赖网络延迟、视频编码结构和浏览器策略——不是“加载完图片就显示”，而是“视频元数据解析完成才消失”。弱网下，loadedmetadata 可能几秒后才触发，此时 poster 确实可见；但若视频首帧极小（如黑帧 + 快速解码），哪怕网速差，它也可能一闪即逝。
常见误判点：
- 看到 poster 显示了 2 秒 → 以为“它扛住了弱网”，实际是视频本身首帧慢，不是 poster 的功劳
- 用
preload="none"期望强制保留 poster → 多数浏览器仍会在用户点击 controls 后立即加载并触发loadedmetadata，poster 随即消失 - 把 poster 当成 img 一样参与 CSS 布局流 → 它不占文档流，仅作为 video 内部渲染层，无法用
margin或flex调整其位置
poster 图片加载失败时会不会触发 error 事件
不会。poster 是 HTML 属性，不是资源请求节点，浏览器不为其创建 HTMLImageElement 实例，因此监听不到 error 事件。路径 404、MIME 错误或跨域拒绝，只会静默失效，video 区域留白或回退到首帧（如果可解码）。
必须主动兜底：
- 用
background-image给<video>元素设 CSS 底图：style="background: url(/assets/cover-fallback.jpg) center/cover;" - 用 JS 检查 poster 路径有效性：fetch 该 URL 并判断 status 是否为 200，再决定是否插入覆盖层
- 避免用 base64：安卓 WebView 和 iOS Safari 15 以下版本会直接忽略，且 base64 字符串增大 HTML 体积，影响首屏解析
poster 图片是否会常驻内存直到 video 卸载
不会。poster 图片一旦被浏览器解码为纹理，就和 video 元素生命周期绑定；当 video 元素被移除 DOM 或 src 被重置，该纹理通常会被 GC 回收。但要注意：
- 若用 JS 动态赋值
video.poster = 'xxx.jpg'，部分浏览器（如 Chrome）不会重新解码，而是复用旧纹理，导致内存未及时释放 - 多个 video 共享同一 poster URL，浏览器一般会复用解码结果，但每个 video 仍会持有一份纹理引用
- 移动端尤其敏感：iOS Safari 对 video 纹理有硬性内存上限，poster 图片过大（>1024×1024）可能挤占后续视频帧解码空间，引发卡顿或 crash
Chrome 和 Safari 在 poster 渲染时机上的关键差异
Chrome v78+ 在 loadedmetadata 触发后立刻隐藏 poster；Safari 则持续显示到用户首次交互（点击播放/拖动进度条）为止。这不是 bug，是设计选择——Safari 把 poster 当作“封面”，Chrome 当作“加载提示”。
跨浏览器稳定方案必须放弃纯 HTML 依赖：
- 静态写死
poster属性，同时加class="has-poster"用于 CSS 控制备用背景 - 监听
loadedmetadata，在 Chrome 中插入绝对定位的<img class="poster-overlay">，并在play或timeupdate事件中移除 - 对 iOS 微信等 WebView，禁用原生 poster，全程用 DOM 覆盖层模拟，避免因系统策略导致空白
真正难处理的不是怎么让 poster 显出来，是怎么让它在不同设备上“消失得恰到好处”——早了用户看不到，晚了遮挡播放控制按钮，中间还夹着内存、解码、手势权限三重约束。
