使用 Blob URL 替代 Data URL 可显著减少内存占用，因其避免 Base64 编码导致的约 33% 体积膨胀和解码开销；应优先用 FileReader.readAsArrayBuffer() 或 new Blob() 创建 Blob，再通过 URL.createObjectURL() 生成可复用的 blob: 地址，并配合 Map/WeakMap 缓存及及时调用 URL.revokeObjectURL() 管理生命周期。
直接用 Blob URL 替代 Data URL 是减少内存占用最有效的方式。它不把文件转成 Base64 字符串，而是让浏览器直接读取原始二进制数据，避免约 33% 的体积膨胀和额外解码开销。
避开 Base64 编码，原生处理二进制
Data URL 把整个文件编码为字符串，1GB 视频会变成约 1.33GB 的字符串，严重拖慢渲染、吃光内存。Blob URL 不做任何转换，只生成一个指向本地 Blob 数据的内部引用，加载快、内存低。
- 读取文件时优先用 FileReader.readAsArrayBuffer() 或直接构造 Blob：
new Blob([arrayBuffer], {type: 'video/mp4'}) - 调用 URL.createObjectURL(blob) 得到 blob: 开头的地址，直接赋给
<video src>或<img src> - 这个 URL 可被多次复用，只要原始 Blob 还在内存中，就不需要重新读文件
复用已有 Blob，避免重复读取
用户反复预览同一文件（比如切换图片、重播视频），没必要每次都从磁盘再读一遍。把首次创建的 Blob 缓存起来，后续直接复用即可。
- 用 Map 或 WeakMap 存储，以文件名或内容哈希为 key，Blob 对象为 value
- 下次访问前先查缓存，命中就调用
URL.createObjectURL(cachedBlob)，跳过 FileReader - 注意：SPA 路由切换时若未保留引用，Blob 可能被 GC 回收，建议显式持有引用
及时释放，防止内存堆积
Blob URL 不会自动销毁，长期驻留会导致内存持续增长，尤其在频繁预览大文件的场景下必须主动管理。
立即学习“前端免费学习笔记（深入）”；
- 每次使用完后，立刻调用 URL.revokeObjectURL(url)，比如组件卸载、弹窗关闭、预览结束时
- 对需长期保留的资源（如已选头像），可延迟释放：监听
beforeunload或配合WeakRef+ 定时清理 - 开发阶段用 Chrome 的 Memory 面板拍快照，确认 Blob 数量稳定不持续上涨
配合服务端缓存，减少重复加载
Blob URL 解决的是前端复用问题，但如果资源来自网络（如 CDN 图片），还需减少重复请求。
- 确保服务端响应头含 Cache-Control: public, max-age=31536000
- 对象存储（如 S3、Azure）需单独为每个资源设置 cache-control 属性
- 前端首次 fetch 后调用
response.blob()构造 Blob URL 并缓存，后续直接复用，彻底跳过网络请求
