开始 - 文件上传概述

我第一次认真重构文件上传系统，是因为一个很普通的客服工单：

用户上传 600MB 的培训视频，进度到 87% 后失败，重新上传又失败了三次。

当时的系统只有一个 /upload 接口。浏览器把文件传给业务服务，业务服务写到本地磁盘，再把文件路径存进数据库。头像、合同、图片、视频都走同一条链路。小文件看起来没有问题，但文件一变大，问题就集中爆发：

• 上传时间长，网络抖动一次就要从头开始。
• 多台业务服务器各自存本地文件，扩容后找不到文件。
• 下载都打到业务服务器，带宽和 CPU 被静态文件拖垮。
• 用户上传可执行文件、脚本文件和违规图片，系统没有任何拦截。
• 文件被谁上传、谁下载、谁删除，事后追不清。

这时你会发现，文件上传不是一个功能点，而是一条完整的系统链路。

系统边界

一个生产级文件上传系统至少要回答五类问题：

1. 传输：客户端如何稳定地把文件传上来？失败后能不能恢复？
2. 存储：文件存在哪里？元数据和二进制内容如何分离？
3. 处理：图片压缩、视频转码、病毒扫描这类耗时任务放在哪里做？
4. 分发：用户下载或预览文件时，如何降低延迟和源站压力？
5. 治理：权限、审计、合规、生命周期和成本如何持续管理？

本课程的主线就是围绕这五类问题逐步演进。

核心指标

设计文件系统时，不要只看接口是否返回 200。更关键的指标是：

• 上传成功率：尤其是大文件、移动网络、跨地域上传场景。
• 首字节时间：用户打开图片、合同、视频封面时多久能看到内容。
• 源站回源率：CDN 或缓存是否真的降低了业务服务压力。
• 存储成本：热文件、冷文件、临时文件是否有生命周期策略。
• 安全命中率与误拦截率：既要拦住风险文件，也不能频繁误伤正常用户。

这些指标会决定架构取舍。例如，分片上传会让客户端和服务端状态更复杂，但它显著提高大文件上传成功率；CDN 会带来缓存一致性问题，但它能把下载流量从业务服务中移走。

演进路线

我们先从最简单的基础上传开始，确认最小链路能跑通。随后引入分片上传和断点续传，解决大文件与弱网络问题。接着把文件迁移到对象存储，让业务服务只负责鉴权、签名和元数据。最后接入 CDN 与安全审计，形成可上线、可运维、可治理的完整文件平台。

读完这门课，你应该能画出一套文件上传系统的核心架构图，并能解释每个模块为什么出现、解决了什么问题、引入了什么新复杂度。