基于Supabase Storage设计原子化商品+媒体上传流程方案咨询

一、最简洁可维护的架构：临时存储+两步确认+幂等校验 #

针对你的场景，最简洁且易维护的方案是基于临时存储+草稿机制的两步提交模式，核心是把所有前置操作放在临时状态，只有最终确认后才固化正式数据：

• 第一步：客户端发起创建商品请求时，后端生成一个唯一UUID作为临时标识，在PostgreSQL中插入一条商品草稿记录（状态标记为pending），同时基于这个UUID生成Supabase Storage的临时上传路径（比如temp/{uuid}/），返回该路径的预签名上传URL给客户端。
• 第二步：客户端完成文件直传后，调用确认接口。此时后端依次执行：
  1. 校验草稿记录存在且状态为pending，同时通过Supabase Storage API验证文件已完整上传（检查文件存在、大小匹配）
  2. 调用Supabase的文件移动接口，将临时路径的文件原子性迁移到正式存储路径（比如products/{product_id}/，这里可以用草稿的ID作为正式商品ID）
  3. 将草稿记录转为正式商品记录（更新状态为active，关联正式文件路径），或者直接插入正式商品记录并删除草稿
• 异常处理：如果客户端上传失败，草稿记录会被定时任务清理（比如24小时后删除pending状态的草稿，同时调用Supabase API删除对应临时路径的文件）；如果确认过程中出现失败（比如文件移动失败），则直接删除草稿和临时文件，返回失败给客户端。

这个方案的优势：

• 不需要显式回滚正式商品，因为正式数据只在最后一步生成
• Supabase的文件移动操作是原子性的，避免了临时存储的复杂管理
• 天然支持幂等：确认接口用草稿UUID作为幂等键，重复调用不会产生脏数据

二、生产系统的通用处理模式 #

在跨存储与数据库的原子性场景中，生产系统通常采用以下几种成熟模式：

• 临时存储+最终提交：这是最主流的方案，本质是将“提交”作为原子性触发点，所有前置操作都是临时状态。比如电商平台的商品草稿、内容平台的素材临时上传，均采用此逻辑，既保证了用户体验的原子感，又降低了跨系统事务的复杂度。
• 后台异步清理机制：无论哪种方案，都会产生孤立的临时文件或草稿。生产中会通过定时任务（比如用PostgreSQL的pg_cron插件、Node.js的定时任务库）定期清理：查询数据库中超过阈值（如24小时）的pending状态记录，然后调用Supabase Storage API删除对应路径的文件。
• 幂等性与重试机制：所有关键接口（创建草稿、确认提交）都实现幂等，用唯一请求ID或草稿UUID作为幂等键，避免客户端重复操作导致的重复数据。同时，对确认过程中的可重试失败（如网络波动导致的文件移动超时），会自动重试2-3次，减少用户侧的失败感知。
• 补偿事务模式（可选）：如果业务要求必须先生成正式商品ID，可采用“创建商品+上传+补偿删除”的模式：
  1. 创建正式商品记录，状态标记为awaiting_media
  2. 返回预签名URL给客户端上传文件
  3. 上传成功后更新商品状态为active；若上传失败或超时未上传，通过定时任务删除该商品记录及已上传的文件
     这种模式需要严格的超时清理逻辑，确保孤立数据被及时回收。

内容的提问来源于stack exchange，提问作者Blue moon 215