第一步：定位根因——"必须传三张"不是配置问题，是代码本来就没实现
我先看了后端 main.py 的链路（run_workflow → generate）。
系统里其实早就设计好了"未传图自动剪枝"这个功能——工作流的 config 里有 optionalImageMode: prune-workflow 这个字段。但我顺着代码一路查下来，发现 这个 prune-workflow 从来没有被真正实现过：它只是被存着、从没被消费。
原来的逻辑是：前端把图片覆盖进工作流 → 直接丢给 ComfyUI。没传的 LoadImage 节点 image="" → ComfyUI 遇到空图直接报错。所以你不传满三张就崩。这也推翻了我之前说的"空插槽安全"——标准 LoadImage 空图确实会炸。
第二步：真正把"剪枝"写出来
我在 main.py 的 generate 函数里加了一段逻辑（17484 行附近）：
发送工作流给 ComfyUI 之前，凡是 class_type=="LoadImage" 且没图的节点，连同它在 TextEncodeQwenImageEditPlus 上的 image2/image3 引用一起删掉。
逻辑是反推的：先找出所有"空图"的 LoadImage 节点（节点 8/17/19），再扫所有节点，谁的输入引用了这些空图节点就把那个输入清掉（不是删节点本身，是断引用）。这样：
传 1 张 → 只留图1，图2/图3 节点和引用全删
传 2 张 → 留图1+图2
传 3 张 → 全留
我还写了个模拟测试，1/2/3 张都验证通过。同时把之前临时断开的 image3 连线恢复回去，让第三张图也能用。
第一步：定位根因——"必须传三张"不是配置问题，是代码本来就没实现
我先看了后端 main.py 的链路（run_workflow → generate）。
系统里其实早就设计好了"未传图自动剪枝"这个功能——工作流的 config 里有 optionalImageMode: prune-workflow 这个字段。但我顺着代码一路查下来，发现 这个 prune-workflow 从来没有被真正实现过：它只是被存着、从没被消费。
原来的逻辑是：前端把图片覆盖进工作流 → 直接丢给 ComfyUI。没传的 LoadImage 节点 image="" → ComfyUI 遇到空图直接报错。所以你不传满三张就崩。这也推翻了我之前说的"空插槽安全"——标准 LoadImage 空图确实会炸。
第二步：真正把"剪枝"写出来
我在 main.py 的 generate 函数里加了一段逻辑（17484 行附近）：
发送工作流给 ComfyUI 之前，凡是 class_type=="LoadImage" 且没图的节点，连同它在 TextEncodeQwenImageEditPlus 上的 image2/image3 引用一起删掉。
逻辑是反推的：先找出所有"空图"的 LoadImage 节点（节点 8/17/19），再扫所有节点，谁的输入引用了这些空图节点就把那个输入清掉（不是删节点本身，是断引用）。这样：
传 1 张 → 只留图1，图2/图3 节点和引用全删
传 2 张 → 留图1+图2
传 3 张 → 全留
我还写了个模拟测试，1/2/3 张都验证通过。同时把之前临时断开的 image3 连线恢复回去，让第三张图也能用。