Blob URL 缓存大型静态资源的核心是绕过 Base64 编码、避免重复磁盘读取，将二进制数据驻留内存复用；需配合 URL.revokeObjectURL 及时释放、服务端 Cache-Control 协同优化。
直接用 Blob URL 缓存大型静态资源，核心在于绕过 Base64 编码、避免反复读取磁盘文件，同时把二进制数据保留在内存中供多次快速复用。关键不是“存得久”，而是“用得准、放得及时”。
用 Blob URL 替代 Data URL（避开 Base64）
Base64 编码会让体积膨胀约 33%，解码还要额外 CPU 开销，对图片、PDF、音视频等大文件尤其明显。Blob 则原生持有二进制数据，无需编码转换：
- 读取文件时用 FileReader.readAsArrayBuffer() 或直接构造 Blob（如
new Blob([arrayBuffer], {type: 'image/jpeg'})） - 生成可复用地址：
const url = URL.createObjectURL(blob) - 该 url 可直接用于
<img src>、<video src>、fetch(url)等，浏览器内部自动处理二进制流
复用已有 Blob，避免重复磁盘读取
用户多次打开同一文件（比如预览 PDF、切换图片），不必每次都 input.files[0] 再读 —— 只要原始 Blob 还在内存中，就复用它生成新 URL：
- 把首次创建的 Blob 存在 Map 或 WeakMap 中，以文件名/哈希为 key
- 后续访问时检查是否存在，存在则直接
URL.createObjectURL(cachedBlob) - 注意：Blob 本身不随页面跳转消失，但单页应用（SPA）中路由切换若未保留引用，会触发 GC；建议显式缓存引用
控制生命周期，防止内存堆积
Blob URL 不会自动释放，长期驻留会吃光内存，尤其在频繁预览大文件的场景下：
- 每次用完后，立刻调用
URL.revokeObjectURL(url)，尤其在组件卸载、弹窗关闭、预览结束时 - 对需长期保留的资源（如已选中的头像、上传草稿），可延迟释放：监听
beforeunload或用WeakRef+ 定时清理策略 - 开发阶段用 Chrome Memory 面板拍快照，确认 Blob 数量稳定不增长
配合服务端缓存进一步减少加载
Blob URL 解决的是“前端复用”，但如果资源来自网络（如 CDN 上的图片），仍需减少重复请求：
- 确保服务端响应头含
Cache-Control: public, max-age=31536000（一年） - Azure Storage、S3 等对象存储需单独为每个 Blob 设置 cache-control 属性，web.config 的配置对其无效
- 前端首次 fetch 后得到 Response.blob()，即可构造 Blob URL 并缓存；后续直接复用，跳过网络请求
