重试、冲突和版本：一次文件上传的三个边界

先确认内容是否完整

大文件上传无法假设一次请求就能成功。网络可能中断，分片可能缺失，客户端也可能重新提交已经发送过的内容。

CloudSync 将上传会话和分片状态持久化，结合 SHA-256 分片与整文件校验、缺失分片查询，保留中断后继续上传的依据。完整性校验回答的是：收到的内容是否与预期一致。

再确认重试会不会重复生效

内容完整之后，还有一个独立问题：客户端没有收到提交结果时，再次提交是否会创建重复版本？

幂等提交关注同一个提交的重试是否安全。它与分片校验不同：校验正确的内容仍然可能被重复创建，因而需要单独处理提交语义。

用版本表达并发修改

当多个设备修改同一文件时，后到的请求不一定基于最新内容。CloudSync 将逻辑文件节点与不可变内容版本分开，使用 baseVersionId 和 PostgreSQL 事务内条件更新实现乐观并发控制。

过期提交发生冲突时应被拒绝，而不是静默覆盖。恢复历史版本也通过新增版本表达，保留已经发生过的修改。这里不包含自动内容合并或实时协同编辑。

• 文件节点描述同一个逻辑文件。
• 不可变版本保存每次提交的内容。
• 条件更新检查提交所依据的版本，显式暴露冲突。

最后处理跨存储的失败

元数据在 PostgreSQL，对象内容在 MinIO，两者不能共享同一个本地数据库事务。因此对象写入成功，并不意味着元数据提交一定成功。

项目采用对象暂存、完整性校验与元数据事务提交相结合的分阶段写入，并通过孤儿对象延迟清理、版本引用复核和失败恢复降低不一致风险。

这是为失败准备收尾机制，不能描述为数据库和对象存储之间的强原子事务。上传可靠性来自这些边界的配合，而不是某个单独的技术名词。