Fooocus：把 Stable Diffusion 做成一键出图的极简界面

开篇：模型选型变简单了，外壳选型变难了

做图像生成应用，模型层面的选择其实已经收敛——SDXL、Flux、SD3.5 就那么几个。真正耗时间的是外壳：你要给终端用户一个点两下就出图的界面，还要给后端一条能塞进 CI 的接口。

Stable Diffusion 的 Web UI 生态覆盖了从"零参数"到"全图编排"的整条光谱。Fooocus、AUTOMATIC1111 WebUI、ComfyUI、InvokeAI 都能出图，但它们的产品假设完全不同。选错的代价不是重装一次，而是几周的胶水代码和一堆维护不动的自定义节点。

竞品全景

Fooocus：把 Stable Diffusion 做成一键出图的极简界面

作者 lllyasviel（ControlNet 作者），Python 实现，GPL-3.0，53,257 Star、8,629 Fork，最近提交 2025-12-01。它的核心主张写在简介里：Focus on prompting and generating。界面只有一个提示词框加一个生成按钮，采样器、CFG、Refiner 切换点、高清修复策略全部由上游固化好的 preset 决定。它更像一个成品应用，而不是一个可编排的框架——没有插件市场，这是设计选择，不是缺陷。

AUTOMATIC1111 Stable Diffusion WebUI

AGPL-3.0，Python，十万量级 Star。生态最厚的那个：ControlNet、LoRA、区域提示、面部修复、Tiled Diffusion 全都有现成扩展。代价是参数面板极其庞大，配置漂移严重，不同插件的版本组合经常互相打架。它的 REST API（/sdapi/v1/txt2img）是事实上的行业接口之一。

ComfyUI

GPL-3.0，Python，十万量级 Star。基于节点计算图，把采样、编码、ControlNet、后处理全部显式建模成 DAG。控制力最强，学习曲线最陡，custom node 生态规模巨大但也存在明显的依赖地狱。生产流水线场景下几乎是默认选项。

InvokeAI

Apache-2.0，数万量级 Star。定位偏专业创作：统一画布（Unified Canvas）、图层式局部重绘、队列化管理。工程化程度高，协议是对闭源商用最友好的一个。

对比维度

我按这几条来看：上手成本（从克隆到出第一张图的时间）、控制粒度（能不能精确干预每一步）、自动化接口（能不能被别的程序驱动）、扩展生态（插件数量与可维护性）、显存与性能（低配设备能不能跑）、协议与商用（能不能进闭源产品）、社区活跃度（出问题时有没有人回答）。

核心对比

深度分析

差异一：Fooocus 把调参经验编译成了默认值

别的地方让你选采样器，Fooocus 直接给你一个 presets/default.json。这是它真正的产品形态：

{
  "default_model": "juggernautXL_v8Rundiffusion.safetensors",
  "default_refiner": "None",
  "default_refiner_switch": 0.5,
  "default_cfg_scale": 4.0,
  "default_sample_sharpness": 2.0,
  "default_sampler": "dpmpp_2m_sde_gpu",
  "default_scheduler": "karras",
  "default_performance": "Speed",
  "default_styles": ["Fooocus V2", "Fooocus Enhance", "Fooocus Sharp"]
}

这套默认值来自作者对 SDXL 的实测调优（低 CFG、sharpness 补偿、Refiner 切入点在 0.5 附近）。你换掉的每一个值，大概率是把它调差。同类项目的默认配置通常是"能跑就行"，Fooocus 的默认配置是"已经调好了"。这就是它值得被单独拿来选的原因。

差异二：自动化接口决定了它能进什么系统

A1111 的接口是一层薄 REST，字段平铺，适合脚本批量调用：

requests.post(f"{base}/sdapi/v1/txt2img", json={
    "prompt": "a cat, cinematic light",
    "steps": 30, "cfg_scale": 4.0,
    "width": 1024, "height": 1024,
    "override_settings": {"sd_model_checkpoint": "juggernautXL"}
})

ComfyUI 交出的是整张计算图，节点 ID 就是键，连线即依赖：

{
  "3": {"class_type": "KSampler",
        "inputs": {"seed": 42, "steps": 30, "cfg": 4.0,
                   "sampler_name": "dpmpp_2m",
                   "scheduler": "karras", "denoise": 1.0,
                   "model": ["4", 0], "positive": ["6", 0],
                   "negative": ["7", 0], "latent_image": ["5", 0]}}
}

这个差别直接决定架构：前者你可以用十行代码包成一个微服务；后者你要么把工作流文件当版本化产物管理，要么接受"每次改流程都要动图"。Fooocus 在这条轴上偏弱——它暴露的是 Gradio 接口，字段名和 UI 状态绑定，官方也没把它当自动化后端来设计。要把 Fooocus 塞进批量流水线，基本等于绕过它自己写调用层。

差异三：插件生态是资产也是负债

A1111 和 ComfyUI 的扩展能力极强，但扩展是跟着上游 API 走的。上游一改签名，几十个插件同时挂掉；ComfyUI 的 custom node 还要锁 torch 版本，装三个以上就可能开始解依赖冲突。Fooocus 没有这个问题——因为它压根没给你插口。这是一个明确的取舍：用可扩展性换掉了升级时的心智负担。

按场景选型

• 个人 / 小工作室，只想输入提示词就出片，显存 8GB 以下 → Fooocus。开箱质量最稳，省下的调参时间远超它缺失的功能。
• 已有大量提示词模板和参数积累，需要 ControlNet、区域提示、面部修复等具体插件 → A1111（或它的性能分支 Forge）。接口成熟，插件能直接复用。
• 要复现多步流水线、做节点级控制、把生成过程接进生产队列 → ComfyUI。工作流即 JSON，天然可版本化、可调度。
• 团队席位的画布式精修，或要把生成能力集成进闭源商业产品 → InvokeAI。Apache-2.0 省掉 GPL/AGPL 的法务讨论。

结语

我会把 Fooocus 推荐给"要尽快产出可用图像、且不打算把生成逻辑做成平台"的人。它的价值不在功能数量，而在于把 SDXL 的调参经验固化成了默认行为，让非算法背景的人也能稳定出片；53,257 Star 和 8,629 Fork 说明这套取舍被大量人接受，最近提交 2025-12-01 也表明仓库没有停摆（不过判断活跃度请看提交密度与 issue 响应，而不是单个日期）。

但如果你需要以下任何一项，就别选 Fooocus：需要 API 驱动批量生产、需要堆叠 LoRA 与 ControlNet 做精细控制、需要把功能分发到闭源产品、或者需要一套能随模型演进持续扩展的流程引擎。这些场景下 ComfyUI 或 InvokeAI 是更正确的起点，A1111 则是插件覆盖面的折中解。Fooocus 是终点式的产品，不是起点式的框架——把它当框架用，你会绕很大一圈。