文件上传通常是服务端项目里最容易“先糊上去，后面再补”的功能，但它其实牵涉到磁盘、网络、资源访问、内容校验和安全边界。Node.js 在这类场景里很有优势，但也很容易因为处理不当留下隐患。这一篇会把文件处理主线系统讲清楚。
为什么上传功能不只是“接收一个文件”？
因为真正的上传链路通常至少包含这些步骤：
- 接收文件流；
- 校验类型、大小和来源；
- 决定存储策略；
- 记录元信息；
- 为后续访问生成稳定引用；
- 必要时做异步处理，比如压缩、缩略图、审核。
也就是说，上传不是一个点，而是一条链路。
这条链路里的每一个节点其实都可能带来完全不同的问题。接收阶段要考虑流式处理和大小限制，校验阶段要考虑类型伪装和非法内容，存储阶段要考虑路径、权限和成本，访问阶段又要考虑公开性、缓存和过期策略。只要少想一层，后面就很容易变成临时补丁堆出来的功能。
本地磁盘、对象存储和 CDN 分别在解决什么？
本地磁盘最直观，适合简单场景和本机开发，但一旦涉及多实例部署、弹性扩容和更大规模资源管理，它通常就会暴露限制。
对象存储则更适合承担长期文件资源管理职责，因为它更容易和多实例服务、外链访问、权限控制和生命周期管理协作。
CDN 的角色又不同。它更偏向“让静态资源更快、更稳定地被访问到”，而不是负责源文件本身的业务管理。
所以，这三者不是互相替代，而是经常处在同一条资源链路的不同位置。
判断该用哪一种，最好不要只看“现在能不能快速跑通”，而要看这个资源未来会不会遇到这些问题：
- 是否需要多机器共享；
- 是否需要外链访问；
- 是否需要权限控制或有效期；
- 是否会出现大量热点访问；
- 是否要做生命周期管理和冷存储。
一旦这些需求开始出现，本地磁盘方案通常就会越来越吃力。
图片和静态资源为什么经常成为系统问题？
因为图片和文件资源不仅体积大、数量多，还会牵涉到：
- 压缩和格式处理；
- 访问权限；
- 缓存策略；
- 地址管理；
- 生命周期清理。
也就是说，资源处理既有存储问题，也有访问问题，还有成本问题。只要规模一上来，这就不再是“顺手保存一下”的小功能。
尤其是图片处理，经常还会附带额外的异步流程，比如：
- 生成不同尺寸；
- 做格式转换；
- 补充水印或压缩；
- 触发内容审核；
- 回写元信息和可访问地址。
所以，很多更稳妥的系统不会在上传请求里同步做完所有事情，而是先把原始文件安全落地，再把耗时处理交给后台任务。
上传功能里最容易忽略哪些安全边界？
最常见的风险往往包括：
- 文件类型伪装；
- 路径穿越；
- 超大文件攻击；
- 随意公开访问本不该公开的资源；
- 服务端盲目信任客户端传来的文件信息。
这也是为什么上传功能看起来简单，却特别值得认真设计。因为一旦边界没处理好，它既会带来安全问题，也会带来资源和成本问题。
除此之外，还有几个工程上很现实的边界也值得提前想清楚：
- 上传失败后，临时文件怎么清理；
- 数据库记录成功但文件落盘失败时如何补偿；
- 文件被删除后，缓存和 CDN 何时失效；
- 同一个资源是否允许重复上传、重复引用。
这些问题不一定在第一版就做得很完整，但至少要知道它们存在。因为资源类功能一旦进生产，补救往往比一开始多想一步更贵。
一个更稳妥的上传链路应该长什么样？
如果把这一类功能压缩成一个最小但靠谱的闭环，通常至少要做到：
- 接收阶段限制文件大小和基础来源；
- 校验阶段不要只信扩展名，必要时做内容类型判断；
- 存储阶段明确路径、命名规则和权限策略；
- 访问阶段区分公开资源与受控资源；
- 处理阶段把耗时任务从主请求中拆出来；
- 清理阶段对失败、替换和删除都有对应回收策略。
做到这里，上传功能才更像是一个可持续演进的资源系统，而不是一段“先把文件收下来再说”的临时逻辑。
总结
这一篇我们把文件上传和静态资源处理从“业务小功能”提升成了更完整的系统链路：接收、校验、存储、访问和安全控制缺一不可。本地磁盘、对象存储和 CDN 分别承担不同职责，而图片和资源处理则往往需要从一开始就带着规模意识来设计。
下一篇我们会继续进入更偏系统设计的话题，也就是缓存、队列和后台任务。