为什么发布不能只看一次 HTTP 响应
内容发布看似只是一次表单提交，真正落到工程系统里，却同时涉及编辑器状态、平台草稿、账号登录态、风险控制以及最终公开结果。尤其当平台在正式发布前加入滑块或验证码后，单纯把“接口返回成功”视为文章已发布，会带来最危险的一类错误：系统显示成功，平台上却只有草稿。
可靠的实现需要把保存内容、触发发布和确认公开拆成三个独立阶段。每个阶段都拥有明确的输入、输出和可恢复状态，任何一步中断都不应丢失已经完成的工作。
第一步：先建立不可丢失的草稿基线
在正式提交之前，系统应先调用平台提供的草稿能力，将标题、正文、摘要、封面和来源类型完整持久化。草稿成功后必须记录平台返回的草稿编号与编辑地址，而不是只保存一个本地布尔值。这样即使应用重启、网络中断或登录态变化，后续流程仍能回到同一篇内容继续处理。
草稿写入也需要幂等约束。任务重复执行时，应优先按平台草稿编号更新原记录；没有编号时，再以标题和短时间窗口做保守匹配。重复创建多个同名草稿虽然不等同于公开重复发布，但会污染创作中心，也会让后续状态核验失去可靠依据。
第二步：把验证码视为状态，而不是异常
滑块验证不是普通失败，它表示自动化已经完成可安全执行的部分，剩余步骤需要账号持有人在可见页面中操作。因此任务状态应进入“等待人工验证”，同时保留原账号会话、草稿地址和必要的发布设置。
系统不应伪造验证码令牌，也不应在后台反复点击发布。正确做法是把已经填好的页面交给用户，用户完成平台提供的验证控件后，再由状态探针确认文章是否进入审核或已经公开。这样的设计既尊重平台安全边界，也避免验证码出现时整条任务被误判为失败。
第三步：用公开结果完成最终确认
点击发布按钮只代表提交动作发生，不代表结果已经确定。最终状态需要通过创作中心列表或公开文章地址进行核验。系统应区分草稿、审核中、发布成功和平台拒绝，并保存可访问的文章链接。只有发现公开记录或平台明确的成功状态，才能对外报告“已发布”。
状态核验还应采用有上限的退避策略：短时间内逐步延长查询间隔，超过合理窗口后转为待确认，而不是无限轮询。对于审核型平台，任务可以保持审核中，并允许后台定期刷新；对于明确拒绝的内容，则记录平台原始原因，避免无意义重试。
工程上的三个关键约束
第一，提交边界只能有一个。在进入正式发布动作前可以安全重试数据准备，但越过提交边界后，任何自动重试都必须先查询平台结果，防止重复公开。
第二，账号会话必须隔离。每个授权账号使用独立且持久化的浏览器分区，人工验证页面也必须在同一分区打开，否则用户明明已经登录，任务仍会因为会话不一致而失败。
第三，状态要能跨进程恢复。草稿编号、验证地址、提交时间和平台设置不能只存在内存中。应用崩溃或升级后，任务仍应知道下一步是继续验证，而不是从头再发一次。
结语
面对带有安全验证的内容平台，可靠性并不来自更激进的自动化，而来自更清晰的边界。先保存完整草稿，再把验证作为可恢复状态交给用户，最后以平台公开结果作为唯一成功依据，才能让发布流程既稳定、可审计，又不会越过平台的安全机制。
