这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
第一版的上限与演进边界
这一版不是终点
基础上传能让产品跑起来，但它的问题会在规模增长后逐一暴露。提前看清上限，才能避免「等到出事故再重构」。
四个明显的上限
1. 业务服务器变成存储服务器
文件存在本机磁盘。一旦扩容到多台机器，文件可能只存在其中一台——请求打到另一台就找不到文件。这就是「有状态的应用服务器」：不能随意伸缩，重启、迁移、滚动发布都要小心。
2. 上传和下载都占业务带宽
大文件上传和下载都经过业务服务。一个 600MB 视频下载，就会占用大量带宽和 CPU，拖慢同一台机器上的普通 API。业务服务的定位是「处理业务逻辑」，不是「搬运大流量」。
3. 单次上传不可恢复
一次网络抖动，整个文件重来。小文件可以忍，大文件就是灾难——这正是客服工单里「87% 后失败重传三次」的根源。
4. 没有治理能力
谁传的、能不能下载、是否审核、删了能不能追——这些第一版都没有。等出事再补，往往已经造成损失。
为演进留好边界
第一版的设计目标不是「完美」，而是为后续演进留出接口：
- 文件 ID 与物理路径解耦：业务只认
file_id，换存储不用改接口。 - 元数据表保留
status：支持异步处理、审核状态流转。 - 下载不暴露本地路径：为对象存储签名 URL 留伏笔。
- 上传大小限制明确：超过限制的文件，明确提示走分片方案。
演进不是推翻重来
后续每一章都是在现有边界上「加一层能力」，而不是推翻第一版：
基础上传 ──▶ 分片上传（传输层加固）
──▶ 断点续传（状态层加固）
──▶ 对象存储（存储层替换，接口不变）
──▶ CDN（分发层加速）
──▶ 安全审计（治理层补齐）正因为第一版把「文件 ID / 元数据 / 存储路径」拆开，后面换对象存储时，业务接口几乎不用动。
下一章进入分片上传，解决「大文件 + 弱网络」这个最直观的痛点。