用唯一键（如临时URL或内容哈希）关联Blob和File元数据，Map中只存业务元数据，封装统一接口处理类型转换与键生成，前端Map仅限当前会话，需结合服务端ID做持久化对齐。
用 Map 关联 Blob 和 File 的元数据，核心在于把它们当作“同一份二进制数据的不同视图”，再用唯一键（如 URL 或内容哈希）建立映射。关键不是强行统一类型，而是统一标识和管理逻辑。
选对键：不依赖 name 或 size，用稳定标识
Blob 和 File 都可能没有 name（比如 fetch 返回的 Blob），或 size 相同但内容不同。所以不能用这些字段做 Map 键。
- 推荐用
URL.createObjectURL(blob)生成的临时 URL 作键——浏览器保证同一 Blob 实例对应唯一 URL，且 File 也能转成 Blob 后生成相同 URL - 若需持久化或跨会话，可用内容哈希（如 SHA-256）：先调用
blob.arrayBuffer()，再用 Web Crypto API 计算哈希值作为键 - 避免直接用 Blob/File 实例本身作键——Map 默认用引用比较，两个内容相同的 Blob 是不同实例，无法命中
存什么：元数据应分层设计，不混杂原始属性
File 自带的 name、lastModified 属于“来源信息”，Blob 没有；而 uploadId、tags、processedAt 属于“业务元数据”，两者都可附加。Map 中建议只存后者。
- 示例结构：
map.set(url, { uploadId: 'abc123', tags: ['image', 'user-upload'], processedAt: Date.now() }) - 不要把
file.name直接塞进 Map 值里——它属于 File 实例的固有属性，重复存储易导致不一致 - 若需反查原始 File，可额外维护一个弱引用映射（
WeakMap<Blob, File>），但仅限当前会话内使用
怎么用：封装读写操作，屏蔽类型差异
对外暴露统一接口，内部自动处理 Blob/File 转换和键生成：
-
attachMetadata(blobOrFile, metadata)：先转为 Blob（File 可直接传，Blob 不变），再生成 URL 键并存入 Map -
getMetadata(blobOrFile)：同样标准化输入，用相同逻辑生成键去查 Map -
clearBySource(file)：利用 WeakMap 找出所有关联的临时 URL 键，批量删除——避免内存泄漏
注意边界：Map 不替代服务端元数据存储
前端 Map 只在当前页面生命周期有效。如果用户刷新页面，或多个标签页协作上传，需配合后端 ID（如 Azure Blob 的 etag 或自定义 x-ms-meta- 头）做二次对齐。
- 上传成功后，把服务端返回的 blob URL 或容器路径作为新键，更新 Map 中对应项
- 下载时若拿到的是纯 Blob，可先查本地 Map 是否有缓存元数据；没有则回退到默认值或发起轻量 API 查询
