展开本页目录
开始前准备什么
- 已有本地 ComfyUI 环境；按所用模型官方说明准备硬件和权重。
- 下载本页材料，检查模型家族、目录与来源；模型权重未打包。
- 保留原文件与实际版本，UI workflow 与 API prompt 分开。
- 先理解本地服务边界
- 保存提交响应标识
- 查询当前队列
- 按 prompt_id 读取历史
- 读取真实输出引用
- 核对下载文件与记录
- 测试空历史与缺文件分支
2026-10-24 核验材料；实际执行范围、结果与限制见下方记录。
补充：原有练习资料与下载
含 UI/单独 API JSON、原输入、模型清单、校验脚本和真实负例；无权重及本次推理输出。
按官方 0.4 格式整理；仅结构核验，需在你的目标版本实际导入。
从本页工作流 Loader 字段读取；按官方来源准备兼容权重。
空结果栏，供你填写实际输出与故障；不预填虚构成功结果。
原生队列链路实测：提交、按 prompt_id 等完成，再用 view 下载
原生服务真正接受并完成任务，下载字段来自 history；相同请求缓存与同前缀新输入的文件计数器分别验证。
· 实际读取 /prompt、/queue、/history/{id} 和 /view；验证成功状态、PNG 字节和缓存行为。
- 运行环境
- ComfyUI 0.42.0；官方提交 8baf68d53d751216dd95d4f678bf109d82db3442；原生前端 1.57.1，中文界面；Python 3.12.13，CPU；独立本地实例 127.0.0.1:3344；关闭自定义节点与合作伙伴节点，未下载模型权重；输入为本站原创几何测试图，不含用户图片；本地练习无需 apizt API Key
1. 提交并保存 prompt_id
用有效 API 节点对象 POST /prompt；保存返回 ID 与 number。收到 HTTP 200 只表示接受排队，不代表已经产出图片。
2. 查询当前队列
GET /queue 查看 queue_running/queue_pending；短任务可能在第一次查询前就已完成，因此队列为空不等于提交失败。
3. 按 ID 等待终态
轮询 /history/{prompt_id}；检查该 ID 存在、status.completed=true、status.status_str=success，再读取 outputs。脚本超时仅报错并保留 ID，不盲目重提。
bashpython3 run_image_workflow.py --base http://127.0.0.1:81884. 按输出字段下载
从 outputs 的 images 数组读取 filename/subfolder/type，并 URL 编码为 /view 查询参数；不要拼接服务器绝对路径或假设固定节点 ID。
5. 识别缓存与重复文件
本次相同 prompt 命中执行缓存并复用 single_00001_.png；将输入改为 b 后，相同前缀产生 single_00002_.png，旧图未覆盖。检查 history，而非用新文件名是否出现判断完成。
这次实际得到什么
- 成功历史中完成状态与实际 PNG 下载同时存在；单图文件 3112 字节、256×192，SHA-256 为 2ab891efb9f136e136e073848e858eb7704a5769c781907eb9e98fad24b19072。
- 同一 prompt 完全不变时，本次 history 复用已缓存产物；变更输入后才产生同前缀的新计数文件。
- 两图批任务与可移植脚本复跑均按 prompt_id 保存了队列快照和 history；原生 UI 列表能看到对应输出。
使用这份结果时注意
- 任务很短，轮询快照不保证抓到 running 瞬间；完成由该 ID 的 history 判断。
- 未测试多用户、反向代理鉴权、跨机器网络或大规模并发。
1. 先理解本地服务边界
素材包仅含读取你自己的 ComfyUI 服务的 queue_client.py 与 API 示例。默认 origin 为 127.0.0.1:8188，保持服务本机可达；不要把无认证服务直接开放到公网。
2. 保存提交响应标识
实际 POST /prompt 后立刻写下 prompt_id 与 node_errors；请求超时而响应未知时，先查本地队列和已有记录，不盲目重提。脚本默认不提交，只有明确 --submit 才会排队。
已有 prompt_id 时跳过提交，只运行下一步查询命令。只有确认要创建一个新任务、模型和本地服务均已就绪时，才运行下面的 --submit；它读取素材包 prompt-api.json，实际排队并继续轮询，不是演示或空跑。
submit-one-local-task.sh
python queue_client.py --origin http://127.0.0.1:8188 --submit3. 查询当前队列
GET /queue 的原生字段为 queue_running 与 queue_pending，按 prompt_id 查看当前任务。队列里没有不一定是成功，也可能失败、被移除或已完成；继续查询同一 ID 的 history。
在解压后的素材目录执行下面命令，把 YOUR_PROMPT_ID 换成已保存的真实 ID。该模式不会新建任务；客户端按此 ID 轮询 history，并在确认图片条目后下载到 actual-output/。服务仍未完成时会有上限地等待，再明确超时。
query-existing-task.sh
python queue_client.py --origin http://127.0.0.1:8188 --prompt-id YOUR_PROMPT_ID4. 按 prompt_id 读取历史
GET /history/{prompt_id}，如果暂时为空继续有上限地等待；检测错误信息或完成状态。脚本设置轮询次数和间隔，不无限循环，也不把 HTTP 200 就视为生成完成。
5. 读取真实输出引用
遍历 history 中 outputs 下实际 images 项，保存 filename、subfolder 和 type，使用 /view 查询下载。不能硬编码 ComfyUI_00001_.png 作为本次结果。
6. 核对下载文件与记录
检查 HTTP 状态、非空内容及图片格式，把 prompt_id 和输出路径一起写记录。素材包 history-fixture.json 是标注的人工响应教材，离线测试只检验解析逻辑，不证明服务实际完成。
7. 测试空历史与缺文件分支
旧包的 python queue_client.py --self-test 检查完成、空历史、缺少 images 三种夹具。10月24日新增原生在线 queue/history/view 与真实输出记录；自己的服务仍须按实际 prompt_id 验证，不能只用夹具判成功。
--self-test 只解析素材包中的本地 fixture，不访问 ComfyUI 服务，也不会生成图片；它通过不表示真实队列、模型或下载已验证。实际查询与新建任务分别使用上面的 --prompt-id 和 --submit。
8. 下载工作流、输入和结构检查
完整包包含官方来源 JSON、按本页整理的 UI workflow、单独的 API prompt、真实输入 PNG、模型与参数清单、空验收表、故障负样本和离线脚本。先执行 python check.py，再在自己的 ComfyUI 安装中导入与实际运行。包内权重未下载，结构检查不能替代前端兼容与推理验收。
怎样确认已经完成
- prompt_id 在提交响应后立即保存，超时不盲重提。
- running/pending/history 三种来源分开判定，空历史不误报完成。
- 下载路径来自实际 history 的图片条目，fixture 与在线结果明确区分。
常见问题
ComfyUI API队列查询教程：轮询 prompt_id 并下载历史输出本次实际验证了什么？
原生服务真正接受并完成任务，下载字段来自 history；相同请求缓存与同前缀新输入的文件计数器分别验证。
本次结果有哪些适用限制？
任务很短，轮询快照不保证抓到 running 瞬间；完成由该 ID 的 history 判断。 未测试多用户、反向代理鉴权、跨机器网络或大规模并发。