## 两种方案
大文件上传的工程问题集中在两点：网络中断要不要从头再来、服务器要等多久。直传方案是一次 HTTP 请求传完整文件，实现简单、服务器资源占用低；分片上传把文件切成小块逐片传输，每片独立成功失败，断了从断点续传，代价是前后端实现复杂、服务端要管理分片合并。两条路各有明确适用面，选错了要么体验差，要么白白增加复杂度。
## 超时链路的联动
选择之前先看清超时链：浏览器到 Web 服务器的空闲超时、反向代理的读写超时、应用容器的执行超时，三层里最短的说了算。直传一个两 G 的文件，慢速网络下传输半小时，任何一层超时短于它都会中途断开——表现正是"传到一半失败"。调超时要整条链路一起调，只改 Nginx 不改应用等于没改；但超时无脑拉长也有代价：连接与内存被长期占用，异常请求得不到及时释放，并发一高资源先耗尽。
## 各自适用面
直传适合小文件与网络可控的内网场景：几十兆以内、办公网络稳定，简单方案最稳。分片适合面向公网的用户上传：视频、安装包、批量素材，网络不可控，用户等不起从头再来。分片的粒度也有讲究：片太小请求数爆炸，片太大单片重传成本高，常见取几兆到几十兆一片。对象存储的引入会改变格局：直传对象存储把流量绕开应用服务器，配合其自带分片能力，是省事与体验的折中点。
## 选择建议
按用户与文件规模定：内部系统小文件，直传加合理超时；公网产品大文件，分片或对象存储直传。无论哪条路，前端配上进度展示与失败重试按钮，体验比底层方案差异更影响感受。顺云云服务器的带宽资源按上传业务量规划，公网大文件高频上传的业务提前评估带宽成本与峰值，别让上传把业务流量挤死。