ComfyUI 啟動失敗？更快定位和恢復的方法

如果 ComfyUI 根本起不來，不要把它當成一個普通“安裝失敗”問題。

大多數啟動失敗，真正原因都出在 原本能跑的環境後來發生了變化：

• 某個插件改了關鍵包
• 某個二進制 wheel 不再匹配當前運行時
• Torch 或 CUDA 漂了
• 某個 helper 文件、bootstrap 步驟被刪了、被攔了，或者被殺毒軟件隔離了

所以真正該問的不是：

“ComfyUI 怎麼啟動？”

而是：

“上一次還能用，到現在不能用，中間到底變了什麼？”

當前最常見的啟動失敗類型

結合 launcher 遙測和真實 ComfyUI 排障，下面這些啟動失敗模式最值得優先覆蓋：

如果你的報錯和這裡某一條几乎完全一致，優先先跳到對應窄頁，不要一上來就做整套重裝。

“啟動失敗” 通常表現成什麼

常見表現包括：

• 程序窗口一閃而過或打開後馬上關閉
• ComfyUI 永遠起不到 UI
• 終端在服務啟動前就出現 import error
• ComfyUI Desktop 卡在 bootstrap 階段
• 啟動器提示缺少某個 helper 文件

第 1 步：先把啟動失敗歸類

動手前，先把問題放進下面某一類。

A 類：啟動階段的 Python 導入失敗

例如：

ModuleNotFoundError: No module named 'sqlalchemy'
comfyui-frontend-package is not installed
ModuleNotFoundError: No module named 'cv2'
ModuleNotFoundError: No module named 'onnxruntime'

這通常表示包缺失或包已損壞。 如果缺的是 ComfyUI 核心啟動路徑裡的包，就不要把它當成“單個插件問題”，直接看 逐個修復 ComfyUI Portable 依賴損壞。

B 類：核心運行時漂移

例如：

Torch not compiled with CUDA
CUDA is not available
AttributeError: module 'torch' has no attribute '...'

這通常意味著 Torch、CUDA 或其他關鍵依賴被改壞了。

C 類：插件導入鏈把啟動卡死

例如：

• 一個插件失敗後，啟動開始變得不穩定
• 裝完一個插件後，很多插件同時開始報錯
• 環境之前能跑，後來才壞

這類問題通常介於 插件導入失敗 和 依賴衝突 之間。

D 類：bootstrap 或 launcher helper 文件異常

例如：

• 某個 helper 可執行文件缺失
• 殺毒軟件把文件隔離了
• ComfyUI Desktop 或其他 Launcher 無法完成啟動鏈

如果你看到的是 bootstrapper 或 helper 文件缺失，先查殺毒軟件和安裝目錄完整性，不要先重裝。

一個更省時間的排查順序

當環境是“原來能跑，現在不能跑”時，最穩的順序通常是：

1. 找到第一條真實啟動錯誤
2. 判斷它屬於 核心運行時、插件依賴 還是 部署/啟動鏈
3. 只修最窄的第一阻塞
4. 重啟，再看新的第一條錯誤
5. 只有當環境已經沒有穩定第一阻塞時，才考慮重裝

這樣可以避免把一個依賴損壞問題直接擴大成整套環境重建。

第 2 步：找“第一條真實錯誤”，不是最後一個表面症狀

很多人只會複製最後看到的一行，但最後一行不一定是根因。

你應該在啟動日誌裡往前找：

• 第一條 IMPORT FAILED
• 第一條 ModuleNotFoundError
• 第一條 Torch / CUDA / DLL load 錯誤
• 第一條 helper / bootstrap 文件缺失

後面的報錯很可能只是連鎖反應。

第 3 步：按類別做最小恢復動作

如果是缺包

只安裝缺失的那個包，或者安裝引入該問題的插件依賴。

不要一開始就做大範圍升級。先安裝第一個真正阻塞項對應的套件，或安裝引入該相依性的插件 requirements；廣譜升級通常會把一個啟動問題變成好幾個。

如果第一條錯誤是 No module named 'sqlalchemy'，先看 SQLAlchemy 啟動修復。 如果修完一個包後，馬上暴露出下一個核心缺包，就切到 portable 依賴修復 runbook。

如果是 Torch 或 CUDA 漂移

把它當成 核心運行時問題，不要先當成插件問題。

先把核心運行時修穩，再回頭驗證插件。

常見跡象：

• ComfyUI 突然退回 CPU 路線
• CUDA 原來能用，裝完節點後突然不能用
• xformers、onnxruntime 或其他包拉進了不匹配的版本

如果是 helper 或 bootstrap 文件缺失

優先檢查：

• 殺毒軟件隔離記錄
• 安裝目錄是否完整
• 啟動器依賴文件是否還在

具體示例可以看 Bootstrapper Missing (watchdog_bootstrapper_missing)。

第 4 步：別太早掉進“重裝陷阱”

重裝看起來乾淨，但如果你機器上已經有這些資產，它往往是最貴的方案：

• 已下載的模型
• 現成工作流
• 仍然需要的自定義節點
• 你過去已經摸索好的環境修法

只有在下面這些情況，重裝才開始變得合理：

• 核心運行時已經壞到沒法推理
• helper 文件缺失且無法安全恢復
• 反覆修包已經讓環境繼續漂移

只要環境還有恢復空間，優先先保住現有資產。

為什麼啟動失敗經常發生在裝插件之後

很多人忽略的是這個模式：

1. ComfyUI 原本正常
2. 裝了一個插件，或者更新了插件
3. 某個 requirements 改了核心包
4. 下一次啟動直接失敗

所以“啟動問題”和“插件問題”很多時候其實是同一件事，只是你從兩個不同階段看到了它。

有些“啟動失敗”其實是“部署失敗”

很多用戶會把首次安裝階段的問題也描述成“ComfyUI 啟動失敗”，但實際上 ComfyUI 可能還沒有進入穩定可運行狀態。

這類情況往往更早：

• 資源包還沒下載完就失敗
• ComfyUI-Manager 沒 clone 成功
• helper 文件或 bootstrap 可執行文件被攔了

如果你連第一次穩定啟動都還沒做到，先看這些頁面，再決定要不要修 Python 包：

• 部署失敗：下載資源包
• 部署失敗：安裝 ComfyUI-Manager
• Bootstrapper Missing (watchdog_bootstrapper_missing)

比散裝 shell 命令更好的恢復路徑

真正煩人的往往不是啟動失敗本身，而是修復路徑：

• 讀 traceback
• 試一個 pip install
• 重啟
• 再遇到另一個新錯誤
• 又改一個包
• 開始懷疑是不是該重裝

Wonderful Launcher 就是為這種階段設計的。

它更適合這些場景：

• ComfyUI Desktop 因插件變脆
• portable 環境隨著時間越來越漂
• 你想保留現有模型、工作流和設置，而不是從零開始

什麼時候該從自救切到啟動器原生修復

如果出現下面這些情況，繼續隨機 pip 安裝通常會更亂，應該先讓啟動器保留任務日誌並走原生修復：

• 啟動失敗發生在多輪插件修復之後
• Torch、CUDA、插件導入一起壞
• 你已經搞不清到底是哪次改動導致的
• 這是工作機、工作室機器，停機成本很高

Wonderful Launcher 能幫你什麼

Wonderful Launcher 更適合 環境已經開始脆弱 的階段： 它強調恢復、隔離和減少漂移，而不是單純再跑一串安裝命令。

下載 Wonderful Launcher

相關文檔

• 逐個修復 ComfyUI Portable 依賴損壞
• ComfyUI 提示 No module named 'sqlalchemy'
• ComfyUI Plugin Import Failed 怎麼修
• ComfyUI 依賴衝突
• ComfyUI Reconnecting Error
• ComfyUI 常見問題
• 故障排查決策樹

需要更快恢復？

如果你想走更引導式、更偏恢復的路徑，先從 Wonderful Launcher 檢查當前環境。 如果環境仍然卡住，保留任務日誌和啟動日誌後再聯繫支持。

參考來源

• ComfyUI 官方排障總覽
• ComfyUI 自定義節點排障
• ComfyUI 模型問題排障
• ComfyUI Desktop 安裝說明