🔥 开篇
周五的傍晚，窗外的晚霞烧得正旺，但我没心思欣赏。因为运维胖哥刚刚在群里发了一张服务器磁盘报警的截图，那鲜红的92%看得我心惊肉跳。
“豆子！”胖哥直接杀到了我工位，“你们那个‘用户反馈’功能是不是有毒？我看 OSS 存储桶里的文件数量这周激增了 50%，但数据库里的反馈记录根本没几条啊！”
正说着，小汐端着奶茶凑了过来，一脸无辜又带着点心虚：“那个……我也发现了。很多用户上传了截图，结果没点‘提交’就关页面跑路了。那些图片就成了没人要的孤儿，一直赖在服务器上。”
“好家伙，”我扶额，“合着我们是在做‘网络垃圾回收站’啊。”
这其实是一个非常经典的工程问题：异步的文件上传与原子的业务提交不一致，导致了“孤儿资源（Orphan File）”。
🎯 场景还原
小汐打开了她的代码，指着那个上传组件：
“现在的逻辑是这样的：”
// 1. 用户选图，立即上传 const onUpload = async (file) => { const url = await uploadAPI(file); // 文件直接落盘 form.imageUrl = url; // 拿到 URL 填入表单 }; // 2. 用户可能... 永远不点击提交 // const onSubmit = async () => { ... }
“只要用户上传了图片，”小汐叹了气，“不管他最后提不提交表单，这文件都已经存下来了。现在的服务器里，估计有一半都是这种‘幽灵文件’。”
“如果是小文件，”小汐突然眼睛一亮，“其实我有招！我们能不能别这么急着上传？”
她快速敲了几行代码：
// 方案一：混合提交（FormData） async create(data, imageFile) { const formData = new FormData() // 把 JSON 数据转成 Blob 塞进去 formData.append('data', new Blob([JSON.stringify(data)], { type: 'application/json' })) if (imageFile) { // 前端先压缩，随表单一起提交 const webpFile = await convertImageToWebp(imageFile, 0.8) formData.append('imageFile', webpFile) } // 一次请求，搞定所有 return request({ url: '/reward', method: 'post', data: formData }) }
“你看，”小汐得意地说，“这样文件和表单是原子性的。要么都成功，要么都失败，根本不会有孤儿文件！”
🧠 思路分析
“小汐这招‘混合提交’，对付小头像、小截图确实够用。”
阿辰不知何时站在了我们身后，手里依旧是那个保温杯。他看了一眼代码，淡淡地说：“但如果用户要上传一个 500MB 的视频呢？或者弱网环境下上传 10 张高清图呢？你让用户点提交按钮后干等几十秒？体验会崩的。”
小汐愣了一下，默默收回了得意的笑容。
阿辰拉过白板，画了两个圈：
“对于大文件或通用场景，我们还是得走异步上传。但关键在于——‘上传 ≠ 生效’。”
他写下了一个词：两阶段提交。
“我们给文件设计个生命周期，就像办签证一样：”
- 临时态 (TEMP)：刚上传的文件，默认都是“临时访客”。给它发个有效期 24 小时的“临时居住证”。
- 转正 (USED)：只有当表单提交成功了，后端才会在事务里给这个文件盖个章，变成“永久居民”。
- 驱逐：过期还没转正的，直接由定时任务清理掉。
💻 代码实战
说干就干。我们决定采用方案二（两阶段提交）作为主方案，小汐的方案一（混合提交）作为轻量级场景的备选。
1. 数据库层改造：给文件加个身份
我们需要一张统一的sys_file表来管理所有文件。
CREATE TABLE `sys_file` ( `id` bigint NOT NULL, `url` varchar(500) NOT NULL, `status` tinyint DEFAULT 0, -- 0: TEMP(临时), 1: USED(已确认) `expire_time` datetime DEFAULT NULL, -- 临时文件过期时间 `create_time` datetime DEFAULT CURRENT_TIMESTAMP );
2. 后端逻辑：上传即“临时”
// 上传接口 public FileVO upload(MultipartFile file) { String url = ossService.upload(file); SysFile sysFile = new SysFile(); sysFile.setUrl(url); sysFile.setStatus(Status.TEMP); // 默认是临时态 sysFile.setExpireTime(LocalDateTime.now().plusHours(24)); // 24小时后过期 fileMapper.insert(sysFile); return new FileVO(sysFile.getId(), url); }
3. 业务提交：事务内“转正”
这是最关键的一步。只有业务成功了，文件才能活下来。
@Transactional(rollbackFor = Exception.class) public void submitFeedback(FeedbackForm form) { // 1. 保存业务数据 feedbackMapper.save(form); // 2. 【关键】将文件标记为“已使用” // 这一步必须在事务内，如果保存失败回滚，文件依然是 TEMP，会被后续清理 if (form.getFileId() != null) { fileMapper.updateStatus(form.getFileId(), Status.USED); } }
4. 流程图解
为了让逻辑更清晰，我画了个图：
用户后端API数据库定时任务什么都不做alt[用户提交表单][用户跑路]loop[每小时执行]1. 上传文件存入记录 (状态=TEMP, 过期=24h后)返回 fileId2. 提交表单 (带 fileId)开启事务保存业务数据更新文件状态 TEMP -> USED提交成功扫描 status=TEMP & expire_time < now删除物理文件删除文件记录用户后端API数据库定时任务
📊 效果验证
上线一周后。
胖哥再次丢过来一张截图，这次是存储桶的增长曲线。
“神了啊，”胖哥发了个大拇指表情，“这周文件增长率直接降了 40%，而且我看了下凌晨的清理日志，每天自动删除了几百个无效文件。那个报警红灯终于灭了。”
小汐看着监控大屏，长舒了一口气：“终于不用担心我的上传接口变成垃圾场了。”
💡 经验总结
这次治理，让我们明白了一个道理：资源必须要有生命周期管理。
核心要点：
- 场景分治：小文件（头像/凭证）可用FormData 混合提交，简单粗暴零孤儿；大文件必须走两阶段提交。
- 默认临时：所有异步上传默认都是“临时态”，设置 TTL（Time To Live）。
- 反向确认：业务提交成功是文件“转正”的唯一条件。
避坑指南：
- ❌坑1：直接返回最终 URL。建议返回
fileId，让后端有控制权。 - ❌坑2：依赖前端删除。永远不要相信前端的
onUnload或Cancel事件，网络一断什么都发不出来。 - ✅推荐：对于 OSS/S3，还可以配置 Bucket 的 Lifecycle 规则作为最后的兜底（比如
temp/目录下的文件 7 天自动物理删除）。