每改一版就重传整份文件：设计文件存储为什么要把内容和版本拆开
设计文件存储服务要保存的不是一份"文件"，而是一条可以随时回到任意历史版本、还能让多人同时编辑的修改历史。它最常见的做法是把不可变的内容块按哈希存进对象存储，再用一份可变的清单和版本指针把块串起来，于是"存新版本"只是写一份新清单、切换一个指针，而不是复制整份文件。很多人把它当成网盘来设计，用覆盖写和修改时间表达版本，结果遇到缓存读到半成品、并发保存互相覆盖、删除后空间收不回。读完你能说清内容寻址、清单、版本指针与延迟回收各自解决什么问题，也能判断块该切多大、签名链接该给多长。
是什么
设计文件存储服务是设计工具背后的存储层：它要接住画布文档、上传的图片与字体、导出的缩略图和 PDF，还要支撑历史版本、多人协同和分享链接。它的接口看起来和网盘差不多——上传、下载、删除——但语义完全不同：网盘存的是"某个时刻的一份字节"，设计工具存的是"一条可回溯的修改历史"。直觉上它像出版社的仓库：正文按页码印好、编上号放进库房，库房里的书不能改；前台那本目录可以换，目录指向哪几页，读者就看到哪一版。典型场景是设计师反复保存、运营同学回滚到上周的稿子、客户端拉取增量、分享页按权限出图。把这些需求压成一句"把文件传到对象存储"，后面的问题基本都会出现。
核心原理
第一层：内容不可变。 文件按固定大小切块，每块用 SHA-256 之类的摘要当键，写进对象存储。同一个块无论被哪个文件、哪个版本引用，物理上都只有一份；键由内容决定，所以写入天然幂等，重传不会产生副本。这与"用文件名当键"相反：文件名会复用，内容哈希不会。
第二层：清单把块串起来。 一份清单记录这个版本由哪些块、按什么顺序组成，以及画布尺寸、字体列表这些元数据。清单本身很小，可以整份写、整份读，也可以整体做哈希得到版本号。
第三层：版本指针可切换。 数据库里存"文件 → 当前版本 → 清单"的映射，提交新版本就是插入一条版本记录并把指针指过去，在一个事务里完成。旧版本仍然指向旧清单，天然可回滚。整份覆盖的写法在这里最吃亏：它把"内容"和"当前版本"绑在一个键上，写一半失败就留下半成品，缓存也可能把中间态当成新版本。
import hashlib, json
def commit(store, db, file_id, chunks, meta):
keys, h = [], hashlib.sha256()
for data in chunks: # 块已在别处上传并校验
key = hashlib.sha256(data).hexdigest()
store.put_if_absent(key, data) # 内容寻址，重复写无副作用
keys.append(key); h.update(key.encode())
manifest = {"blocks": keys, "meta": meta}
version = h.hexdigest()
store.put_if_absent(f"m/{version}", json.dumps(manifest).encode())
db.set_pointer(file_id, version) # 单事务切换，旧版本仍可读
return version去重与回收。 块只存一份，省下的是跨版本、跨文件的重复内容，修改一页不必重传整份稿子。但"谁在引用这个块"不能只靠一个计数器：并发提交时先加引用再落库，中间崩溃就会多算；先落库再加引用，又可能被回收线程扫掉。稳妥做法是版本表作为唯一事实来源，回收分两步——先标记所有可达块，再延迟一段时间删除不可达块，给正在上传的会话留出窗口。
上传与读取。 大文件走分片上传：先开会话，逐片传，服务端记录已收到的片号和摘要，最后合并并校验整体哈希，成功后才让清单可见。读取时先做权限判断，再签发短时效的下载地址；块内容永不变，可以放心交给 CDN 长缓存，清单和指针则必须短缓存或不缓存。删除同理：先删指针，块交给延迟回收，避免正在读旧版本的用户突然拿到 404。
派生资产也要挂到版本上。 缩略图、预览图、导出的 PDF 都是清单的函数，不该和画布文档混在一张表里。做法是以清单哈希加渲染器版本作为缓存键，重新生成时旧产物仍可服务，升级渲染器也不会污染历史版本的显示效果。
常见考点与误区
- 误区一：用对象键覆盖来表达"新版本"。面试常问"版本历史怎么存"，答"每次上传覆盖同一个 key，数据库记一下时间"就错了。覆盖让旧版本不可恢复，也让 CDN 和客户端可能读到写了一半的对象；正确做法是不可变内容加可变指针。
- 误区二：把去重当成纯省钱功能。跨租户去重会泄漏"这个文件是否已存在"的侧信道，恶意用户能靠上传试探他人内容；生产上要么按租户隔离命名空间，要么对块加密后再存。
- 误区三：以为签名链接就是权限控制。签名一旦发出，在过期前无法撤回，权限被移除的人也还能用；因此有效期要短、要绑定具体对象和操作，敏感文件还得走服务端代理校验。
- 误区四：以为对象存储强一致就等于系统一致。单个对象的读写如今大多已经是强一致的，但跨区域复制、批量列表与中间缓存层仍有延迟；判断"我刚刚保存的那一版"要用返回的版本号去读，而不是靠时间戳或"最新"。
- 考点五：回收与上传的竞态。标记阶段没算上正在传输的块，清理阶段就可能把马上要用的块删掉；回答时要主动提延迟删除、引用计数和上传会话的租约。
- 考点六：块越大越好或越小越好。块大，元数据少但去重粒度粗、重传代价高；块小，去重细但清单和请求数暴涨。常见折中是 4–8 MB，并按文件类型调整。
实践建议
- 先判断规模：单文件小于几十 MB、并发不高的业务，整份存加版本表就够了，别为了"架构感"上分块；分块的复杂度主要在回收和一致性。
- 块大小取 4–8 MB，客户端先算摘要再传，服务端二次校验；清单里记录算法和块大小，给未来换算法留出兼容空间。
- 元数据、权限、版本指针放支持事务的数据库，内容放对象存储；两边不要跨系统做"分布式事务"，用"先写内容、再切指针、失败留孤儿"的顺序，让孤儿由回收兜底。
- 删除一律软删加延迟回收，至少留一个上传会话的最长存活时间；回收任务要有干跑模式和误删告警。
- 可观测性盯四个数：分片重传率、去重命中率、回收延迟、首字节 p99。去重率突然下降，往往不是代码坏了，而是块边界变了。
一句话总结：设计文件存储的难点不在存字节，而在让内容不可变、版本可回溯、引用可安全回收。