她问我：服务器快被垃圾文件塞爆了，怎么破？我说：给文件办个“临时居住证”-洪萨配资

🔥 开篇

周五的傍晚，窗外的晚霞烧得正旺，但我没心思欣赏。因为运维胖哥刚刚在群里发了一张服务器磁盘报警的截图，那鲜红的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数据库定时任务