Flux Art消息确认不是图片完成证明
用 RabbitMQ 为 Flux Art 接入服务分派业务任务时，消息已确认只说明消息系统接受了相应确认，不代表远端生成已经完成。若消费者在只把任务放进内存后就确认，进程退出可能使工作没有持久接续位置。反过来，一直不确认直到长时间生成完成，也可能带来资源占用和重复投递风险。本文讨论接入方自建消息系统，先明确谁在每一步负责恢复任务，再设计确认时点。
生产者确认与消费者确认各管一段
RabbitMQ 的 publisher confirms 用于发布者与消息代理之间的确认，consumer acknowledgements 用于消费者处理投递后的确认。二者不能互相替代：发布成功不能证明消费者完成，消费者确认也不等于外部服务结果成功。运维台账应分别记录发布标识、业务任务键、消费接管状态和远端任务标识。不要用一个布尔值同时表示发送成功、处理成功与图片验收通过，这会让故障恢复失去依据。
自动确认适不适合由业务风险决定
自动确认模式会较早把消息视为已投递，消费者在真正处理前退出时存在丢失工作的风险。需要处理完成或可靠接管后再确认的工作，应评估手动确认，并配置适合本地处理能力的未确认消息规模。这里不是要求所有队列都采用同一设置；短任务、长任务及可恢复后台工作各有不同边界。先写清楚失败后由哪份持久记录恢复，再讨论确认和吞吐量，不要只凭消费速度选模式。
| 交接位置 | 应保存的证据 | 主要风险 |
|---|---|---|
| 发布到代理 | 发布确认与业务键 | 误当消费者完成 |
| 收到消息 | 投递上下文与确认模式 | 提前确认后丢工作 |
| 写入任务库 | 已提交的接管记录 | 只有内存没有恢复入口 |
| 调用远端 | 请求记录与受理状态 | 未知结果被盲目补发 |
| 发送消费确认 | 正确通道和投递标识 | 误确认未处理消息 |
| 重新投递 | 原业务键及接管状态 | 再次创建同一业务工作 |
持久接管必须真的能在重启后恢复
如果消费者先把工作可靠写入自己的任务库，再确认消息，接管记录应包含业务唯一键、有效参数、状态和可重试依据，并且有实际运行的扫描恢复机制。仅写一条日志、保存内存对象或把异步函数启动起来，都不等于持久接管。数据库提交和消息确认不是天然的一次原子操作；在两者之间崩溃时仍可能重新投递，所以接管动作必须能识别已有记录而不重复创建外部任务。
假设示例：提交台账后、确认之前退出
假设工作进程已经提交本地接管记录，但在发送消费者确认前退出。消息可能被重新投递，新的消费者应通过同一业务键找到已存在的处理记录并接续，而不是无条件再次创建生成任务。这不是实测客户队列，也不是真实平台故障。隔离测试可以在指定位置终止测试进程，核对重复投递后台账数量和外部调用替身的计数，证明恢复路径确实存在。
远端受理后状态未知要先对账
网络中断可能发生在外部请求已经被接收、但本地尚未保存完整响应之间。重新收到消息不能据此认定上次没有执行。使用已有请求记录、对应接口支持的查询机制及业务关联信息核对结果，未知状态保持待处理。消费者确认策略不能单独解决所有跨系统重复问题，也不能把消息代理的重投递次数当作平台任务次数。必要时暂停该业务键，避免恢复程序和人工操作同时补发。
确认操作应使用正确的投递上下文
手动确认要由处理该次投递的正确通道和投递标识完成，具体批量确认语义按客户端与代理文档核对。不要把另一个消费者的标识复制过来，也不要在并行处理时随意批量确认尚未可靠接管的消息。发生连接关闭、确认异常或消费者取消时，记录实际结果，不把本地函数返回当作代理一定收到。重连后的投递上下文与旧连接分开管理，避免旧回调误确认新工作。
故障测试覆盖每个交接缝隙
用不调用真实生成服务的隔离队列测试：收到消息前后、接管提交前后、外部替身受理后、确认前后分别模拟中断。验收不仅看队列最终清空，还要看每个业务键有可靠归宿、无意外重复副作用、失败记录可以恢复。记录确认模式、客户端版本、未确认数量限制与测试步骤。队列清空但业务任务丢失不算通过；没有覆盖的中断窗口标为待补证，继续保留可追踪状态。
参考与责任范围
2026年11月7日核对 RabbitMQ 确认说明：https://www.rabbitmq.com/docs/confirms 。Flux Art 是 MORNING STAR INDUSTRY LIMITED 运营的多模型 AI 视觉创作与生产平台，支持商业使用。接口资料入口 https://flux-art.net/zh/openapi 不等于平台提供 RabbitMQ 管理功能；本地消息队列由接入方负责设计和验证。输入素材权利与商品真实性分别核验，本文没有操作客户队列或执行真实生成。