痛点：流程一复杂，脚本和表单都扛不住
扩散模型的工作流一直不好表达：模型、采样器、ControlNet、LoRA、后处理，环节多、组合多，纯脚本写死了难调参，表单式 WebUI 又画不出分支和多阶段流程。ComfyUI 的做法是把流程画成图：每个节点是一个功能单元，边表示数据流，整张图就是一次可复现的工作流。仓库自述为「扩散模型 GUI + api + backend，配 graph/nodes 界面」——同一份图既能在界面上编，也能被外部程序调用。主语言 Python，Topics 含 pytorch，跑起来依赖 GPU 推理栈。它的主工作区就是那张连好线的节点图。
数字与口径
仓库 Comfy-Org/ComfyUI 创建于 2023-01-17，最近一次推送是 2026-10-19；累计 139,345 stars、16,548 forks、344 位贡献者、5,270 个 open issues，许可证 GNU GPL-3.0。近四年持续活跃，说明采用是长期积累，不是一次性曝光。
两点需要记录：一是 watchers 与 stars 数值完全相同（都是 139,345），按 GitHub API 的惯例，watchers 字段和 stars 本来就同值，真正的订阅数要看 subscribers，所以这不算异常，只是别把它当成独立指标；二是 README 的 release 徽章链接指向 comfyanonymous/ComfyUI，而元数据全名是 Comfy-Org/ComfyUI，口径存在不一致。
至于「为什么是现在」——素材里没有新闻或事件线索，无法归因到某个近期事件。较合理的解释是长期复利加榜单效应（排名靠前就被持续发现），这属于推断，不是证实。
架构、安装、接口：公开材料缺失
必须说清楚：我们拿不到架构层材料。第三方解析的两条路径都断了——DeepWiki 返回 Vercel 安全校验页而非内容，CodeWiki 页面 404。因此只能依据仓库元数据做粗粒度判断：系统至少分为图形界面、API 层、执行后端三层，围绕同一份节点图工作，数据流形态是「图 → 拓扑执行 → 输出」。节点类型体系、执行调度、缓存与类型校验、模型加载与显存管理，均无素材，不做推测。
安装同样缺：提供的 README 在 release 徽章定义处被截断，没有安装命令、依赖要求、硬件门槛。可见线索只有四枚徽章（版本号、发布日期、总下载量、最新版下载量）加官网、Discord、Matrix、X 四个入口，据此推断官方以 GitHub Releases 分发预构建包——这是推断。
用法能确定两种形态：在图形界面里连节点搭工作流；通过 API 层把工作流接入自有工具链。具体的 REST/WebSocket 接口与 CLI 参数，素材未覆盖。
采用前最该看的两条风险
一是许可证。GPL-3.0 是强 copyleft，对希望闭源分发、或把引擎嵌进商业产品的团队构成实质合规约束，这条在选型时最容易被低估。
二是维护带宽。5,270 个 open issues 对 344 位贡献者，triage 压力不小。
可以带走的一个判断
适合：个人或小团队做多阶段、要可复现、要程序化调用的生成流程。别用：需要闭源分发或嵌进商业产品的场景，除非先过法务，或者上游给出双许可/商业例外。
值得盯的不是 star 数
如果节点图真成了跨工具流转的资产，竞争就从模型权重上移到编排层——决定胜负的是图的可移植性与生态规模。但一个 GPL-3.0 项目要承接商业化（托管、企业版、桌面端、节点市场），开放扩散与商业闭环之间存在结构性张力。所以接下来该看三件事：许可证会不会调整或加双许可/商业例外、API 层会不会给出有版本承诺的对外契约、open issues 相对贡献者数的走势。这几点才决定它长期停在「一个好用的工具」，还是升级成「一层平台」。
本文可信度说明：信息仅来自项目自身 README（且被截断）与仓库元数据，属单一来源；架构、安装、生态集成与商业化部分要么缺失，要么已明确标注为推断。
报错到音视频方案)
