临时上传需要保留规则

“临时上传” 是一个带作业的承诺。

听起来很清楚：用户上传文件，系统会短暂使用，然后就消失。很好。但系统并不是单一地点。文件可能会经过浏览器、边缘缓存、应用服务器、对象存储、队列、模型运行时、重试工作器、缩略图生成器、CDN、支持工具以及日志。

如果“临时”只意味着主数据库里临时，那么这个承诺就太薄了。用户关心的是文件本身，而不是你那张架构图。

临时上传的保留策略应覆盖：原始文件、缩放后的版本、遮罩、预览、缩略图、重试载荷、失败任务、输出交付的 URL、缓存以及日志。它需要说明：会创建什么、为什么要创建、会存活多久，以及之后还会留下什么。

这并不意味着每个临时文件都必须立刻消失。有些系统需要短期的交付链接。有些需要较短的重试窗口。有些需要与内容无关的记录，用于计费或防止滥用。关键在于：保留行为是有意设计的，并且被清楚解释。

临时上传也需要失败处理。如果生成在中途崩溃，上传还会保留吗？如果工作器超时，源图像会被保留用于调试吗？如果用户取消了，部分输出会怎样处理？失败路径往往是“临时承诺”变成“意外存储”的地方。

最稳妥的做法是减少副本。副本越少，保留规则越少，清理任务也越少。一个短生命周期的“生成会话”（接收内容、处理、返回结果、并丢弃敏感材料）比把上传变体像彩纸一样到处散落的产品更容易推理和管理。

“临时”不是你在界面上随便贴的词。它是一个工程层面的声明。

延伸阅读：如何在不使用云端术语的情况下理解“短暂计算”，Unexposed 数据存储，以及 OpenAI 的API 数据控制。