ComfyUI 工作流 API 怎麼接入網站：前端、後端、佇列和結果展示流程

把 ComfyUI 工作流接進網站，不是前端直接調一個 API 就完事。可用的產品流程需要前端表單、後端任務接口、參數映射、圖片上傳、佇列、狀態輪詢、結果儲存和錯誤處理。

更穩的做法是：workflow JSON 由後端維護，使用者只填安全參數；後端把參數寫入工作流，提交給 ComfyUI，再把結果保存並返回給前端。

先分清兩層 API

通常有兩層：

1. 網站自己的 API，給瀏覽器調用。
2. ComfyUI API，給後端內部調用。

不要把 ComfyUI API 直接暴露到公網。它更適合當內部渲染服務，而不是公開 API Gateway。

最小網站功能閉環

1
2
3
4
5
6
7

使用者填表
  -> 後端建立任務
  -> 後端把參數映射到 workflow JSON
  -> 後端提交給 ComfyUI
  -> 前端輪詢任務狀態
  -> 後端取得生成結果
  -> 前端展示或下載

這就是第一版最小可用流程。

後端接口怎麼設計

可以先做三個接口：

1
2
3

POST /api/generate
GET  /api/tasks/{taskId}
GET  /api/tasks/{taskId}/result

POST /api/generate 只負責建立任務並返回 taskId，不要讓這個請求一直等到圖片生成完成。

任務狀態要自己維護

建議維護：

1
2
3
4
5

queued
running
succeeded
failed
expired

即使 ComfyUI 有 queue 和 history，產品側仍需要自己的任務狀態，方便前端展示和排查。

workflow JSON 不要讓使用者直接傳

workflow JSON 應該是後端配置。使用者只能改安全字段：

• prompt；
• negative prompt；
• style；
• size；
• seed；
• 上傳圖片；
• 限制範圍內的 strength 或 steps。

讓使用者上傳任意 workflow JSON，可能暴露模型、節點、路徑或高成本操作。

參數映射要單獨維護

把表單字段映射到工作流節點：

1
2
3
4

form.prompt -> workflow node text
form.seed -> sampler seed
form.width -> latent width
form.height -> latent height

這樣換工作流時，不需要重寫整個前端。

圖片上傳怎麼處理

圖生圖或參考圖流程建議：

1. 先傳到後端。
2. 驗證格式和大小。
3. 暫存文件。
4. 傳給 ComfyUI 或放到 ComfyUI 可讀的位置。
5. 到期後清理。

不要只相信瀏覽器給的文件名和 MIME type。

前端交互怎麼做

前端應該提供：

• 表單校驗；
• 上傳進度；
• 排隊或生成中狀態；
• 等待提示；
• 結果預覽；
• 重試按鈕；
• 可理解的錯誤信息。

不要只放一個無限轉圈。

後端提交 ComfyUI 的偽代碼

1
2
3
4
5
6
7
8

receive request
validate user input
create task record
load workflow template
patch safe parameters into workflow
submit prompt to ComfyUI
save prompt_id and task status
return taskId

後續由 worker 或輪詢任務更新狀態，直到結果生成。

結果文件怎麼存

方案一：直接從後端代理下載

內部小工具可以先這樣做。後端從 ComfyUI 取文件，再返回給瀏覽器。

方案二：上傳到物件儲存

公開網站更建議用 S3、R2、OSS 等物件儲存，只在資料庫裡保存 URL 和元資料。

為什麼需要佇列

圖片生成慢，GPU 資源有限。沒有佇列，使用者連點幾次就可能壓垮服務。

佇列可以控制：

• 並發；
• 使用者限流；
• 重試；
• 超時；
• 優先級；
• GPU 使用率。

錯誤處理要給使用者能懂的信息

把內部錯誤轉成可理解提示：

• prompt 不合法；
• 上傳文件太大；
• 生成超時；
• 模型暫不可用；
• 佇列已滿；
• 結果已過期。

詳細堆疊留在日誌裡，不要返回給瀏覽器。

上線前要加哪些保護

• 登入或配額；
• 上傳限制；
• prompt 和內容策略檢查；
• workflow 參數限制；
• 佇列並發控制；
• 超時和取消；
• 結果過期；
• 成本監控；
• 模型和節點 allowlist；
• 內部 API 保護。

RunningHub 和自建 ComfyUI 怎麼選

RunningHub 這類託管平台能減少基礎設施工作，適合快速驗證產品。自建 ComfyUI 則更適合需要控制模型、節點、GPU 成本、資料邊界和自訂工作流的場景。

快速試產品可用託管；需要深度控制時再自建。

一個推薦落地順序

1. 先在 ComfyUI 手動跑通工作流。
2. 固定一份 workflow JSON。
3. 只暴露少量安全參數。
4. 建立後端任務 API。
5. 前端加輪詢。
6. 保存結果。
7. 加佇列和限制。
8. 加監控和清理。
9. 再擴展更多工作流。

FAQ

前端可以直接調用 ComfyUI API 嗎？

公開網站不建議。應由後端做邊界。

網站需要 WebSocket 嗎？

第一版不一定需要，輪詢就夠。之後可以用 WebSocket 改善進度體驗。

workflow JSON 可以讓使用者上傳嗎？

通常不建議。後端維護工作流，只暴露安全參數。

生成結果應該存在哪裡？

生產環境通常應放物件儲存，而不是留在 ComfyUI 機器上。

一個網站能接多個 ComfyUI 工作流嗎？

可以。用 workflow ID 和獨立參數映射管理。

影片工作流和圖片工作流接入一樣嗎？

結構類似，但影片需要更長超時、更大儲存、更嚴格佇列和更清楚的進度提示。

小結

ComfyUI 接網站的穩定做法，是把它當內部渲染引擎。後端負責 workflow、佇列、任務狀態、結果儲存和安全限制；前端只收集安全輸入並展示進度和結果。