preload="none" 是多视频列表默认安全选择，可避免并发请求引发性能问题；高曝光视频可设 preload="metadata"，配合 IntersectionObserver 动态管理加载，并需超时兜底和移出清理。
preload="none" 是多数列表场景的默认安全选择
多视频列表（如信息流、短视频墙）中，90% 以上的视频用户根本不会点开。给所有 <video></video> 设 preload="auto" 会触发大量并发请求，尤其在低端安卓机或弱网下，极易引发内存压力、主线程阻塞甚至页面卡死。浏览器对 preload="auto" 的实际执行权完全自主——Safari 常直接忽略，Chrome 在省电/节流模式下也会降级为 metadata 或 none。
所以，默认统一设为 preload="none"，是控制资源消耗最直接有效的方式：
- 不发起任何网络请求，
src值可保留（便于后续 JS 激活），也可清空（更彻底释放潜在绑定） - 配合
loading="lazy"可进一步延迟初始解析，但注意：该属性仅对<img alt="HTML视频video标签怎么配置预加载属性降低性能消耗" >和<iframe></iframe>有强制规范支持，<video></video>的loading="lazy"行为依赖浏览器实现（Chrome 77+、Safari 15.4+ 支持，旧版需 JS 降级） - 若首屏前 2–3 个视频确定高曝光，可单独设
preload="metadata"，提前获取时长、封面帧等，避免点击后白屏等待
用 IntersectionObserver 动态切换 preload 而非 scroll 监听
滚动预加载不是靠 preload 属性本身实现的，而是靠 JS 检测可视状态后，动态修改 preload 和 src。直接监听 scroll 事件会导致高频触发、布局抖动和性能浪费；IntersectionObserver 是现代标准解法，轻量且原生支持阈值控制。
典型操作流程如下：
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 初始化时，所有视频保持
preload="none"，并确保src=""或移除src属性（避免浏览器预解析） - 创建
IntersectionObserver，设置threshold: [0, 0.25]，观测进入视口 25% 即触发 - 元素进入可视区时：
el.preload = "metadata"→ 触发元数据加载 → 监听loadedmetadata事件 → 显示 poster 或时长 → 用户点击再设preload = "auto"或调用load() - 元素完全移出可视区（且不再可能滚动回来）时：
el.preload = "none"+el.src = ""，主动中断已发起的请求并释放内存
preload="metadata" 加载失败时别硬等，要设 fallback
preload="metadata" 看似轻量，但依然依赖网络请求。如果视频源跨域且服务端未返回正确 Access-Control-Allow-Origin 头，或 CDN 返回 4xx/5xx，loadedmetadata 事件永远不会触发，UI 就卡在“无封面、无时长”的空白状态。
必须加超时兜底逻辑：
- 在设置
preload="metadata"后，启动一个 3–5 秒的setTimeout - 若
readyState >= 1（即已进入HAVE_METADATA）则清除定时器；否则视为失败，显示默认 poster 并标记“元数据加载异常” - 不要在失败后自动降级为
preload="auto"—— 这会突然拉起完整视频下载，违背节制原则
移动端 auto 模式基本无效，别信文档里的“浏览器自动选择”
HTML 规范里写 preload="auto" 是“让浏览器尽可能加载”，但现实是：iOS Safari 和大部分安卓 WebView 对该值完全无视；Chrome on Android 在 4G 以下网络或开启“节省流量”时，会强制按 none 处理；即使加载了，也常只缓存前几秒，后续仍需边下边播。
这意味着：
- 把
preload="auto"当作“保底策略”是错觉，它既不可控，也不可靠 - 真正可控的是：用户点击瞬间调用
video.load()或直接video.play()（需muted+playsinline） - 若业务强依赖首帧秒开，应考虑服务端 HLS 分片 + 客户端 MSE 拼接，而非依赖
preload
复杂点在于：preload 不是开关，而是提示；滚动预加载不是属性配置题，而是资源生命周期管理题。最容易被忽略的是——在元素移出可视区后忘记清空 src，导致已加载的视频资源长期驻留内存，尤其在长列表反复上下滚动时，内存占用会持续攀升。
