第一版接口与元数据模型

第一版长什么样

第一版文件上传系统通常长这样：

浏览器 -> 业务服务 -> 本地磁盘
                 -> 数据库记录

它的优点很直接：实现快、依赖少、调试简单。用户选择文件，服务端接收 multipart 请求，把文件写入指定目录，再保存一条元数据记录。

三个接口

基础上传至少需要三个接口：

注意下载接口：不要把物理路径直接丢给用户。用户只应该拿到 file_id，由服务端决定如何访问。这是后面接对象存储、CDN 签名 URL 的伏笔。

元数据表

文件系统真正被业务依赖的，不是「磁盘上的文件」，而是元数据：

这张表回答的是业务问题：谁拥有这个文件、当前是否可访问、是否通过审核、生命周期到什么时候。

元数据 vs 文件内容

把「元数据」和「二进制内容」分开，是文件系统最重要的心智模型之一：

• 二进制内容：交给存储（本机磁盘 → 对象存储），体积大、要备份、要 CDN。
• 元数据：业务事实来源（归属、状态、权限、审计），交给数据库。

后面章节会反复用到这个分离：对象存储只认识「一个对象」，不认识「这个对象属于谁、能不能下载」——这些只有元数据表知道。

写入的补偿

写文件和写数据库要有一致性意识，避免：

• 只有文件没有记录：找不到元数据，文件变成孤儿。
• 只有记录没有文件：元数据存在但内容丢了。

第一版不追求分布式事务，但要留出补偿思路：先写元数据（状态 uploading），文件写成功后更新状态；后台定时清理「状态卡住」的残留。

下一节看上传前的基础校验——别让第一版就埋下安全地雷。

上一章节

基础上传

下一章节

上传前的基础校验