把多平台发布做成状态机后，如何避免重复投稿？

在多平台内容分发系统里，最危险的故障通常不是“发布失败”，而是请求已经到达平台，但本地因为超时、断网或回调丢失，把结果记成失败。任务一重试，同一篇文章就可能被重复提交。要解决这个问题，核心不是增加更多重试，而是把每个平台、每篇内容的发布过程建模为可核验的状态机。

一、先定义清晰的发布状态

一个最小可用的状态集合可以包括：draft（草稿）、ready（待发布）、submitting（提交中）、submitted（已提交）、under_review（审核中）、published（已发布）、rejected（被退回）和 uncertain（结果不确定）。

uncertain 很关键。网络超时只说明客户端没有拿到结果，不能证明平台没有收到请求。把这类情况直接写成 failed，会诱导系统再次发送；把它写成 uncertain，则要求执行器先读取平台侧记录，再决定是否重试。

状态转换也应受到约束。例如只有 ready 才能进入 submitting；submitted 之后只能通过平台查询或回调进入 under_review、published、rejected；published 不允许再次提交。这样可以避免前端按钮、后台任务和人工操作同时触发同一个发布动作。

二、用幂等键识别“同一次发布”

每次提交都应生成稳定的幂等键，可以由以下字段组成：

• 租户标识
• 平台标识
• 发布账号
• 内容版本哈希

同一个租户、平台、账号和内容版本只能存在一条有效发布记录。任务重跑时先查询这条记录，而不是直接调用平台接口。只有内容发生变化，内容版本哈希改变，系统才创建新的发布版本。

数据库还应增加唯一约束，让并发任务无法绕过业务层产生重复记录。应用层检查负责提供友好提示，数据库约束负责兜底。

三、队列不是业务真值

消息队列适合调度任务，但不适合作为发布结果的唯一来源。消息可能重复投递，也可能在消费者确认前执行成功。业务真值应该落在数据库中，包括当前状态、尝试次数、最近一次请求时间、平台返回摘要和外部内容编号。

执行器收到任务后，先锁定发布记录并检查状态：

1. 已经 published 或 under_review，直接结束；
2. 处于 submitting 且超过超时时间，进入 uncertain；
3. 只有 ready 或经核验可重试的记录，才允许发起请求；
4. 提交成功后先保存平台内容编号，再确认队列消息。

这种顺序可以把“至少一次投递”带来的重复风险控制在业务状态机内。

四、保存证据，而不只保存成功或失败

发布记录不能只有一个布尔值。至少要保存：提交时间、请求摘要、响应摘要、外部内容编号、审核状态、公开链接和最近一次核验时间。对于浏览器自动化，还应记录页面结果截图或可复核的状态文本；对于 API 发布，则保留请求关联 ID 和平台返回码。

证据的作用有两个：一是让运营人员知道内容到底走到了哪一步；二是在超时或回调缺失时，帮助系统判断是否已经提交。没有证据的“成功”不能用于自动化决策。

五、按文章和平台展示状态矩阵

运营界面适合用“文章 × 平台”的矩阵展示结果。每个单元格显示具体平台名称、发布账号、内容版本、当前状态、外部编号和公开链接。这样可以直接看出哪些平台已经发布、哪些仍在审核、哪些需要修改，也能阻止用户误点造成重复投稿。

批量发布时，一个平台失败不应回滚其他平台。每个平台是一条独立状态记录，系统汇总为部分成功，并给出下一步动作。

六、重试前必须先核验

安全的重试规则可以概括为：只有在确认平台没有接收过该内容时才重试。对于支持查询接口的平台，按外部编号或时间窗口查询；对于只能人工操作的平台，进入需人工核验状态，不能让后台任务盲目重复点击。

自动化发布的价值，不是把点击速度变快，而是让每一次状态变化都有条件、有证据、可恢复。状态机、幂等键、持久记录和平台回查配合使用，才能让多平台分发从“脚本批量操作”变成可靠的工程系统。