子图与模板复用:工作流的组件化

一句话定义

子图(Subgraph) 是 2025 年中引入的组件化能力:选中一段节点 → 转换为一个带输入输出端口的"自定义节点",可发布到节点库复用(0.3.63 起支持发布);配合模板库与工作流库,让工作流从"一次性画布"升级为"可积累的组件系统"。

为什么重要

工作流复杂到 50+ 节点时,可读性崩塌;组件化(子图)+ 复用(模板/节点库)是管理复杂度的官方答案——把"放大管线""人像精修"沉淀为标准件,新项目组装而非重画。时效注:该能力于 2025-06 引入并逐步增强,替代旧的 Group Node 机制。

前置知识

界面导览：画布、侧栏、队列与模板(界面与侧栏)。

核心概念

• 创建子图:框选节点 → 右键 Convert to Subgraph;引擎自动识别被外部引用的端口,生成子图节点的输入/输出。
• 进入编辑:双击子图节点展开内部视图,改内部不影响外部连线。
• 发布到节点库(0.3.63+):子图 → Publish,成为可跨工作流搜索/拖放的"个人自定义节点";节点库与模板库都在左侧边栏。
• 模板库:官方按场景维护的成品工作流(文生图/Flux/视频/控制);载入即改,是学习结构与工程化范式的教材。
• 工作流库:自己保存的 json 集合,支持命名/搜索/收藏。

原理与机制

子图本质是图嵌套(graph-in-graph):外层图把子图当普通节点调度,内层图保持独立拓扑与缓存——组件级缓存粒度使"改内层一处"只重算相关子图。发布到库的子图带元数据(名称/描述/端口),复用即实例化。对比旧 Group Node:子图解决了"组内端口定义混乱、嵌套受限、无法跨工作流共享"三大痛点。

外层:  [Load] ─▶ [商品主图管线(子图)] ─▶ [放大管线(子图)] ─▶ [Save]
                └ 内部: 抠图→重绘→精修…(独立缓存与拓扑)

直观类比

子图是把一段代码重构成函数:长画布像千行脚本,Convert to Subgraph = 抽函数(定好入参/返回值),Publish = 放进个人函数库,下个项目 import。模板库则是官方代码示例集。

实例与案例

• 沉淀你的"放大标准件":把 高清放大(Upscaling):两条路线与取舍 的放大管线(放大器+Ultimate SD Upscale+tiled)做成子图发布;以后任何项目拖入即用,参数(倍率/tile)留在子图节点上。
• 团队协作:资深成员维护"人像精修子图",其他人只拖组件调参数——降低整队使用门槛。
• 学习新模型:先跑官方模板 → 用子图把不关心的段落折叠 → 快速定位"这个模型真正改变了哪几个节点"。

常见误区

• 什么都做成子图:两三个节点的段落抽子图反而增加跳转成本;按"独立功能块+会被复用"两个标准。
• 旧 Group Node 混用:老工作流里的 group node 会被提示转换;混用易出渲染与执行怪相,导入后先转换。
• 子图内埋死参数:常调参数应暴露为子图输入/widget;埋在里面每次要进内层改,复用价值归零。
• 以为发布=分享给别人:发布到的是本机节点库;跨人分享仍靠导出 json(含子图定义)或社区发布渠道。

自测题

1. Convert to Subgraph 自动做了什么?端口如何确定?
2. 子图与旧 Group Node 的三大差异?
3. 什么样的段落值得抽子图?反例是什么?
4. 子图的缓存粒度带来什么性能收益?

与其他知识点的关系

• 工作流 JSON 与 API 自动化:子图让 API 侧的 JSON 结构更模块化(组件 id 对应一段执行子图)。
• 高清放大(Upscaling):两条路线与取舍/局部重绘(Inpainting):只改该改的地方 是最适合沉淀为子图的标准管线。
• 界面导览：画布、侧栏、队列与模板 的侧栏(节点库/模板库)是本页的操作载体。

延伸阅读

• 官方公告 "Introducing Subgraphs" 与 0.3.63 发布说明:blog.comfy.org
• 模板库:界面左侧 Templates 标签