Flux Art停止接新任务，不等于所有任务都停止
通过 Flux Art 接口批量制作素材时，运营可能要求暂停某批任务、切换值班人员或停机维护。先停止新的领取和提交，再盘点已经发出的请求；直接关闭进程不能证明远端任务取消。本文给出接入方的停接与交接清单，不假设平台提供额外取消接口，也不把未见回执的请求判定为未执行。
先写清停止范围和截止点
停止的是某个批次、某个业务版本，还是全部创建入口，必须明确。记录停接生效时间、批次标识和负责执行的写入者，防止另一个后台入口继续提交。仅在页面隐藏按钮不能保证服务器队列停下。技术人员应验证所有相关创建路径遵守停接标记，同时保留查询和必要的已完成结果入库能力；这些动作的权限与资源安排应事先说明。
按是否越过提交边界分组
假设某批有未发送队列、已有 task_id 的处理中任务，以及请求已发出却没有收到回执的项目。这不是实测数据，不能把三组都写成暂停完成。前一组可以保留为未提交；中间一组继续按既有任务核对；最后一组应单列结果未知，等待按原请求记录恢复。下表的作用是决定交接动作，不是猜测远端任务的实际结果。
| 停接时的位置 | 交接分类 | 允许的下一动作 |
|---|---|---|
| 确认尚未发出请求 | 未提交待处理 | 保留队列，等待恢复接新 |
| 已经拿到任务标识 | 已提交在途 | 查询同一任务并记录状态 |
| 请求已发但未收到回执 | 结果未知 | 核对原请求，禁止盲目重建 |
| 远端成功但文件未入库 | 待下载或入库 | 沿原任务完成文件保存校验 |
| 文件已入库但未验收 | 待业务审核 | 对照需求检查实际素材 |
| 截止时仍未结束 | 待接班继续处理 | 交付标识、证据和负责人 |
停止领取时要处理竞争窗口
工作进程可能刚取出一条任务，停接标记才写入。应在领取和即将发送之间建立受控边界，记录哪些项目已经进入提交步骤。能在发出前确定未提交的项目退回待处理；已经发出或无法证明未发出的项目不能随意退回普通待发送队列。否则接班者可能重新创建同一业务任务。具体并发控制由自建队列和持久化机制实现。
处理中任务继续查，不凭等待时长判失败
有 task_id 的任务可以按当前文档查询状态；本地维护窗口到了，不意味着远端任务失败。Flux Art 当前查询字段和错误处理见 https://flux-art.net/zh/openapi/reference 。轮询应有退避与截止安排，不能为了赶交班无限请求。到达交接截止时间仍未结束的任务，保留已知状态、最后核对时间和下一负责人，而不是改成已完成。
成功之后还有文件交付边界
远端成功、文件下载成功和素材业务验收通过是不同记录。停机前已经成功但尚未可靠入库的文件，需要记录任务标识、结果来源及后续下载安排；已入库但尚未验收的素材，交给运营继续检查。不要只交付一张绿色任务列表。文件校验应针对实际保存的内容，不能把临时链接存在当作长期存档已经完成。
结果未知要保留原请求身份
请求可能已到达远端但回执丢失时，交接单保留原请求标识、幂等键、参数摘要和最后执行步骤，不暴露 API 密钥。接班者先核对再按文档恢复同一请求，不因停机或换人创建新请求身份。若无法可靠核对，项目仍是未知；将它放入可追踪的异常队列，比写成失败后自动重试更稳妥。
给接班者一个可以验证的清单
交接包至少包含批次范围、停接证据、各组数量、每个未决项目标识、已入库文件位置以及下一动作。接班者核对清单总数是否覆盖原批次，并抽查没有项目同时出现在未提交与已完成两组。恢复接新任务前，还要确认旧写入者已经失去正式写入权限，避免两个班次同时操作；只在聊天里说已退出不能替代执行证据。
演练的重点是没有重复和没有失踪
在隔离环境中测试停接与领取同时发生、请求发出后断网、查询未终态、下载中断和换班恢复。通过标准是每个业务项目都有确定归属，未知项被明确保留，而且没有重复创建。Flux Art 使用入口 https://flux-art.net/zh 与接入方的队列控制各有职责；素材质量仍需人工验收，停接演练也不能替代商品信息与最终交付审核。