这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
文件上传是一条系统链路
一个客服工单
我第一次认真重构文件上传系统，是因为一个很普通的客服工单：
用户上传 600MB 的培训视频，进度到 87% 后失败，重新上传又失败了三次。
当时的系统只有一个 /upload 接口：浏览器把文件传给业务服务，业务服务写到本地磁盘，再把路径存进数据库。头像、合同、图片、视频都走同一条链路。
小文件看起来没什么问题，但文件一变大，问题集中爆发：
- 上传时间长，网络抖动一次就要从头开始。
- 多台业务服务器各自存本地文件，扩容后找不到文件。
- 下载都打到业务服务器，带宽和 CPU 被静态文件拖垮。
- 用户上传可执行文件、脚本和违规图片，系统没有任何拦截。
- 文件被谁上传、谁下载、谁删除，事后追不清。
这时你会发现：文件上传不是一个功能点，而是一条完整的系统链路。
文件系统的五个问题
一个生产级文件上传系统，至少要回答五类问题：
| 问题 | 关心什么 | 对应章节 |
|---|---|---|
| 传输 | 如何稳定传上来？失败能否恢复？ | 分片上传、断点续传 |
| 存储 | 文件存哪里？元数据与内容如何分离？ | 对象存储 |
| 处理 | 压缩、转码、病毒扫描放哪做？ | 安全审计 |
| 分发 | 下载如何低延迟、不压垮源站？ | CDN 加速 |
| 治理 | 权限、审计、合规、生命周期与成本？ | 安全审计、完整系统 |
本课程的主线，就是沿着这五类问题逐步演进：从基础上传 → 分片与断点续传 → 对象存储直传 → CDN 分发 → 安全审计 → 完整平台。
为什么不能只当成一个接口
只看「接口返回 200」，会漏掉整个系统的真实状态。文件系统真正的复杂度，都发生在你看不见的地方：
- 上传接口成功，不代表文件可用（可能还在扫描、合并）。
- 文件可访问，不代表有权限的人才能访问（可能 URL 被猜中）。
- 存储有容量，不代表成本可控（可能临时分片无限堆积）。
- 功能上线，不代表事故可追溯（可能没有审计日志）。
一句话：文件系统是「传输 + 存储 + 处理 + 分发 + 治理」的组合体，任何一个环节缺失，都会在文件变大、用户变多后变成事故。
下一节我们明确这套系统要满足哪些目标，以及用哪些指标来衡量它是否健康。
发现内容有问题？
告诉我们哪里需要改进。