图片解码后内存占用取决于宽×高×每像素字节数，与格式无关；JPEG/WebP/AVIF/PNG 解码后多为 RGBA 4 字节 / 像素，1920×1080 约 8.3MB；真正影响内存压力的是解码时机、驻留周期与生命周期管理。
图片格式直接影响浏览器解码后的内存占用，相同尺寸的图片在不同格式下，解码后占用的内存可能相差 2–4 倍。关键不在文件体积大小，而在于解码后像素数据的存储方式——浏览器对每种格式采用不同的解码策略和内存布局。
解码后内存 = 宽 × 高 × 每像素字节数
无论原始格式是 JPEG、PNG 还是 WebP，浏览器最终都要将其解码为 RGBA（或有时 RGB）位图送入 GPU 渲染管线。此时内存开销由像素总数和通道精度决定：
- JPEG / WebP / AVIF 解码后通常为每像素 4 字节（RGBA，8 位 / 通道），即 1920×1080 图片 ≈ 1920 × 1080 × 4 ≈ 8.3 MB 内存
- PNG 若含 Alpha 通道，同样占 4 字节 / 像素；若为纯灰度 PNG（无 Alpha），部分浏览器仍会升格为 RGBA，实际仍按 4 字节算
- WebP 有“无损 +Alpha”和“有损 +Alpha”两种模式，但解码结果均为全尺寸 RGBA 位图，内存占用与同分辨率 JPEG 一致
- AVIF 支持更高位深（如 10bit），但当前主流浏览器（Chrome/Firefox/Safari）默认仍解码为 8bit RGBA，内存不额外增加
格式影响的是解码时机与内存驻留周期
不同格式的解码行为会影响内存峰值和释放时机，而非单张图的静态内存值：
- JPEG：流式解码快，但解码后位图常驻内存，直到 img 元素被移除或 GC 触发
- PNG：需完整加载并校验 CRC 后才开始解码，首帧延迟略高；透明区域多时，Alpha 混合计算可能延长渲染管线驻留时间
- WebP：支持渐进式解码（部分浏览器已支持），可更早呈现模糊预览，降低用户感知等待，但总内存占用不变
- AVIF：解码 CPU 开销显著更高（尤其低端设备），可能导致主线程阻塞，间接引发内存回收延迟，出现短暂内存堆积
真实场景中更需关注复用与生命周期管理
单图内存可估算，但实际内存压力来自大量图片同时处于解码后状态：
立即学习 “Java 免费学习笔记（深入）”；
- 滚动长页中未卸载的 <img> 即使移出视口，只要 DOM 存在且 src 已加载，其解码位图大概率仍在内存中
- 使用 loading=”lazy” 可推迟解码，但一旦进入视口，仍会立即解码并驻留；配合 IntersectionObserver 主动 release（如设置 src=””）才能真正释放
- Canvas 绘制图片后，若未 clear 或重用 canvas，原图位图 +canvas 像素缓冲可能双份驻留
- Service Worker 缓存 WebP/AVIF 文件虽节省网络带宽，但不减少解码内存——缓存越高效，越容易无意中让多张高清图长期驻留内存
优化建议：控解码、管生命周期、量实际内存
别只盯着文件大小压缩，要主动干预解码行为和内存存活时间：
- 对非首屏图片，用 decode() 方法 + await 控制解码时机，避免 onload 自动触发导致批量解码高峰
- 大图展示后，如用户长时间未交互，可调用 createImageBitmap() 配合 transferToImageBitmap() 实现零拷贝纹理上传，并及时 revokeObjectURL
- 用 Chrome DevTools 的 Memory > Heap Snapshot +“Images”分类 查看解码后位图数量和尺寸，比 Network 面板的文件大小更有参考价值
- 在低端设备上，可 UA 检测后降级为 JPEG（而非仅靠 <picture> 格式回退），因 JPEG 解码器更成熟、内存碎片更少
