启用 ComfyUI-Manager 与它的三个开关

装完 ComfyUI 之后想装自定义节点，大部分人第一反应是找 Manager。但在 ComfyUI v0.31.0（2026-08-08）上，Manager 不是开箱即用的：它是一个扩展，官方 README 给的做法是先装依赖，再用一个命令行开关把它启用。更容易被忽略的是，围绕它一共有三个 flag，彼此之间还有隐含和依赖关系——搞不清楚这三者，你会遇到「明明加了参数却没生效」或者「以为关掉了其实后台还在跑」这类问题。

这篇只讲一件事：怎么把 Manager 正确地开起来、怎么按场景裁剪它，以及怎么验收。

一、官方给的两步，原样是这样

README 里 Manager 的设置步骤就两条命令，中间没有别的动作：

pip install -r manager_requirements.txt

python main.py --enable-manager

第一条装的是 Manager 自己的 Python 依赖。官方为它单列了一份 manager_requirements.txt，而不是并进核心依赖里，所以它需要你显式跑这一条；跳过这一步直接加 --enable-manager，等于参数敲对了、依赖没装。

第二条是启动时显式打开 Manager 功能。comfy/cli_args.py（v0.31.0）里 --enable-manager 的 help 写的就是「启用 ComfyUI-Manager 功能」，没有更多修饰。也就是说，不加这个参数，Manager 就是关的，这是默认状态。

顺带说一句仓库位置：Manager 的代码在 github.com/Comfy-Org/ComfyUI-Manager/tree/manager-v4。注意这里是 manager-v4 分支，不是默认分支。查文档、翻代码、对照 issue 的时候别翻错分支——网上大量教程写的是更早形态的 Manager，和这里说的两步命令未必对得上。至于 v4 与旧版本在实现上差在哪里，我们手上没有依据，不展开。

二、三个开关分别在管什么

comfy/cli_args.py（v0.31.0）与 README 表格里，和 Manager 相关的一共三个：

参数	help 原意
--enable-manager	启用 ComfyUI-Manager
--enable-manager-legacy-ui	使用旧版 Manager UI，源码里它会隐含 --enable-manager
--disable-manager-ui	只禁用 Manager 的 UI 与端点，保留后台功能（README 举例：安全检查、计划安装的完成流程），要求已经开启 --enable-manager

后两个是互斥的，不能同时给。

这张表里有两处值得单独拎出来讲，因为它们都属于「help 字面之外的连带效果」，读者最容易在这里翻车。

第一处是 --enable-manager-legacy-ui 隐含 --enable-manager。 源码里它会顺手把启用位置真，所以你只写这一个参数，Manager 本身也会开起来。好处是省一个参数；坏处是当你后来想关掉 Manager、把启动脚本里的 --enable-manager 删掉，却忘了删 legacy-ui 这一行，Manager 会照常启用——你看着命令行以为已经关了，实际没关。要关就两个一起删。

第二处更反直觉：--disable-manager-ui 不等于「关掉 Manager」。 按 help 的说法，它禁用的是 Manager 的 UI 与端点，而后台功能保留下来，README 举的例子是安全检查以及计划安装的完成流程。换句话说，这是一个「砍掉前台入口，留下后台执行」的开关，而不是一个总闸。真正的总闸是不加 --enable-manager。

而且它还有个前提：它要求 --enable-manager 已经开启。逻辑上是自洽的——Manager 都没开，也就没有 UI 需要你去禁用。但实操上意味着这个参数不能单独用，你得写成两个参数一起给。

顺着这个设计往回想，官方把「Manager 的 UI」和「Manager 的后台能力」拆成了两件事，这个拆分本身就是我们做部署决策时的判断依据：在多用户或者对外服务的实例上，你往往希望「已经排上队的安装任务能收尾、安全检查继续跑」，但不希望任何一个访问者都能通过界面随手装节点。这正是 --disable-manager-ui 存在的意义。

三、按场景写命令

场景 A：本机单人用，就是想装节点。 老老实实两步走，第一条 pip install -r manager_requirements.txt，第二条：

python main.py --enable-manager

不用加别的。

场景 B：机器放在内网给几个人用，不想让人从界面随手装节点。

python main.py --listen --multi-user --enable-manager --disable-manager-ui

逐个说为什么在这：--listen 不带参数时监听 0.0.0.0,::，即所有 ipv4 与 ipv6 网卡——默认值是 127.0.0.1，不加就只有本机能访问，这是「局域网连不上」的第一嫌疑；--multi-user 的 help 是启用按用户分离的存储；--enable-manager 是必须的前提，因为 --disable-manager-ui 要求它已经开启；--disable-manager-ui 关掉 UI 与端点，同时按 help 保留安全检查、计划安装完成这类后台流程。

以上为按官方参数语义组合的示例，未逐项实测，以官方文档与 --help 输出为准。另外提醒一句：把服务开到所有网卡上是一个需要你自己评估的暴露面，--listen 不带参数等于对所有网卡开放，这一点 help 写得很清楚，别当成默认无害的写法。

场景 C：只想临时看看旧版界面。 加 --enable-manager-legacy-ui 即可，不用再写 --enable-manager（它已隐含）。但要记住上面说的删除陷阱。

四、产出物与怎么验收

先说清楚边界：README 只给了上面那两条命令，没有给出启动日志的样例文案，也没有给出 Manager 相关的界面提示文本，所以这里不去描述「日志里会打印哪一行」「界面上会弹什么字」——我们没有依据，编出来的字符串只会让你按图索骥找不到。

有依据的「产出物」只有三样。 一是 Manager 在前台的入口：--enable-manager 打开的就是 Manager 功能，--disable-manager-ui 按 help 关掉的是「UI 与端点」，所以这两个参数的组合直接决定了你在浏览器里还看不看得见这个入口——这是唯一一个用眼睛就能确认的产出。二是自定义节点最终落盘的位置，也就是 custom_nodes 目录，它归 --base-directory 统管。三是加了 --multi-user 之后，按 help 的说法存储会「按用户分离」，至于分离后的目录长什么样，help 没写，我们不猜。

除此之外的东西——具体多出哪些文件、界面上写着什么字——都不在我们的依据范围内。

能确定的验收动作是这几个：

1. 依赖装没装。 第一条 pip install 有没有正常结束、有没有报错。这一步失败但你没注意，后面一切都是白搭。
2. 参数有没有真的传进去。 启动命令里 --enable-manager 是否存在。如果你用的是批处理、shell 脚本或者桌面版的快捷方式，参数是否落在了实际执行的那一行，而不是被注释掉或者写在了错误的位置。
3. Web 界面里 Manager 的入口是否可用。 这是最直接的判断：开了 --enable-manager 而没加 --disable-manager-ui 时，前台应当能用；反过来，如果你加了 --disable-manager-ui，那么前台入口不可用才是预期正确的结果——不要把它当成故障去排查，这是本篇最想让你记住的一点。
4. 装出来的节点落在哪里。 自定义节点属于 --base-directory 统管的六类目录之一（models、custom_nodes、input、output、temp、user）。如果你启动时用了 --base-directory 把基准目录挪走，那么就该去挪走后的 custom_nodes 下找，而不是在 ComfyUI 安装目录里找。这一条在「装完却看不到新节点」时特别管用。

按上面这几条参数语义倒推，最容易出错的是这三处（我们没有统计数据，只按语义上「最容易漏」排）：漏了 pip install -r manager_requirements.txt；--disable-manager-ui 单独写、没有配 --enable-manager；以及删参数时漏删 --enable-manager-legacy-ui 导致 Manager 其实还开着。

五、什么情况别这么干

要求完全离线的机器。 Manager 的职责是安装、更新和管理自定义节点，这件事天然要连外网。同一台机器上如果你还打算用 --disable-api-nodes（它的 help 明确写了不加载所有 api 节点，同时阻止前端与互联网通信），那这两个目标是相互拉扯的，需要你自己权衡先后，别指望一条命令同时满足。

跑生产流水线的实例。 更稳的做法是把节点集合固化下来，用 --disable-all-custom-nodes 一刀切，再用 --whitelist-custom-nodes NAME [NAME ...] 把确实需要的目录放进白名单。生产环境的诉求是「今天和昨天跑出来的东西一致」，而不是「随时能装新节点」，这两个诉求应该分在不同的实例上。

公网直接暴露的实例。 不建议把 Manager UI 留在这种实例上；即便你只是内网多人共用，也建议按场景 B 那样只留后台。需要额外说明的是，任何反向代理、防火墙、访问控制的做法都属于通用运维范畴，不是 ComfyUI 官方文档的内容，本文不展开。

还有一条与 Manager 间接相关的。 ComfyUI 的 requirements.txt 用 == 精确 pin 了前端（comfyui-frontend-package==1.48.7）、工作流模板（comfyui-workflow-templates==0.11.37）与内置文档（comfyui-embedded-docs==0.5.9）三个包，升级 core 会连带换掉它们的版本。所以升级 ComfyUI 之后，Manager 侧的依赖是否还需要重新执行一次 pip install -r manager_requirements.txt，值得你在升级流程里留一个检查点，而不是默认它不变。

最后照例提醒：以上参数、默认值与隐含关系都以 v0.31.0 时点的 comfy/cli_args.py 与 README 为准。ComfyUI 迭代很快，参数会变，升级后请以 python main.py --help 的实际输出为准，别拿半年前的启动脚本硬套。

延伸阅读

• 让 ComfyUI 完全离线跑：--disable-api-nodes 之外还要关掉哪些出网路径
• ComfyUI 的 assets 系统、数据库与 blake3 哈希：--enable-assets 到底要不要开
• ComfyUI 多卡机器上的设备参数：--cuda-device 与 --default-device 到底差在哪

---

本文依据 ComfyUI 官方仓库（github.com/Comfy-Org/ComfyUI）的 README、comfy/cli_args.py、 release notes 与官方安全公告整理，核对日 2026-08-09，对应版本 v0.31.0； 文中引用的 issue 状态为该日期的快照。本文内容为官方文档与源码口径，非本机实测。 参数、默认值与功能随版本变动，请以官方文档与 python main.py --help 的实际输出为准。