Edge 中 preload="auto" 导致 CPU 升高，因其在 DOM 就绪后立即多线程预解码，即使视频隐藏或不在视口；metadata 模式下若服务端缺失 Accept-Ranges: bytes 头，会下载整个文件解析元数据；none 模式下页面不可见时 Edge 会软暂停加载，切回后首帧延迟。
preload="auto" 为什么反而让 Edge CPU 升高
不是因为视频解码，而是浏览器在后台持续缓冲、解码、丢帧导致线程调度失衡。Edge 对 preload="auto" 的实现比 Chrome 更激进：它会在 DOM 就绪后立即启动多线程预解码，哪怕视频被 display: none 隐藏或不在视口内。
常见错误现象：Task Manager 显示 Edge 进程内存持续上涨、CPU 占用 >40%，但页面静止无交互；DevTools 的 Performance 面板能看到大量 DecodeFrame 和 MediaPipeline 任务堆积。
- 移动端（包括 Edge on Android）会降级为
metadata，但桌面 Edge 不会——它真会按 auto 去拉数据、解码、缓存 - 若视频未启用
faststart（moov box 在文件末尾），Edge 会反复请求 Range 片段并重试，触发大量无效 HTTP 请求 - 多个
<video preload="auto"></video>同时存在时，Edge 默认不节流，每个都分配独立解码线程，极易触发内存溢出
metadata 模式下仍吃内存？原因在服务端响应头
preload="metadata" 看似轻量，但实际行为取决于服务端是否返回 Accept-Ranges: bytes。没这个头，浏览器无法做字节范围请求，只能下载前几 KB 甚至整个文件来解析时长和分辨率——这直接导致首屏流量翻倍、内存占用不降反升。
真实场景中，Nginx 或 CDN 默认不开启范围请求，尤其对 MP4 文件；而开发者常误以为“只取 metadata 就一定快”，结果在 Edge 中看到 Network 面板里一个 206 Partial Content 都没有，全是 200 OK + 大体积响应体。
立即学习“前端免费学习笔记（深入）”；
- 验证方式：在 DevTools 的
Network标签页过滤视频 URL，看响应状态码和Content-Range头是否存在 - 修复手段：Nginx 加
add_header Accept-Ranges bytes;；CDN 控制台开启「Range 回源」开关 - 注意：即使开了 Range，若视频未用
ffmpeg -c copy -movflags +faststart重写，metadata 解析仍需扫描大量数据，内存峰值不变
none 模式下首次点击卡顿，其实是 Edge 主动暂停了加载队列
Edge 在页面不可见（比如切到其他 tab）或系统开启省电模式时，会对所有 preload="none" 的媒体资源执行「软暂停」：已发起的请求会被挂起，未发起的延迟至页面重新聚焦。这不是 bug，是策略——但它导致用户切回来点播放时，要等一次完整的 TCP 握手 + 首帧解码，感知就是“点了没反应”。
- Chrome/Firefox 会继续后台加载，Edge 则严格遵循 visibilityState === 'visible' 才恢复
- 该行为无法通过 JS 绕过，
video.load()在页面隐藏时调用无效，且不会触发error事件 - 解决方案不是改
preload，而是用IntersectionObserver监听进入视口后立刻调用video.load()，避开系统级暂停时机
真正可控的资源占用控制点只有三个
别再纠结 preload 取值。Edge 的媒体加载行为高度依赖底层 Chromium 分支策略，HTML 层面的声明只是建议。真正能压住 CPU 和内存的，是组合动作：
- 服务端：MP4 必须
faststart，HTTP 响应必须带Accept-Ranges: bytes和Cache-Control: public, max-age=31536000 - HTML 层：用
<link rel="preload" href="xxx.mp4" as="video">替代preload属性，让资源发现更早、优先级更明确 - JS 层：监听
visibilitychange，页面隐藏时调用video.pause()+video.src = ''清空缓冲区；恢复时重新赋值src并load()
最容易被忽略的是第三点：Edge 不会自动释放已缓冲的视频帧，src = '' 是唯一可靠清空方式。不这么做，滚动列表页时每换一个 <video></video>，内存就涨一块，直到 OOM。
