发布重试要先考虑一致性而不是成功率

很多内容系统都会遇到发布动作失败重试的问题，比如文章入库成功了，但缓存没刷、索引没建，用户看到的状态就不完整。这时候最直觉的做法是“再点一次发布”，但如果底层没有幂等设计，重试本身会把问题放大。

我更在意的是把发布流程拆成几个可确认状态：草稿、发布中、已发布、发布失败。只要状态流转清楚，重试就能知道自己是在补哪一步，而不是简单把整套写入再跑一遍。

在 Sequelize 这一层，比较值得提前准备的是：

• 唯一键和业务幂等键，避免重复插入。
• 状态字段和更新时间，方便观察是否卡住。
• 对外副作用和数据库写入分层处理，不要混在一个模糊动作里。

重试的意义不是“多试几次”，而是让失败恢复仍然可控。把一致性放在前面，成功率反而更容易稳定下来。

为什么这类问题总会在线上阶段突然变贵

围绕「发布重试要先考虑一致性而不是成功率」这类判断，最容易被低估的地方，是大家前期总把它当成 ORM 写法偏好，而不是数据契约和查询边界。数据量小、调用方少的时候，字段命名、关联深度、分页方式、迁移顺序都像只是风格问题；一旦接口被更多页面复用，筛选、排序、统计和审计需求一起叠上来，之前没收住的边界就会同时在性能、排障和协作成本上爆出来。

落地时我会先卡住的检查项

• 先把输入 DTO、模型字段和最终 SQL 这三层对应关系看清，避免“接口语义已经变了，ORM 代码却还在偷偷兜底”。
• 把统计、明细、写操作和回滚路径拆开看，别让一个方便的查询顺手背上太多职责。
• 一旦这篇文章讨论的点已经影响到索引、事务或迁移顺序，就说明它不是微调，而是该补正式约束了。