题目重点：合并两类云文件题的存储核心，讲清元数据、直传、版本、变更日志与冲突恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练范围是用户个人文件/照片在多设备间上传、下载、删除和同步，不包含实时多人协作文档编辑；若原题要求共享 ACL 或编辑冲突合并，需另签。
- 元数据记录逻辑对象与版本，媒体 bytes 放对象存储；设备可以离线后重连。题目未明确用户数、平均照片大小、RPO/RTO 或跨区域要求。
解题路线
- 将 metadata 和 blob 分开：metadata DB 存 owner、fileId、path/album、version、contentHash、blobKey、size、state、updatedAt；bytes 由客户端分片直传对象存储，服务端只签上传会话/权限。
- 上传先创建 pending 版本和幂等 uploadId；客户端分片上传并校验 checksum；对象完成后在同一元数据事务中发布新版本及同步变更事件，失败会话定期清理。
- 设备以游标拉取 per-user change log（新增、更新、删除 tombstone）；重复拉取可按 `(fileId,version)` 幂等应用。离线两端同时修改时，用版本条件写拒绝静默覆盖，并提供冲突副本或明确合并规则。
- 下载先读 metadata 授权与当前版本，再返回短期读取授权；热门缩略图/小图可缓存，原始媒体和冷版本留在对象存储/分层存储；缓存键须含版本并在删除/撤权时失效。
- 照片变体增加缩略图、EXIF/位置隐私、图库索引与跨设备缩略图生成，Dropbox 通用文件变体关注目录移动、同名路径与大文件版本；这些是不同功能层，底层 blob+metadata+changelog 一致。
- 按上传/下载 QPS、对象大小分布、版本保留天数、变更日志保留期和离线设备滞后度估容量，不从题目虚构固定数字。
手动走一遍
手机 A 离线上传 photo X v2，平板 B 也离线修改 X 基于 v1。A 先完成 v2；B 重连带 expectedVersion=v1 写入时应收到版本冲突，而不是覆盖 A 的 v2。B 可保留冲突副本，随后两端通过 change log 游标收敛到相同可见版本集合。
规模与取舍
元数据按 fileId/version 索引的单次读写约 O(log F)（依存储实现），同步读取 O(changes since cursor)；媒体传输成本与 bytes 大小成正比。整体存储随当前对象、保留版本、缩略图及变更日志增长，不能只按用户文件数估算。
易错点与追问
容易失分的边界
- 把大照片 bytes 存进关系型 DB 主行，使元数据查询与媒体吞吐耦合。
- 对象上传成功即向所有设备宣称可见，元数据未提交产生孤儿/半成品。
- 用客户端时间戳做唯一冲突裁决，设备时钟漂移导致静默覆盖。
- 删除只清 metadata，不处理下载授权缓存、缩略图和延迟清理。
- 把 Dropbox/Photos 的同步共享核心重复写成两篇同题文章。
继续深挖
- 如何支持共享相册撤权后已缓存设备的访问边界？
- 跨区域容灾下元数据与对象复制顺序怎样保证读可用？
- 百万个离线设备很久不更新时如何压缩 change log 但保留重同步能力？
- 同一内容重复上传要不要按 hash 去重，隐私和跨用户侧信道风险是什么？
