Base64图片存localStorage仅适用于≤50KB的极小静态资源（如1KB SVG logo、2KB loading spinner），需内联或首屏后立即存入，读取前必须校验data.startsWith('data:image/')，且不支持自动更新；体积膨胀33%、隐私模式失效、无监听机制，多数场景应优先选用HTTP缓存+Service Worker或IndexedDB。
直接用 localStorage 存 Base64 图片，多数情况下是错的——它膨胀体积、不支持二进制、隐私模式失效，且首次加载并未真正省请求。
Base64 + localStorage 适合什么场景
只适用于极小、极静态、极少更新的资源，比如 1KB 的 SVG logo、2KB 的 loading spinner。单图建议严格控制在 ≤50KB；超过这个量级，体积膨胀（Base64 比原始二进制大 33%）和写入阻塞就会明显拖慢 JS 主线程。
- 必须内联或首屏后立即存：不能等用户点开才 fetch → 转 Base64 → 存，否则体验断层
- 读取前务必校验：
if (data && data.startsWith('data:image/'))，否则可能把空字符串或过期键当有效数据赋给src - 别依赖它做“版本更新”：localStorage 没监听机制，图片换了 URL 但键名没变，就永远读不到新图
IndexedDB 是更合理的本地图片存储方案
它原生支持 Blob 和 ArrayBuffer，不编码、不膨胀、容量大（Chrome 单库可达数百 MB），还带事务和索引。适合存用户头像、离线相册、编辑中的草稿图等中大型资源。
- 初始化时用
onupgradeneeded建objectStore，设keyPath: 'id'，再加name和type索引方便查 - 存图走三步：用
FileReader读取文件 → 得到result（即Blob）→ 在事务里调store.add({ id, name, type, data: blob }) - 读取时用
get()或index.get('avatar.jpg')，返回的是Blob，可直接生成URL.createObjectURL(blob)赋给img.src
什么时候该放弃本地存储，回归 HTTP 缓存
绝大多数线上项目，图片根本不需要“存在前端”。用好 Cache-Control、ETag、CDN 缓存策略 + Service Worker 预缓存，比任何客户端数据库都稳。
立即学习“前端免费学习笔记（深入）”；
- CDN 自动压缩、格式转换（如请求
.jpg但返回 WebP）、实时裁剪，这些能力IndexedDB完全不具备 -
Service Worker可拦截图片请求，命中缓存就直接响应，不触发网络；还能按需更新缓存，解决“旧图不刷新”问题 - 混用本地存储和 HTTP 缓存极易出错：比如 IndexedDB 存了图 A，但 CDN 缓存了图 A 的旧版，用户看到的就是错乱组合
真正难的不是“怎么存”，而是“谁该负责这张图的生命周期”。运营配图归 CDN，用户上传归 IndexedDB，固定图标归构建时内联——边界划不清，技术选型再准也会翻车。
