第一版的上限与演进边界

这一版不是终点

基础上传能让产品跑起来，但它的问题会在规模增长后逐一暴露。提前看清上限，才能避免「等到出事故再重构」。

四个明显的上限

1. 业务服务器变成存储服务器

文件存在本机磁盘。一旦扩容到多台机器，文件可能只存在其中一台——请求打到另一台就找不到文件。这就是「有状态的应用服务器」：不能随意伸缩，重启、迁移、滚动发布都要小心。

2. 上传和下载都占业务带宽

大文件上传和下载都经过业务服务。一个 600MB 视频下载，就会占用大量带宽和 CPU，拖慢同一台机器上的普通 API。业务服务的定位是「处理业务逻辑」，不是「搬运大流量」。

3. 单次上传不可恢复

一次网络抖动，整个文件重来。小文件可以忍，大文件就是灾难——这正是客服工单里「87% 后失败重传三次」的根源。

4. 没有治理能力

谁传的、能不能下载、是否审核、删了能不能追——这些第一版都没有。等出事再补，往往已经造成损失。

为演进留好边界

第一版的设计目标不是「完美」，而是为后续演进留出接口：

• 文件 ID 与物理路径解耦：业务只认 file_id，换存储不用改接口。
• 元数据表保留 status：支持异步处理、审核状态流转。
• 下载不暴露本地路径：为对象存储签名 URL 留伏笔。
• 上传大小限制明确：超过限制的文件，明确提示走分片方案。

演进不是推翻重来

后续每一章都是在现有边界上「加一层能力」，而不是推翻第一版：

基础上传 ──▶ 分片上传（传输层加固）
          ──▶ 断点续传（状态层加固）
          ──▶ 对象存储（存储层替换，接口不变）
          ──▶ CDN（分发层加速）
          ──▶ 安全审计（治理层补齐）

正因为第一版把「文件 ID / 元数据 / 存储路径」拆开，后面换对象存储时，业务接口几乎不用动。

下一章进入分片上传，解决「大文件 + 弱网络」这个最直观的痛点。

上一章节

上传前的基础校验

下一章节

分片上传