ComfyUI v0.37.4 已有官方發布紀錄，但發布頁未列逐項變更，因此不能只憑版本號判斷既有工作流是否受影響，也不能推定升級後速度或輸出品質有所改變。自訂節點、Python 與 PyTorch 套件、GPU、模型路徑及啟動方式各異，同一版本在不同環境仍須分別確認。先核對能查到的版本差異，再對照工作流依賴並測試代表性流程，才有依據安排升級。
先前的 #881 已討論 ComfyUI 0.37.1 升級評估；這裡只將它作為背景，聚焦後續發布的 v0.37.4，不能把舊版討論當成本版變更。ComfyUI v0.37.4 官方發布頁
一、ComfyUI 0.37.4 更新，先確認版本差異落在哪一層
目前能直接確認的是 v0.37.4 這個發布標籤與版本發布紀錄；發布頁沒有逐項變更說明，因此不能據此斷言特定節點、插件或模型相容性已改變。
版本查核要先分辨「標籤存在」和「改了什麼」。官方發布頁是版本識別的第一手來源；要核對程式差異，應查看前一個標籤至 v0.37.4 的比較頁，不能從版本號自行推論。
官方標籤頁分別列出 v0.37.3 的提交 7240b5f 與 v0.37.4 的提交 8ff6dc3，可由前一版標籤頁及v0.37.4 發布頁核對。兩個標籤的程式碼比較可從官方比較頁查看；發布頁本身未附逐項變更說明。
比較程式碼時，先把差異按檔案和用途整理，再依變動範圍安排測試：核心或節點定義有變動，就找出使用相關節點的流程；前端有變動，檢查介面擴充與工作流載入；依賴設定有變動，核對套件版本。發布說明未列出的內容不能當成「沒有改動」，也不應將通用檢查項目寫成本版已確認的修正。
可以用一張簡單的差異紀錄表避免漏測，欄位包括「檔案或區域」「變更內容」「可能涉及的依賴」「要重跑的工作流」和「測試結果」。先將差異對應到自己安裝的功能；若某項變更與現有工作流無關，記錄判斷依據即可，不必為了涵蓋所有檔案而盲目重測。若差異涉及共用的節點介面或套件，則列出直接使用它的流程，並額外挑一個日常常用流程確認沒有連帶影響。
遇到比較頁載入不完整、差異範圍看不清楚，或無法判讀某個檔案用途時，先不要把猜測寫成版本結論。可查看同一專案的標籤與發布紀錄、搜尋變更檔名及相關功能文件；仍無法確認時，將該項標成待驗證，交由隔離環境測試。這種做法能區分「目前沒有查到差異」和「已確認沒有差異」，也避免把版本升級與自訂節點更新混為一次變更。
使用者可先記下工作流依賴的核心與自訂節點、前端擴充、外部套件和模型，再對照比較頁的檔案清單。無法確認影響時，將相容性留待測試，檢查流程能否載入、執行及產出。
找到特定檔案變動後，優先重測依賴該節點、前端擴充或套件的工作流。這能把版本差異連到個人環境，也有助於定位錯誤。以下檢查項目是通用升級方法，不能視為 v0.37.4 已確認的修正。
ComfyUI 分成伺服器端與客戶端：前者處理資料、模型與影像生成，後者負責介面。自訂節點可能只運作於其中一側，也可能同時涉及兩側，因此測試時要確認工作流能否執行、節點能否呼叫所需程式，以及結果能否保存。ComfyUI 官方自訂節點概述
“Comfy runs on a client-server model.” — ComfyUI 官方文件〈概述〉。伺服器端與客戶端分工不同，升級檢查應同時觀察執行與介面。
二、工作流相容性問題通常從哪些依賴形成
因為工作流所依賴的節點、套件、模型與硬體組合不同；版本標籤相同，不能代表所有環境都具備相同相容性。
先從工作流中使用的節點清單開始。核心節點由 ComfyUI 提供，自訂節點則由額外套件加入；有些只在伺服器端運算，有些會擴充前端介面，另一些需要兩端互相配合。更新核心程式時，即使工作流 JSON 沒改，自訂節點所呼叫的介面、輸入格式或前端擴充仍可能需要測試。若啟動時出現節點載入錯誤，先記下節點套件名稱與錯誤訊息，不要一開始就重裝全部依賴，否則難以找出真正原因。
Python、PyTorch、CUDA 或其他運算套件也會影響可否啟動和執行。這些元件的相依關係可能因作業系統、顯示卡與安裝方式而異；不能只把舊環境中的套件版本照抄到新環境，也不宜未留紀錄就直接更新套件。模型檔、LoRA（低秩適配模型）與其他資源的路徑同樣要納入盤點。若兩個環境指向不同模型目錄，測出的差異可能來自模型版本或檔案缺漏，不是 ComfyUI 版本本身。
工作流檔案也不一定包含完整環境描述。Comfy CLI 官方參考文件列有依工作流檢視節點依賴的功能，並提供環境快照的儲存與還原命令；這些工具可協助管理，但仍應以自己實際安裝方式與測試紀錄為準。Comfy CLI 官方參考
三、升級前如何建立可比較的測試基準
記下舊版 ComfyUI、執行套件、自訂節點、模型路徑、啟動參數與代表性輸入，並保留一份可重跑的工作流及輸出，才有比較基準。
先選幾個最常用、最能代表實際產出的流程，不必把所有存檔都拿來測。清單可涵蓋文字生圖、圖生圖、放大或其他常用任務；挑選原則是這些流程真的會用到不同節點和模型，而非單純追求數量。將工作流 JSON 與輸入圖另存一份，另外記下 checkpoint、LoRA、VAE 等檔案名稱與版本，以及輸出尺寸、採樣器、步數、提示詞和種子。
環境紀錄至少包括 ComfyUI 版本或 Git 提交、作業系統、GPU 型號、Python 與 PyTorch 版本、自訂節點清單、啟動參數，以及模型目錄設定。能以獨立資料夾、虛擬環境或另一台測試機複製舊環境時，讓新版先在隔離環境運作；若硬體或磁碟空間不允許，至少完整備份程式目錄、依賴清單與設定，確認舊版能按原方式恢復。
測試前先在舊版跑過同一批工作流，確認基準本身可用。記錄載入成功與否、是否有缺少節點、是否完成佇列、輸出檔是否存在，以及大致耗時。若舊版原本就有錯誤，就先修復或標記，否則升級後無法區分哪些問題是新引入的。
把測試結果分成「可用」「有差異但可接受」和「阻斷工作」三類，能讓更新決策不只依賴主觀觀感。可用代表流程載入、節點執行與輸出檔都符合用途；可接受的差異要記下具體項目，例如時間變化但成品規格不變；阻斷工作則包括必要節點無法載入、工作流中斷，或產出格式不符合交付需求。每個結論都附上版本、工作流名稱和日誌位置，日後重測才找得到相同條件。
若一個工作流涵蓋多種用途，可拆成最短的核心流程與完整產出流程各跑一次。核心流程用來快速確認啟動、載入與主要節點是否正常；完整流程則檢查實際會用到的擴充、模型、輸出位置和後處理。遇到失敗時先保存錯誤訊息與工作流副本，再從失敗節點往前檢查輸入，不要立刻改動原始流程。若問題只出現在新增或更新的依賴，記下該依賴版本與安裝方式，後續才有條件單獨重現。
四、升級前後如何比較節點載入與生成結果
讓前後測試使用相同工作流、輸入、模型與生成設定，再重跑異常項目；種子能固定時先固定，並把硬體和套件差異一併記錄。
先檢查啟動日誌與節點選單，確認自訂節點是否成功載入；接著開啟代表性工作流，查看是否有缺失節點、欄位改名或無法連接的輸入輸出。排入佇列後觀察是否完成、錯誤訊息出現在哪個節點，以及輸出尺寸、格式、檔案位置是否符合預期。介面正常顯示，並不能代替實際執行測試。
比較圖片時固定提示詞、輸入影像、模型與主要參數；若工作流支援固定 seed（隨機種子），就使用同一值。不同環境或運算設定可能造成輸出差異，單看兩張圖不同不能立刻判定回歸失敗。可以先查節點是否完成、構圖或尺寸等關鍵輸出是否偏離用途，再在相同環境重跑，確認差異是否可重現。記錄完成時間時也要保持硬體負載和流程設定接近，不以單次耗時宣稱新版更快或更慢。
若只有特定自訂節點報錯，就停用該套件或用乾淨測試環境逐項排查；不要同時更新 ComfyUI、所有自訂節點、PyTorch 與模型，否則即使問題消失，也找不到是哪個變更造成改善。每次只改一個變因，測試紀錄才能支援後續決策。
“Save a snapshot of the current ComfyUI environment.” — Comfy CLI 官方參考文件。環境快照可作為復原材料之一，仍須確認實際備份涵蓋程式、模型與自訂設定。
五、哪些情況適合更新，哪些情況應先觀察
日常試用環境可在備份後先行測試；若工作流正用於交付或依賴多個自訂節點，先在獨立環境通過回歸測試，再安排正式環境更新。
如果發布頁沒有列出具體變更，而現有環境又能穩定完成工作，單靠版本號沒有足夠理由立刻覆蓋正式環境。可先關注官方補充資訊與自訂節點維護者的相容性說明，再按自己的時程做隔離測試。遇到會影響產出交期的環境，測試時間也要算進更新決策：檢查不完整時保留舊版，比在工作進行中臨時修復更容易掌握風險。
若測試環境已能開啟全部代表性工作流、所需節點正常載入、輸出符合用途，且新舊差異已查明或可接受，就可以規劃更新。若有關鍵節點無法載入、輸出尺寸或檔案格式不符，或錯誤無法穩定重現，應暫緩切換並保留日誌。更新決定應依自己的工作流與硬體條件制定，不必套用相同結論。
六、升級後異常時如何回到可用環境
先停止在正式環境繼續改動，依備份還原原先程式與依賴，並確認模型路徑及設定一致；只退回程式版本但沿用已變更的套件，不一定能恢復原狀。
回退前先保留新版的錯誤日誌、版本識別與測試結果，這些資料有助於判斷問題來自核心程式、自訂節點，還是 Python、PyTorch 等環境。接著切回原本可用的程式版本或環境快照，核對啟動參數、模型路徑、自訂節點狀態，再用同一組代表性工作流確認是否恢復。若模型資料夾獨立存放，回退時通常不必重下載模型，但仍須確認檔案沒有被移動、改名或覆寫。
不要把唯一可用的安裝直接升級後，再期待單一版本號就能完整還原。保留舊環境的目的，是讓工作可以先恢復；根因分析則在恢復後進行。確認問題並修正測試環境，再決定是否另擇時間更新正式產出環境。
用依賴與回歸測試決定更新時機
先確認官方提供的版本差異，再以自己的節點依賴、工作流測試結果與回退條件決定更新時機。
確認與自己依賴相關的差異已查明、代表性工作流通過節點載入與輸出測試、舊環境能按紀錄回復，才安排正式環境更新。三項條件有一項未完成，就先保留目前可用的環境，補齊測試或回退準備後再決定。
- 先查官方版本資訊；未列出的具體變更不要自行推斷。
- 自訂節點、Python、PyTorch、模型路徑與硬體都可能影響測試結果。
- 用相同輸入與設定比較升級前後，對異常項目逐一重測。
- 正式產出環境先留可恢復的舊版，再依實測結果安排更新。
常見問題
Q1：ComfyUI v0.37.4 發布，代表舊工作流一定要更新嗎？
不一定。先確認發布資訊是否提到與自己使用的節點或依賴有關，再以備份和隔離測試決定是否更新。
Q2：升級後工作流顯示缺少節點，代表工作流檔壞了嗎？
不一定。可能是自訂節點未安裝、載入失敗或環境未啟用。先從啟動日誌確認節點套件與錯誤訊息，再用原始工作流測試。
Q3：固定 seed 後，升級前後圖片不同就是錯誤嗎？
不能只憑圖片不同判定。還要核對模型、輸入、套件、硬體與精度設定，並重跑確認差異是否可重現、是否影響實際用途。
Q4：回退 ComfyUI 程式版本就足夠了嗎？
不一定。若升級時也改了 Python 套件、自訂節點或設定，回退程式版本未必能還原原環境；應依備份一併恢復相關依賴與設定。
參考資料
- Comfy-Org. (2026). Release v0.37.4. https://github.com/Comfy-Org/ComfyUI/releases/tag/v0.37.4
- Comfy-Org. 概述. https://docs.comfy.org/zh/custom-nodes/overview
- Comfy-Org. 參考. https://docs.comfy.org/zh/comfy-cli/reference
