前阵子我调一个对比工作流把两组生成结果分别接进 Image Comparer在 rgthree 分类下Queue 跑完节点区域干干净净连条多余的线都没有。我当时的第一个反应是插件坏了准备直接重装。冷静下来从日志开始查才发现“无输出”这几个字背后藏着好几种完全不同的故障处理方式天差地别。这篇文章就把我这次排查过程完整拆开从“节点在但不出图”到“节点变红、端口消失”再到“Queue执行到一半报错”先教你给现象分类再按链路一步步定位上游数据有没有问题、插件到底加载没有、前端是不是在骗你、版本是不是互相打架。ComfyUI rgthree-comfy 这套组合里Image Comparer 是很多人用来做结果对比的常用节点尤其适合同一个 prompt 换 seed、不同模型风格并排看细节之类的场景。如果你也在用整合包、又被“节点不输出”搞到怀疑人生这篇文章可以直接照着走一遍。先说结论大多数“无输出”不是节点坏了而是我们对节点身份的误解或者排查链路没有先切开。1. 先说清楚“无输出”到底指的是哪种现象1.1 三种常见的“无输出”表象“无输出”不是单一故障我自己的处理习惯是先给现象分类否则一上来就重装插件十有八九白折腾。现象 A节点还在画布上连线也对Queue 之后节点内部没有任何图像下游也没有可接力的数据。这是最常见的“节点在结果空”。现象 B画布上这个节点显示成红色块名字后面带着问号端口不完整甚至完全看不到端口。这其实不是无输出是当前环境里这个节点类型压根没有注册成功。现象 CQueue 执行到相关位置直接停下来控制台抛出一片红色报错输出自然也不存在。这属于“执行中断”和“节点安静地没输出”是两码事。现象最可能的方向建议先看章节节点在、连线正常、节点内空白节点本身定位、前端显示、上游数据第 4、5 章节点变红、端口缺失、名称带问号插件加载失败、版本不兼容第 3 章Queue 执行报错中断上游数据、显存资源、节点返回 None第 2 章先把现象对号入座后面排查才有方向。我见过不少人把“执行报错”当成“无输出”来修折腾半天插件最后发现是显存爆了。1.2 为什么大家默认它应该“输出”一张图这就要说到 ComfyUI 的思维惯性了。在这个工具里几乎每个节点都有输出端口图像从生成到保存总有一个“末端节点”于是很多人天然认为 Image Comparer 也负责“出图”。加上很多分享出来的工作流里它往往被画在整条链路的末端还用虚线框强调了“在这里对比两张图”新手很容易误以为它就是最终输出节点。另一个很实际的视觉陷阱是Image Comparer 的预览区域在节点内部。节点刚创建时尺寸不大如果你没把它拉大或者页面缩放比例比较小那个内部预览区可能被压缩到几乎看不见看起来就像“没有输出”。所以遇到“无输出”我的第 0 步永远是拿鼠标拖一下节点边缘把它放大看看里面到底有没有图。如果放大了还是空白再往下查。记住这个原则先分现象再找原因。接下来我按照最合理的排查链路把每一层都过一遍。2. 从上游倒查的完整排查链路先把锅从 Comparer 身上拿开2.1 在输入端前面加 Preview Image一刀切问题边界排错的本质是缩小范围。Image Comparer 这个节点接收的是图像数据我们需要先确认一件事到达它输入端口的图像到底有没有问题。具体操作很简单不用改任何生成逻辑在 Image Comparer 的 image_a 输入端前面接一个内置的 Preview Image 节点然后把 Preview Image 的输出再接回 Comparer 的 image_a 端口。用同样的方法在 image_b 输入端前面也接一个 Preview Image。整体 Queue 一次先不看 Comparer只看刚才加的两个 Preview Image 有没有正常显示。判断结果就四种两个 Preview 都有图说明从模型生成到 VAEDecode再到 Comparer 输入端口这一整条链路全部正常。问题几乎可以锁死在 Comparer 自身或者前端渲染层。某一路 Preview 没图说明问题在上游可能是那一分支的节点被跳过、返回了 None或者某个中间节点内部报错但被静默处理了。两路都没有图优先检查公共上游比如 Checkpoint、KSampler、VAE Decode 是否正常或者干脆是显存不够导致整条链中断。Preview 有图但 Comparer 依然空白那就不是数据问题跳到第 4、5 章去检查节点定位和前端显示。还有一个前置注意事项Image Comparer 的输入端接的是 VAE Decode 之后的图像张量不是 latent 数据。如果你误把 KSampler 的 latent 输出直接接到了 Comparer它大概率不会展示任何东西。这种错误在初学者工作流里很常见因为它不一定会报错只是安静地空白。2.2 检查 MUTE、Bypass 与红色报错数据链路正常不代表节点真的执行了。ComfyUI 里如果某个节点被静音或者跳过连到它上面的线会变成虚线节点上会有明显的状态标记。特别是用了 rgthree 的 Fast Groups Bypasser / Fast Groups Muter 之后一键就可以把一大组节点全部跳过有时候你自己都不记得什么时候误触过。检查一下从上游到 Comparer 之间的连线如果哪一段是虚线优先把状态恢复回来。被跳过的节点不会执行自然不会有输出这和节点故障是两回事。接下来看控制台。ComfyUI 启动时那个终端窗口里Queue 之后出现任何异常都会打印出来。典型的有这几类CUDA out of memory. Tried to allocate ...显存不足后面所有生成节点都可能“无输出”。Error occurred when executing ImageComparer: NoneType object has no attribute shape比较常见上游某个节点在异常分支里返回了 NoneComparer 拿不到有效数据。各种TypeError、ValueError指向具体节点名称根据报错里的名字回上游找问题。记住一个排错原则先解决红色报错再谈无输出。很多“无输出”只是执行中断的结果把报错修掉图自然就出来了。如果日志里没有任何错误但 Comparer 还是空白再继续往下走。3. rgthree-comfy 自身没有正常加载的情况3.1 先确认插件真的被加载了有时候问题根本不在工作流而在插件本身没有成功加载。这里要纠正一个误区ComfyUI Manager 里显示“已安装”不代表这个插件被成功导入。Manager 只会看目录里有没有对应文件夹但导入过程可能因为依赖缺失、代码不完整、版本不兼容而失败。最快的方式是看启动日志。ComfyUI 每次启动都会打印自定义节点的导入时间列表大概长这样Import times for custom nodes: 0.3 seconds: C:/ComfyUI/custom_nodes/rgthree-comfy如果这个列表里根本没有 rgthree-comfy说明插件目录没有被识别或者导入失败被跳过了。再往下翻有时候会直接看到Cannot import rgthree-comfy或者一段 traceback。另外一个确认方法是在画布空白处右键搜索“Image Comparer”或者“rgthree”。搜得到说明节点已注册搜不到说明插件没加载。如果你的工作流里节点已经变成红块、名字后面带问号那几乎可以断定是节点类型没注册。顺便说一句ComfyUI 自动保存的工作流使用的是节点注册名比如ImageComparer (rgthree)。如果换了一个不带这个插件的环境打开工作流就会出现红色未知节点。所以这类“无输出”其实很多时候是环境不匹配不是插件坏了。3.2 最常见的四种加载失败原因我根据实际排查经验把 rgthree-comfy 加载失败的原因归纳成下面四类命中率很高原因典型表现解决方向目录放错custom_nodes 下找不到或在错误路径移动到ComfyUI/custom_nodes/rgthree-comfy目录嵌套了两层custom_nodes/rgthree-comfy/rgthree-comfy保留单层目录删掉多余嵌套同目录存在多个副本日志重复导入或前端节点混乱只保留一份其余备份后移除版本不兼容ComfyUI 核心太旧或太新升级核心或回滚 rgthree 版本其中“目录嵌套两层”是我见过最多的情况。很多人从 GitHub 下载 ZIP 后直接解压结果发现 custom_nodes 下面套了一层同名文件夹ComfyUI 扫描时找不到真正的入口文件插件就静默失败了。穿透到秋叶整合包这类环境也一样整合包本身不会帮你处理这种目录问题。另外要留个心眼如果你之前手动下载过旧版后来又用 ComfyUI Manager 装了一份新的custom_nodes 里可能同时存在两个 rgthree 相关目录。两个版本冲突时前端可能加载到旧的那份表现也很像“节点无输出”。3.3 手动重装的正确姿势确认是插件加载问题后重装要按顺序来不要直接删目录。先备份再动手。cd ComfyUI/custom_nodes mv rgthree-comfy rgthree-comfy.bak git clone https://github.com/rgthree/rgthree-comfy.gitWindows 用户没有 git 的话可以从 GitHub 的 Code 按钮下载 ZIP解压后必须保证路径是custom_nodes/rgthree-comfy里面直接是插件代码而不是再套一层同名目录。装完重新启动 ComfyUI再次看日志里的Import times for custom nodes确认 rgthree-comfy 出现在列表中。然后一定记得做一次浏览器强制刷新这一步很多人会漏掉我在第 5 章会专门讲。备份的好处是如果新版反而有问题可以随时把.bak改回来一分钟恢复原状。这条经验救过我很多次不建议跳过。4. Image Comparer 的真实身份它是比较器不是输出器4.1 节点设计目标与 UI 交互到了这一步需要直面一个很多人不愿意接受的事实Image Comparer 在大多数版本里本来就不往下游传图像。它不是一个“生成图”或者“导出图”的节点而是一个观察型节点。rgthree-comfy 里这类节点的作用是把多张图并排展示在一个界面中方便你对比细节。你可以在节点内部的预览区看到 A/B 两组图支持缩放、拖拽、平移鼠标滚轮推近推远专门用来看模型的细节差异。这个设计目标是“辅助判断”不是“继续参与后续计算”。所以当你把它放在工作流末端期待它像 Save Image 一样吐出最终图片时它当然“无输出”——因为它压根没有图像输出端口可以接下游。教程里所谓的“在这里输出对比结果”指的是它在界面里展示对比画面并不是给其他节点读取的数据。这个认知不到位后面所有排查都容易跑偏。换一个角度理解Image Comparer 在 ComfyUI 里的角色就像打印机旁边的显示器你可以指着屏幕跟别人讨论效果但把文件真的拷出来还得靠打印机。4.2 想真正“输出对比图”可以这样替代如果确实需要一张可以保存、分享、继续处理的对比图我的建议是换一种组合方式。方案一双路 Save Image。在生成链路的末端接两个 Save Image 节点分别保存两张图然后到外部看图软件里对比。最简单但效率一般多了两张零散文件。方案二拼接节点合成一张后再保存。用内置的 ImageConcatenate 或 Impact Pack 里的拼接节点把 A/B 两张图并排拼成一张再接 Save Image。这样最终只有一个文件查看缩略图、发群、存档都方便。注意拼接方向别竖着拼否则对比时上下滚动很别扭。方案三Comparer 只管看保存节点各存各的。也就是说同一路输出分叉到两个节点一个进 Image Comparer 供你人眼对比一个进 Save Image 落盘。两边互不干扰既保留了节点内的交互体验又拿到了实际文件。我自己目前常用方案二。尤其是调试同一个 prompt 不同 seed 的差异时拼接图直接扔进文件夹文件名按 seed 标好回头整理素材特别舒服。如果只是临时看效果就直接用 Preview Image压根不碰 Comparer 也完全没问题。5. 前端渲染层面的三个隐蔽坑缓存、JS 资源与显示区域5.1 浏览器缓存和旧前端资源ComfyUI 的插件不只有 Python 后端逻辑很多还带前端 JS 代码rgthree-comfy 就是典型。插件更新之后后端加载的是新代码但浏览器可能还在用旧的 JS 缓存表现就是节点看起来行为奇怪、预览区域渲染异常。处理方式很简单浏览器里按CtrlShiftR强制刷新或者打开开发者工具的 Network 面板勾选 Disable cache 再刷新一次。如果远程部署、前面还隔着一层 nginx 之类的反向代理记得代理层也要清缓存否则前端资源照样是旧的。这里还要强调一个操作顺序先重启 ComfyUI 后端再清浏览器缓存。如果你只刷新浏览器不重启后端前端拿到的还是旧的静态资源。反过来只重启后端不刷新浏览器也是白搭。顺序错一步就可能把正常插件误判成坏的。5.2 预览区域与节点显示问题第三种前端坑真的就是纯粹的显示问题。Image Comparer 的预览区域在节点内部节点初始高度不大有时候你看到的是一块看起来什么都没有的灰板但你把节点边缘拖大之后图就出来了。检查时顺手看一眼浏览器页面的缩放比例如果缩放得太小节点内部的 canvas 区域可能没有被正确渲染。还有如果你同时装了多份 rgthree 副本前端可能加载到错误版本导致节点类型虽然存在行为却不对。这种情况回到第 3 章清理重复副本即可。说句实在话我排查“Image Comparer 无输出”遇到最多的反而不是什么高深问题而是节点太小、缓存没清、上游根本没出图这三件事。先排除这三个再往深处挖。6. 最后的兜底方案最小工作流复现、重装与版本回滚6.1 用最小复现工作流定位是全局还是单节点如果前面几条都没解决说明问题藏得比较深。这时候最有效的方法是搭一个最小复现工作流把所有无关变量全部砍掉。最小复现工作流就三个节点两个 Load Image 分别加载两张本地图片分别接到 Image Comparer 的 image_a 和 image_b。不加载模型、不跑采样、不接任何插件只留这一个 rgthree 节点。Queue 一次看 Comparer 能不能正常展示。如果最小工作流正常说明问题不在插件而在你原工作流里的某些分支或节点组合。接下来逐步把原工作流的分支加回来看加到哪一步开始空白问题就定位了。如果最小工作流也是空白那就基本锁定是环境问题插件加载、前端缓存、版本兼容。这时候再考虑重装和回滚。有人觉得搭最小工作流麻烦其实这才是最快的路径。一次测试能同时排除上游数据、模型路径、第三方插件冲突、节点组合的问题省下的时间远超搭节点那两分钟。6.2 重装与版本回滚的正确顺序重装第 3 章已经讲了这里重点说版本回滚。rgthree-comfy 更新很频繁不一定每个新版本都兼容你当前的 ComfyUI 核心。出现升级后节点消失、无输出、连端口都变化的情况回滚到旧版本通常能救回来。cd custom_nodes/rgthree-comfy git log --oneline -10先看最近的提交记录挑一个你印象中“能用”的版本直接切过去git checkout 98d8f3a然后重启 ComfyUI强制刷新浏览器测试。如果一切正常就用git checkout main或git switch main回到最新分支等未来插件更新后再试。还有一个非常重要的升级纪律不要一次性点击 ComfyUI Manager 里的 Update All。我踩过一次坑核心、所有插件一起更新结果一批节点全部失效最后只能从备份里恢复。正确的顺序是先备份当前可用环境再单独升级 ComfyUI 核心刷新测试确认没问题再按需升级单个插件。插件升级也遵循同样的“先备份、改一个、验证一个”的节奏。6.3 我习惯的最终排查组合如果你问我现在遇到 Image Comparer 无输出会怎么走我会给你一套固定的组合拳先拖大节点看是不是显示问题再打开启动日志确认插件加载列表然后在 Comparer 前面插 Preview Image 分割问题边界最后才用最小工作流和版本回滚收尾。这套顺序不针对具体某一个故障而是用来快速收敛范围。你会发现大多数“无输出”在显示层和上游数据层就被解决掉了真正需要重装插件的情况其实很少。反过来如果你一上来就重装运气好可能凑巧修好但大概率会浪费半小时还把环境搞乱。我自己在这套流程里收获最大的一点是遇到问题先记录版本号再去日志里找关键字最后才动手升级或者回滚。ComfyUI 的生态插件更新太快没有版本记录出问题后连“哪一步变坏”都无迹可寻。保持这个习惯之后这类节点故障对我的干扰就小多了。