嘿，这个场景我在项目里碰过好多次了，直接给你最落地的结论：必须把产品信息提交和文件上传拆分为独立接口，而且移动端绝对不能一次性上传所有文件——这两个决策是解决你当前问题的核心，下面展开说具体原因和实操方案：

一、为什么一定要拆分接口？ #

• 职责划清才好维护：产品信息是业务数据（比如名称、分类、描述），文件上传是纯存储操作，拆分开后，以后不管是改业务规则还是换存储服务商，各自改各自的接口就行，不会互相牵连。
• 容错性拉满：如果产品信息校验没通过（比如必填项漏了），那压根不用浪费带宽传文件；反过来，要是某个文件上传失败，也不会把已经填好的产品信息搞丢——用户可以先存产品信息当草稿，后续再补传文件，体验好太多。
• 适配多端差异：Web端能拖批量文件，但移动端网络不稳定，拆分后可以灵活调整流程，比如先拿产品ID，再慢慢传文件，不用卡成狗。

二、移动端文件上传：分片+分批，拒绝一次性上传 #

移动端网络波动大、带宽有限，一次性传所有文件简直是灾难——只要一个文件断了，全部得重传，用户绝对会炸毛。推荐这么干：

1. 先拿产品唯一标识：用户填完产品信息后，调用 POST /products/draft 接口提交基本信息，后端生成一个productId返回给前端，同时把产品信息存进数据库，标记成「待上传文件」状态。
2. 大文件分片传：对单个超过10MB的文件拆成分片（比如每片5MB），调用 PUT /products/{productId}/files/{fileKey}/parts 接口传分片，后端直接把分片请求转发给S3的分片上传API，不用自己存分片（省服务器资源）。所有分片传完后，再调用 POST /products/{productId}/files/{fileKey}/complete 合并分片。
3. 多文件逐个/少量并行传：移动端别同时传一堆文件，最多并行传2个，按顺序逐个处理，每个文件传完后，后端把文件元数据（文件名、大小、S3地址）和productId关联存进数据库。
4. 断点续传不能少：前端要记录每个文件已上传的分片位置，下次打开APP时，先跟后端同步状态，从断点继续传，不用从头再来。

三、后端的配套处理细节 #

• 直接对接S3分片API：别自己搞分片存储，SpringBoot后端就做个代理，把分片上传请求转交给S3的CreateMultipartUpload、UploadPart、CompleteMultipartUpload接口，省心又省资源。
• 状态管理要细致：数据库里要存产品的整体状态（草稿、部分文件完成、全部完成），还要存每个文件的状态（待上传、上传中、已完成、失败），前端才能实时展示进度条。
• 幂等性要保障：每个上传请求带上唯一的fileKey和分片编号，后端处理时先查有没有已经处理过这个分片，避免重复上传浪费S3存储空间。
• 超时重试要合理：移动端上传时设置30秒左右的超时，失败后自动重试2-3次，还是失败就标记为上传失败，提示用户手动重试。

四、Web端的适配方案 #

Web端网络相对稳定，可以搞批量上传，但同样用拆分后的接口：

• 先提交产品信息拿productId，然后批量选文件，并行传3-5个文件（别太多，避免占满带宽），大文件同样分片传。
• 实时展示每个文件的上传进度，全部传完后调用 POST /products/{productId}/complete 接口，把产品状态改成「已完成」。

五、异常场景怎么处理？ #

• 产品信息提交失败：前端直接提示用户改信息，不用进文件上传流程。
• 单个文件上传失败：只重传这个文件就行，不影响其他已传文件和产品信息。
• 后端宕机：移动端本地保存已上传的文件状态，下次启动时先同步后端状态，接着传没完成的部分。

内容的提问来源于stack exchange，提问作者Sharique