ComfyUI API自动化测试：Postman集成与异步接口验证实战-尧图网络科技

1. 项目概述：为什么需要自动化接口验证？

如果你正在使用 ComfyUI 的托管 API 服务（比如 ComfyStack、RunDiffusion 或其他云服务）来部署你的 AI 生图工作流，那么你很可能已经体验过手动测试接口的繁琐。每次修改工作流中的一个参数，比如更换模型、调整提示词，或者只是想验证一下 API 是否正常工作，你都需要打开终端，复制粘贴一长串curl命令，然后等待返回结果。这还只是单次测试，如果涉及到复杂的业务逻辑，比如批量生成、条件判断或者与其他系统集成，手动测试的效率会低得令人抓狂。

这就是“ComfyUI 与 Postman 测试集成”要解决的问题。它不是一个新工具，而是一套将 Postman 这个强大的 API 测试平台，与 ComfyUI 的 API 服务深度结合的方法论和实操流程。其核心价值在于将一次性的、手动的接口调用，转变为可重复、可自动化、可协作的标准化测试流程。

简单来说，它能帮你：

固化请求：将复杂的 ComfyUI API 请求（包括认证、工作流 ID、动态参数）保存为 Postman 的 Collection，团队成员可以共享和复用。
参数化与变量管理：用 Postman 的环境变量、集合变量来管理你的 API Key、工作流 ID、以及每次生成时变化的参数（如seed,prompt），实现“一次配置，多次运行”。
自动化测试与监控：利用 Postman 的 Collection Runner 或 Newman（命令行工具）进行批量测试、定时任务，甚至集成到 CI/CD 流水线中，确保你的 AI 生图服务稳定可靠。
可视化与调试：Postman 提供了清晰的请求/响应视图、测试脚本编写（JavaScript）和结果断言功能，让你能直观地验证生成的图片 URL 是否有效、任务状态是否正确，远比在终端里看 JSON 输出要高效。

对于开发者、测试工程师以及需要频繁调用 ComfyUI API 的运营人员来说，掌握这套方法，意味着能将 AI 生图能力像其他微服务一样进行规范化的测试和管理，是提升生产力和保障服务质量的必备技能。

2. 核心思路与方案设计

在开始动手之前，我们需要理清 ComfyUI API 的工作模式，以及如何用 Postman 的特性来适配它。ComfyUI 的托管 API 通常遵循一个异步任务模型，这与我们熟悉的即时返回结果的 REST API 有所不同。

2.1 ComfyUI API 调用流程解析

一个典型的 ComfyUI 文生图 API 调用包含三个核心阶段，理解这个流程是设计自动化测试的关键：

提交任务 (/prompt)：你向 API 发送一个包含workflow_id和动态prompt参数的 POST 请求。服务器不会等待图片生成完毕，而是立即返回一个prompt_id（任务 ID）和一个用于 WebSocket 连接的prompt_token。这是一个“触发即返回”的异步接口。
查询任务状态与结果 (/get_task_info)：拿到prompt_id后，你需要通过轮询（Polling）这个接口来获取任务执行进度、队列位置以及最终的生成结果（图片 URL）。任务状态（status）从1（排队中）到3（成功）或4（失败）变化。
（可选）实时进度推送 (WebSocket)：为了获得更好的体验，你可以使用返回的prompt_token建立 WebSocket 连接，服务器会在任务状态变化时主动推送进度，避免频繁轮询。

2.2 Postman 集成方案设计

针对上述异步流程，我们在 Postman 中的集成方案需要解决几个核心问题：

如何串联异步调用？一个请求的响应（prompt_id）是下一个请求的参数。
如何实现高效的轮询？避免手动重复发送请求。
如何验证最终结果？不仅检查状态码，还要验证返回的图片 URL 是否可访问、图片内容是否符合预期（例如，通过检查响应时间或文件头）。

我的方案是构建一个三层结构的 Postman Collection：

环境变量层：存放基础配置，如base_url、api_key、workflow_id。这样切换测试/生产环境时，只需切换环境，无需修改每一个请求。
请求集合层：
- 01_submit_task: 提交生成任务。
- 02_poll_status: 轮询任务状态。这里会用到 Postman 的“Tests” 标签页和setNextRequest功能来实现自动化轮询逻辑。
- 03_download_image: 在任务成功后，自动解码并下载结果图片。
测试脚本层：在“Tests”标签页中编写 JavaScript 代码，用于：
- 从响应中提取prompt_id并保存为变量。
- 判断任务状态，如果未完成，则自动再次调用02_poll_status。
- 对最终结果进行断言（如状态码为 200、包含图片 URL 等）。

这个设计将一次完整的手动调用，封装成了一个点击“Runner”就能全自动执行的测试流程。

2.3 工具选型与准备

Postman：桌面版或 Web 版均可。确保你有一个账号（免费版足够用于此集成）。
可用的 ComfyUI API 服务：你需要一个已经部署好、并且你知道其base_url和拥有有效API Key的 ComfyUI 托管服务。本文将以通用的 ComfyUI API 规范为例，具体 URL 和参数请替换为你自己的服务。
一个已发布为 API 服务的工作流：在您的 ComfyUI 托管平台（如 ComfyStack）上，确保已经上传并发布了一个工作流，并获取到其唯一的workflow_id。

注意：不同的 ComfyUI 托管服务商（如 ComfyStack, RunDiffusion, 或其他自建服务）的 API 端点路径、认证方式可能略有差异。请务必以你所用服务的官方文档为准。本文提供的思路和模式是通用的。

3. 实操搭建：在 Postman 中构建自动化测试流

接下来，我们一步步搭建这个自动化测试集合。

3.1 第一步：创建环境变量

在 Postman 中，点击左侧的 “Environments”，然后点击 “+”。
给环境命名，例如ComfyUI_Production。
添加以下变量：
- base_url: 你的 ComfyUI API 服务基础地址，例如https://api.your-comfy-service.com。
- api_key: 你的 API Key，格式通常为sk-xxxxxxxxxxxx。请务必将其初始值设为空，并在当前值（Current Value）栏填写。这样可以将它作为“秘密”管理，避免在分享集合时泄露。
- workflow_id: 你已发布的工作流 ID，例如wf-abc123def456。
- prompt_id: 留空。这个变量将由我们的脚本在运行时动态填充。

3.2 第二步：创建请求集合 (Collection)

点击左侧 “Collections”，然后点击 “+”。
命名为ComfyUI Image Generation API Test。
在集合的 “Variables” 标签页，你也可以定义一些集合级别的变量，例如polling_interval（轮询间隔，单位毫秒），设为2000（2秒）。

3.3 第三步：构建 “01_submit_task” 请求

这个请求对应提交文生图任务。

在刚创建的集合下，新建一个请求，命名为01_submit_task。
方法选择POST。
URL 填写：{{base_url}}/api/maas/comfy_task_api/prompt（请根据你的实际 API 文档调整路径）。
在 “Headers” 标签页，添加：
- Authorization:Bearer {{api_key}}
- Content-Type:application/json
在 “Body” 标签页，选择raw和JSON，然后填入请求体。这里的关键是prompt对象，它需要根据你的工作流结构来定义。一个最简单的示例如下：

{ "workflow_id": "{{workflow_id}}", "prompt": { "3": { "inputs": { "seed": 123456789, "steps": 20, "cfg": 7, "sampler_name": "euler", "scheduler": "normal" } }, "6": { "inputs": { "text": "a beautiful landscape, mountains, lake, sunset, masterpiece" } }, "7": { "inputs": { "text": "ugly, blurry, low quality" } } } }

重要提示：prompt对象内的节点 ID（如“3”,“6”,“7”）和参数名必须与你发布的工作流完全匹配。最可靠的方式是使用你所用平台提供的“查看参数范围”或“在线调试”功能，获取针对你特定工作流的请求体示例。

在 “Tests” 标签页，我们编写脚本，用于提取响应中的prompt_id并保存，同时为下一个请求设置逻辑。

// 检查请求是否成功 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // 解析响应JSON var jsonData = pm.response.json(); // 确保响应包含预期的数据字段 pm.test("Response has success code and data", function () { pm.expect(jsonData.code).to.eql(0); pm.expect(jsonData.data).to.be.an('object'); pm.expect(jsonData.data.prompt_id).to.be.a('string'); }); // 将返回的 prompt_id 保存到环境变量中，供后续轮询请求使用 var promptId = jsonData.data.prompt_id; pm.environment.set("prompt_id", promptId); console.log("Task submitted. Prompt ID saved: " + promptId); // 可选：将 prompt_token 也保存下来，如果你想测试 WebSocket 的话 if (jsonData.data.prompt_token) { pm.environment.set("prompt_token", jsonData.data.prompt_token); } // 关键：设置下一个要执行的请求为轮询状态请求 // 这将在使用 Collection Runner 时生效 postman.setNextRequest("02_poll_status");

3.4 第四步：构建 “02_poll_status” 请求

这个请求用于轮询任务状态。

新建请求，命名为02_poll_status。
方法选择POST。
URL 填写：{{base_url}}/api/maas/comfy_task_api/get_task_info
Headers 同上：Authorization: Bearer {{api_key}}和Content-Type: application/json。
Body 填入：

{ "comfy_task_ids": ["{{prompt_id}}"] }

在 “Tests” 标签页，编写更复杂的逻辑来处理轮询：

// 检查状态查询请求本身是否成功 pm.test("Status check request is successful", function () { pm.response.to.have.status(200); }); var jsonData = pm.response.json(); var taskInfo = jsonData.data.comfy_task_info[0]; // 获取第一个任务信息 // 检查任务信息是否存在 pm.test("Task info exists", function () { pm.expect(taskInfo).to.be.an('object'); }); var currentStatus = taskInfo.status; var progress = taskInfo.progress_num; var taskId = taskInfo.comfy_task_id; console.log(`Task [${taskId}] Status: ${currentStatus}, Progress: ${progress}%`); // 根据状态决定下一步操作 if (currentStatus === 3) { // 状态 3: 成功 console.log("Task completed successfully!"); pm.test("Task completed with status 3", function () { pm.expect(currentStatus).to.eql(3); }); // 将最终的文件URL保存到环境变量，供下载请求使用 if (taskInfo.final_files && taskInfo.final_files.length > 0) { // 注意：URL 可能需要解码，这里先保存原始字符串 pm.environment.set("final_image_url", taskInfo.final_files[0]); console.log("Final image URL saved."); } else if (taskInfo.files) { // 有些API可能用 files 字段，这里假设输出节点ID是 ‘9’ const outputNodeId = “9”; // 请根据你的工作流调整 if (taskInfo.files[outputNodeId] && taskInfo.files[outputNodeId].length > 0) { pm.environment.set("final_image_url", taskInfo.files[outputNodeId][0]); console.log("Final image URL (from files) saved."); } } // 任务完成，设置下一个请求为下载图片，然后结束流程 postman.setNextRequest(“03_download_image”); } else if (currentStatus === 4 || currentStatus === 5) { // 状态 4: 失败， 5: 权限不足 console.error(`Task failed or was denied. Status: ${currentStatus}, Error: ${taskInfo.errMsg}`); pm.test(`Task should not fail`, function () { pm.expect(currentStatus).to.not.be.oneOf([4, 5]); }); // 失败，停止后续请求 postman.setNextRequest(null); } else { // 状态 1 (排队中) 或 2 (生成中) console.log(`Task still in progress (Status: ${currentStatus}). Will poll again after delay.`); // 使用 setTimeout 模拟等待，然后再次调用自己（轮询） // 注意：这在 Postman 的 “Send” 按钮下无效，仅在 Collection Runner 中有效。 // 我们使用 postman.setNextRequest 配合 Runner 的延迟设置来实现轮询。 // 这里我们仍然设置下一个请求为自己，但依赖 Runner 的 “Delay” 功能。 postman.setNextRequest(“02_poll_status”); // 你也可以在这里添加一个测试失败来让 Runner 暂停？不，更好的方法是控制迭代。 // 我们通过判断状态不是成功/失败，并设置下一个请求为自己，来实现循环。 // Runner 会执行下一次迭代，中间会有间隔。 }

关于轮询的实现：上面的脚本通过postman.setNextRequest(“02_poll_status”)在任务未完成时，指示 Runner 再次执行同一个请求。为了控制频率，你需要在Collection Runner中设置 “Delay”（例如 2000 毫秒）。单纯的setTimeout在单次请求的 “Tests” 标签页中不会阻塞请求流程，因此不适用。

3.5 第五步：构建 “03_download_image” 请求

此请求用于验证生成的图片 URL 是否有效。

新建请求，命名为03_download_image。
方法选择GET。
URL 填写：{{final_image_url}}。注意，从 API 获取的 URL 可能包含编码字符（如%2F代表/，\u0026代表&）。Postman 的环境变量会自动处理一些编码，但如果遇到问题，你可能需要在 “Pre-request Script” 中先对 URL 进行解码。
这个请求通常不需要特殊的 Headers，因为图片 URL 通常已包含鉴权参数。
在 “Tests” 标签页，我们可以对图片响应做基本验证：

// 验证请求成功 pm.test(“Image downloaded successfully”, function () { pm.response.to.have.status(200); }); // 验证返回的内容是图片 pm.test(“Response is an image”, function () { pm.expect(pm.response.headers.get(“Content-Type”)).to.include(“image/”); }); // 可选：验证图片大小（例如，大于 10KB） pm.test(“Image size is reasonable”, function () { pm.expect(pm.response.responseSize).to.be.above(10240); // 10KB }); console.log(“Image download and validation passed. Automation flow completed.”); // 流程结束，将下一个请求设为 null postman.setNextRequest(null);

3.6 第六步：配置并运行 Collection Runner

现在，我们已经有了三个串联的请求。如何让它们自动按顺序执行，并在02_poll_status处循环等待呢？

点击你的 Collection 旁边的 “…” 按钮，选择 “Run collection”。
在 Runner 界面：
- 环境选择：确保右侧选择了你创建的ComfyUI_Production环境。
- 迭代次数：设为一个较大的数，比如 30。这定义了轮询的最大次数（30次 * 延迟时间）。
- 延迟：这是关键！设置一个延迟，比如 2000 毫秒。这意味着每个请求执行后，会等待 2 秒再执行下一个迭代。这给了 API 处理任务的时间。
- 日志级别：建议选择 “All logs”，方便调试。
点击 “Run ComfyUI Image Generation API Test”。

运行过程：

Runner 执行01_submit_task，提交任务，脚本将prompt_id存入变量，并指示下一个请求是02_poll_status。
Runner 等待 2 秒（延迟），然后执行02_poll_status。
02_poll_status的脚本检查状态。如果是“进行中”，它再次将下一个请求设置为02_poll_status。
Runner 再次等待 2 秒，然后又一次执行02_poll_status（这就是轮询）。
当脚本检测到状态变为3（成功）时，它保存图片 URL，并将下一个请求设置为03_download_image。
Runner 执行03_download_image，下载并验证图片。脚本将下一个请求设为null。
Runner 遇到null，知道流程结束，停止运行。

这样，你就实现了一个完整的、从提交任务到下载验证的全自动化接口测试流程。

4. 高级技巧与深度优化

基础的自动化流程搭建完成后，我们可以进一步利用 Postman 的强大功能来提升测试的健壮性、可维护性和场景覆盖度。

4.1 使用 Pre-request Scripts 进行请求前预处理

“Pre-request Scripts” 在请求发送前执行，非常适合用于动态生成数据或处理变量。

场景一：自动生成随机参数。避免每次测试都用相同的seed和prompt，让测试更具随机性。

在01_submit_task的 “Pre-request Scripts” 标签页中：

// 生成一个随机种子 const randomSeed = Math.floor(Math.random() * 1000000000); pm.environment.set(“random_seed”, randomSeed); // 从一个提示词数组中随机选择一个 const promptArray = [ “A cyberpunk cityscape at night, neon lights, raining”, “A serene portrait of an elderly wizard, detailed, fantasy art”, “A cute corgi puppy sitting in a field of sunflowers, cartoon style” ]; const randomPrompt = promptArray[Math.floor(Math.random() * promptArray.length)]; pm.environment.set(“random_prompt”, randomPrompt); console.log(`Using seed: ${randomSeed}, prompt: ‘${randomPrompt}’`);

然后，在请求 Body 中，就可以使用{{random_seed}}和{{random_prompt}}变量了。

场景二：URL 解码。如果从get_task_info获取的图片 URL 包含\u0026这样的 JSON Unicode 转义字符，需要在03_download_image的 “Pre-request Scripts” 中先解码：

// 获取环境变量中的原始URL let encodedUrl = pm.environment.get(“final_image_url”); if (encodedUrl) { // 替换 Unicode 转义序列，如 \u0026 -> & let decodedUrl = encodedUrl.replace(/\\u([\dA-F]{4})/gi, (match, grp) => String.fromCharCode(parseInt(grp, 16)) ); // 更新请求的URL变量 pm.environment.set(“final_image_url_decoded”, decodedUrl); // 在Runner中，你需要让请求URL使用这个解码后的变量 // 可以将请求URL改为：{{final_image_url_decoded}} }

4.2 编写更健壮的测试断言

除了检查 HTTP 状态码，我们应该对 ComfyUI API 的业务逻辑进行断言。

在02_poll_status的 “Tests” 中，可以增加：

// 断言返回的数据结构符合预期 pm.test(“Response has correct structure”, function () { pm.expect(jsonData).to.have.property(‘code’, 0); pm.expect(jsonData).to.have.property(‘msg’, ‘Success’); pm.expect(jsonData.data).to.have.property(‘comfy_task_info’).that.is.an(‘array’); pm.expect(jsonData.data.comfy_task_info).to.have.lengthOf(1); }); // 断言任务ID与提交的一致 pm.test(“Returned task ID matches the submitted one”, function () { pm.expect(taskInfo.comfy_task_id).to.eql(pm.environment.get(“prompt_id”)); }); // 断言进度值在合理范围内 pm.test(“Progress is a valid number”, function () { pm.expect(taskInfo.progress_num).to.be.a(‘number’); pm.expect(taskInfo.progress_num).to.be.within(0, 100); });

4.3 参数化与数据驱动测试

如果你想用多组不同的输入（提示词、模型参数）来测试同一个工作流，可以使用 Postman 的Data Files功能。

创建一个 CSV 或 JSON 文件，例如test_data.csv：

seed, positive_prompt, negative_prompt, steps, cfg 123, “a castle on a hill”, “blurry”, 20, 7 456, “a spaceship in orbit”, “”, 30, 5 789, “a bowl of fruit, photorealistic”, “text, watermark”, 25, 8

在 Collection Runner 中，选择 “Select File” 上传这个 CSV。
在请求的 Body 中，使用 CSV 的列名作为变量，例如{{seed}},{{positive_prompt}}。
Postman 会为数据文件中的每一行运行一次整个 Collection，实现批量自动化测试。

4.4 集成外部监控与通知

虽然 Postman 本身有监控功能（需要付费计划），但我们可以通过 “Tests” 脚本在失败时调用外部 Webhook。

例如，在02_poll_status的失败分支（status === 4）里，添加：

// 当任务失败时，发送通知到 Slack 或钉钉 if (currentStatus === 4) { const webhookUrl = pm.environment.get(“alert_webhook_url”); // 将 webhook URL 存在环境变量中 if (webhookUrl) { const requestData = { url: webhookUrl, method: ‘POST’, header: ‘Content-Type: application/json’, body: { mode: ‘raw’, raw: JSON.stringify({ text: `🚨 ComfyUI 任务执行失败！\n任务ID: ${taskId}\n错误信息: ${taskInfo.errMsg}\n时间: ${new Date().toISOString()}` }) } }; // pm.sendRequest 是异步的，这里我们发送请求但不等待结果 pm.sendRequest(requestData, function (err, response) { console.log(‘Alert webhook sent.’, err ? err : response); }); } }

4.5 使用 Newman 进行命令行集成

Postman 的 Collection 可以通过 Newman（一个命令行工具）来运行，这为 CI/CD 集成打开了大门。

导出 Collection 和环境：在 Postman 中，将你的 Collection 和环境分别导出为 JSON 文件（例如comfyui-collection.json和comfyui-env.json）。
安装 Newman：npm install -g newman
运行测试：
```
newman run comfyui-collection.json -e comfyui-env.json --delay-request 2000 --iteration-count 5
```
- --delay-request 2000: 设置请求间延迟。
- --iteration-count 5: 运行 5 次迭代（对于轮询逻辑，一次迭代可能不够，需要结合 Collection 内的setNextRequest逻辑理解。更常见的做法是直接运行整个 Collection，依赖其内部循环逻辑，并设置一个总的超时时间）。
集成到 CI/CD：你可以在 GitHub Actions、GitLab CI 或 Jenkins 的 Pipeline 中执行上述 Newman 命令，并将测试报告生成 JUnit 或 HTML 格式，作为流水线质量门禁的一部分。

5. 常见问题排查与实战心得

在实际操作中，你肯定会遇到各种问题。下面是我总结的一些典型问题及其解决方案。

5.1 认证失败 (401 Unauthorized)

症状：请求返回 401 状态码。
排查：
1. 检查Authorization请求头是否正确：Bearer后面是否有空格？Key 是否正确？
2. 检查 API Key 是否已过期或被撤销。
3. 检查环境变量api_key的当前值 (Current Value)是否已正确填写，而不是只填了初始值。
4. 确认你的 API 服务商要求的认证方式（可能是X-API-Key头，而不是Authorization）。

5.2 工作流未找到或参数错误 (400 Bad Request / 404 Not Found)

症状：提交任务时返回 400 或 404，提示workflow_id无效或prompt参数错误。
排查：
1. 核对workflow_id：确保是从托管平台正确复制的工作流 ID，且该工作流已成功发布为 API 服务。
2. 仔细检查prompt对象结构：这是最常见的问题。节点 ID 和输入名称必须与你的工作流完全一致。一个数字错误（如把“6”写成“7”）就会导致失败。强烈建议：先在平台的“在线调试”功能里，用界面操作生成一次图片，然后复制它给出的curl命令示例中的prompt部分，以此作为你 Postman 请求体的模板。
3. 检查参数值类型：例如，seed应该是数字，text应该是字符串。JSON 格式必须正确。

5.3 轮询陷入无限循环或超时

症状：测试一直在02_poll_status循环，永不停止。
排查：
1. 检查任务状态：手动调用一次get_task_info，看看任务是否真的卡住了（比如资源不足、模型加载失败）。errMsg字段可能有提示。
2. 检查轮询逻辑：确保你的 “Tests” 脚本正确判断了所有终态（成功3，失败4，权限不足5）。终态时必须执行postman.setNextRequest(null)或跳转到其他请求。
3. 设置超时机制：在 Collection 或 Runner 级别设置一个最大迭代次数或总超时时间。可以在02_poll_status的 “Pre-request Script” 中增加一个计数器：

// 初始化轮询计数器 if (!pm.environment.get(“poll_count”)) { pm.environment.set(“poll_count”, 0); } let count = parseInt(pm.environment.get(“poll_count”)) + 1; pm.environment.set(“poll_count”, count); // 设置最大轮询次数为 30 const maxPolls = 30; if (count > maxPolls) { console.error(`Polling exceeded ${maxPolls} times. Force stopping.`); postman.setNextRequest(null); // 强制停止 // 或者抛出一个测试失败 pm.test(`Polling should complete within ${maxPolls} attempts`, function () { pm.expect(count).to.be.lessThan(maxPolls); }); }

4. **调整延迟时间**：如果任务通常需要 10 秒完成，你每 2 秒轮询一次，可能需要 5-6 次。如果任务很重，可能需要更长的延迟（如 5 秒）和更多的迭代次数。

5.4 图片 URL 下载失败

症状：03_download_image请求返回 403 或 404。
排查：
1. URL 编码问题：这是罪魁祸首。从 API 返回的 URL 可能包含%2F(/) 或\u0026(&)。Postman 的{{variable}}语法有时不能正确处理后者。务必在 “Pre-request Script” 中先进行解码（如 4.1 节所述）。
2. URL 过期：ComfyUI 服务生成的图片 OSS 链接通常有有效期（如 10 分钟）。如果你的轮询间隔太长，可能在获取 URL 后，还没来得及下载就过期了。解决方法是：在get_task_info请求中，使用url_expire_period参数设置一个较长的有效期（如 1800 秒），并确保在 URL 过期前完成下载。
3. 跨域或权限问题：如果是直接访问 OSS 链接，确保该链接是公开可读的，或者包含了正确的临时访问令牌（通常 API 返回的链接已包含）。

5.5 实战心得：让测试更可靠

从简单开始：先用一个最简单的文生图工作流（只包含 Load Checkpoint, CLIP Text Encode, KSampler, VAE Decode, Save Image）来搭建和调试你的 Postman 集合。成功后再迁移到复杂工作流。
充分利用日志：在 “Tests” 脚本中多使用console.log()输出关键变量（如prompt_id,status,progress_num）。在 Postman Console (View -> Show Postman Console) 中查看这些日志，是调试异步流程的利器。
环境隔离：为开发、测试、生产环境创建不同的 Postman 环境，管理不同的base_url和api_key。永远不要在测试中使用生产环境的 Key。
定期维护：当你的 ComfyUI 工作流更新后（例如增加了新的输入节点），记得同步更新 Postman 请求中的prompt对象结构。可以建立一个 checklist，将更新 API 测试作为工作流部署流程的必要一环。