1.1 扩展管理在ComfyUI工作流中的定位与作用
我刚开始用ComfyUI那会儿，觉得它就是个节点画布，拖拖拽拽就能出图，挺省心。用得久了才发现，真正让这套东西变得“好用”还是“难搞”的，往往是扩展。ComfyUI本体提供的是基础节点和运行框架，自定义节点、模型加载器、图像后处理这些能力，大多来自社区扩展。扩展装得顺手，工作流跑起来就顺；扩展管理乱了，打开一个别人的工作流，满屏红框提示缺节点，那种感觉挺让人头大。
我自己理解，扩展管理在ComfyUI工作流里扮演的是“底层秩序”的角色。它不直接参与出图，却决定了工作流能不能复现、能不能迁移、能不能在换一台机器之后还跑得起来。举个例子，你在本地调好了一个复杂的工作流，发给同事用，对方缺了三个自定义节点和一个依赖包，工作流基本就瘫了。这时候ComfyUI Manager的价值就出来了，它把“找扩展、装扩展、查缺失、补依赖”这些零散动作收拢到一个界面里，省掉了大量翻文档和手动敲命令的时间。
从更实际的角度看，扩展管理还影响着工作流的稳定性。节点版本之间会打架，Python依赖会冲突，模型路径会对不上。这些问题单看都不大，堆在一起就会让一个原本能跑的工作流突然罢工。我习惯把扩展管理看成工作流的“地基维护”，平时不显眼，出问题的时候最先被想起。
1.2 ComfyUI Manager核心功能与典型使用场景
ComfyUI Manager我用下来，最常用的功能集中在几块：扩展的搜索与安装、已安装扩展的更新检测、缺失节点的提示与补装，还有模型文件的一些辅助管理。它的界面不算花哨，但把高频操作都摆在了明面上。打开Manager面板，能看到已安装列表、可更新列表，也能直接搜关键词找扩展，点一下就能拉取安装。对不太习惯命令行的人来说，这个入口降低了不少门槛。
典型场景我碰到最多的是两种。一种是拿到别人的工作流，加载之后提示缺节点，Manager会列出来源和名称，我可以直接在面板里补装，不用挨个去GitHub翻。另一种是新环境搭建，换了电脑或者重装了ComfyUI，之前那套扩展要重新配一遍，这时候Manager的批量查看和安装就挺省事。我自己的习惯是，新环境先装Manager，再让它帮我把常用扩展补齐，比手动一个个克隆仓库快很多。
还有一个场景容易被忽略，就是扩展更新。社区扩展迭代快，有些更新修了bug，有些更新改了接口。Manager能提示哪些扩展有新版本，我可以选择性地更新，不必全量升级。这个“选择性”挺重要，全量更新有时候会把稳定环境搞乱，尤其是生产用的工作流，我一般会先看更新说明再动手。
1.3 扩展管理常见问题全景与排错思路
扩展管理出的问题，说起来五花八门，归归类其实就那几类。安装失败最常见，表现是点了安装没反应、进度卡住、或者报一堆红色错误。往下走是依赖冲突，两个扩展要求不同版本的同一个Python包，装了这个那个就报错。网络问题在国内环境挺普遍，GitHub拉取慢或者直接超时，Manager面板里转圈转半天。路径和权限也会添乱，尤其是Windows上，目录带空格或者没有写入权限，安装过程就会半路失败。
我自己的排错思路是先看日志，不急着点重试。Manager的安装日志里通常能看到卡在哪一步，是克隆仓库失败，还是pip安装依赖报错，还是解压路径不对。日志指向网络，我就去检查代理和镜像设置；日志指向依赖，我就去看版本冲突；日志什么都没写，我才考虑手动安装或者换一种安装方式。这个顺序能省掉很多盲目操作。
还有一点经验想分享，扩展管理的问题不要一上来就重装Manager或者重装ComfyUI。重装能解决一部分问题，但也会把原本能用的环境搞乱。我一般会先做最小化验证，比如手动克隆一个扩展看看能不能装上，或者单独跑一次pip安装看看报什么错。把问题范围缩小之后，再决定是修依赖、换源，还是回滚版本。这套思路在后面几章会展开讲，这里先埋个引子。
2.1 Manager安装启用与界面入口配置
我装Manager的过程其实挺朴素的，最早是在ComfyUI根目录下找到custom_nodes这个文件夹，把Manager的仓库克隆进去，重启一下就行。命令大概就是git clone那个地址，放到custom_nodes/ComfyUI-Manager路径下。这种做法看起来原始，好处是自己清楚文件到底落在哪儿，出了问题也方便找。后来Manager自己也带了安装脚本，Windows下有.bat，Linux和Mac有.sh，跑一遍能省掉手动克隆的步骤。我两种都试过，结果差不多，手动方式更适合我这种喜欢把每一步都看清楚的人。
界面入口这块，装完重启ComfyUI之后，菜单栏或者浮动面板上会出现一个Manager按钮。我用的版本是在顶部菜单栏右侧，点开就是一个面板，里面分了已安装、可安装、更新等几个标签。有些整合包会把Manager预装好，打开就能看到入口，省了一步。也遇到过装完没出现按钮的情况，多半是没重启进程，或者Manager文件夹的层级放错了，比如多套了一层目录，ComfyUI扫描不到。我一般先检查路径结构，确认__init__.py在正确层级，再杀进程重开。
入口配置还有个细节值得提一下，Manager的面板可以设置成浮动或者固定，我习惯固定放在右侧，方便随时点开看。面板里也有一些基础设置项，比如是否自动检查更新、是否启用预览版更新通道。这些开关我通常保持默认，等实际用到的时候再调。装Manager这件事本身不难，难的是后面装扩展的时候各种环境差异，所以启用之后我会先跑一次“检查更新”，确认Manager自己是最新的，再往下折腾。
2.2 扩展搜索、安装流程与来源识别
搜索扩展这件事，我有自己的一套习惯。Manager面板里有个搜索框，输入关键词就能列出相关扩展。我一般会先想清楚自己要装的是什么功能，比如“换脸”、“高清放大”、“图像对比”，用英文关键词搜命中率更高，社区扩展大多数用英文命名和描述。搜的时候我会看结果列表里的名称和简介，有些名字起得花哨，简介写得含糊，这种我会多留个心眼。搜不到的时候我会换几个同义词再试，或者在GitHub上先找仓库，再回Manager里按仓库地址装。
安装流程走起来不复杂，点一下Install按钮，Manager会去拉取仓库，然后尝试安装依赖，界面上会显示进度或者日志。我印象里大部分扩展几秒到几十秒就装完了，慢的会卡在依赖下载上。装完之后Manager通常会提示需要重启ComfyUI，有些扩展还要额外下载模型文件，Manager会把提示写在面板里。我一般会先看提示再决定重启，避免装到一半重启导致状态混乱。批量装多个扩展的时候，我习惯一个一个来，装完一个确认没问题再装下一个，这样出问题容易定位。
来源识别是这一步里我最在意的。Manager列表里每个扩展会显示作者和仓库来源，我一般优先选GitHub上star多、近期有提交的仓库。有些扩展名字很像官方出品，点进去发现是个人仓库，功能描述也很泛，这种我会谨慎一些。装之前我会点开仓库地址看一眼，确认README写得清楚、issue区没有大面积安装失败反馈。来源不明的扩展我基本不碰，尤其是要求填写API密钥或者执行未知脚本的。这个判断习惯让我少踩了不少坑，虽然有时候会错过一些好用的小众扩展，但稳定性上划算。
2.3 安装日志、网络环境与权限检查要点
安装日志是我排查问题的第一站。Manager面板里一般有个日志区域，或者在ComfyUI的控制台窗口能看到完整的输出。日志会显示当前在做什么，是克隆仓库、下载依赖、还是解压文件。我碰到过安装卡住不动的情况，盯着日志看发现停在git clone那一步，基本就是网络问题。也见过日志里刷出一串红色pip报错，那是依赖版本对不上。看日志的时候我习惯从下往上看，最后几行往往就是失败原因，比从头翻快得多。
网络环境这块在国内用Manager确实要多留神。GitHub的访问时好时坏，clone大仓库容易超时。我自己的做法是在Manager设置里配置代理或者镜像源，有些版本支持填写自定义索引地址。没配好的时候，安装失败率会明显高一些，表现是进度条卡住或者日志里出现连接超时。我还会用浏览器先打开对应的GitHub页面测试一下连通性，能打开再回Manager里点安装，省得白等。换了网络环境之后，我第一件事就是重测一下安装一个轻量扩展，确认链路通畅。
权限问题容易被忽略，但碰上了挺磨人。Windows上如果ComfyUI装在Program Files这类受保护目录，Manager往custom_nodes里写文件就可能被系统拦住，日志里会出现权限拒绝的字样。我的做法是把ComfyUI放在用户目录下的普通文件夹里，避开系统保护路径。Mac和Linux上则是要看文件夹的所属用户和读写权限，用ls -l看一眼就知道。还有一种情况是Manager面板本身能打开，但点安装没反应，这种我一般会检查是不是以普通用户权限跑的ComfyUI，必要时换一个终端环境重新启动。权限这关过了，后面装扩展会顺很多。
3.1 常见失败类型：依赖冲突、网络代理、路径权限与版本不兼容
装扩展失败这事儿，我踩过的坑能凑成一桌菜。最常见的几种，我大致分了分类，方便自己对号入座。依赖冲突排在头一位，日志里刷出一堆红色pip报错，说什么版本不满足、包找不到、依赖解析失败，基本就是它。这种冲突有时候是扩展自己的requirements写得太宽泛，有时候是两个扩展抢同一个包的不同版本，装第二个的时候把第一个的环境给搅乱了。我还遇到过torch版本被某个扩展拽着降级，结果另一个依赖新版本torch的节点当场罢工。
网络这块的失败特别有迷惑性，表面上看是安装卡住，实际上背后是clone或者pip下载超时。GitHub在国内的连通性时好时坏，大仓库拉一半断掉的情况我碰过好几次。pip源默认走官方，速度慢不说，偶尔还会被墙。代理没配好、镜像源填错、终端环境变量跟Manager设置打架，这些都能让安装过程莫名夭折。我后来养成了一个习惯，装之前先用浏览器点一下仓库地址，能打开再动手，省得白等半天。
路径权限和版本不兼容算是隐藏款。Windows下把ComfyUI塞进Program Files，Manager往custom_nodes写东西就会被系统拦下来，日志里冒出一句权限拒绝，看着不起眼但足够让安装失败。Mac和Linux上文件夹属主不对、读写权限没开，也是同样的结果。版本不兼容更微妙，ComfyUI本体更新太快，有些老扩展调用的节点API已经变了，装上去能识别但一跑就报错。Python版本也是个坎，3.10和3.12之间差着不少轮子，扩展没提供对应版本的包就只能干瞪眼。
3.2 分步排查：日志定位、手动安装、镜像代理与依赖修复
排查我一般从日志下手，这是最快能摸到线索的地方。Manager面板里的日志区域或者ComfyUI控制台窗口，失败的时候会留下完整的输出。我的习惯是从最后几行往回看，红色报错往往就压在最底下，比从头翻省事得多。看到git clone停在半路，那就是网络；看到pip install一串Could not find a version，那就是依赖或者索引源的问题；看到Permission denied，直接去查路径权限。日志里还会显示当前在装哪个包，这个信息对判断是单个扩展的问题还是环境整体的问题很有帮助。
日志定位不了的时候，我会退到手动安装。把仓库地址复制出来，进到custom_nodes目录下自己git clone，再进到扩展文件夹里pip install -r requirements.txt。这样做的好处是每一步都能看到输出，哪一步失败一目了然。命令行里还能加参数，比如pip install -i指定镜像源，或者--no-cache-dir跳过缓存重新拉包。我碰到过一个扩展在Manager里怎么都装不上，手动clone之后发现它requirements里写了个已经被删除的老包，改一下版本号就通了。手动装还有个附带好处，装完能顺手看一眼扩展的目录结构，确认__init__.py位置对不对。
镜像代理和依赖修复是配套的。pip我一般会配国内源，清华或者阿里云的镜像，速度稳定。git这边配代理稍微麻烦点，git config --global http.proxy设一下，或者用ghproxy这类加速前缀替换仓库地址。Manager自己的设置里有些版本支持填自定义索引，填上镜像地址之后安装成功率会明显高一些。依赖修复我通常用pip check先扫一遍，看有没有版本冲突，再用pip install --upgrade或者指定版本号来修。碰到比较顽固的冲突，我会把冲突的包单独拎出来看它被谁依赖，有时候是某个扩展的requirements写死了老版本，手动放宽一下就能解决。
3.3 失败恢复与回滚：备份、缓存清理与Manager重装
安装失败之后最怕的是把原来能用的环境也搞坏了。我现在养成的习惯是动手之前先备份，custom_nodes整个文件夹拷一份出来，models目录太大就只备份最近新增的，workflows也顺手存一下。这套备份在虚拟机或者本地磁盘都行，关键是出问题的时候能快速回退。我碰到过一次装扩展把几个节点的依赖一起升级了，结果老的扩展全部报错，靠备份回滚才救回来。备份这事儿花不了几分钟，省下的可能是几个小时的重新配置。
缓存清理是个容易被忘掉的步骤。pip装失败的包会留一部分在缓存里，下次重装的时候可能读到一半的残缺文件，表现是报错信息跟第一次不一样，反而更难排查。pip cache purge清一下，git的临时目录也顺手删掉，能让下一次安装从干净状态开始。custom_nodes里如果留了装失败的半成品文件夹，也一起删掉，不然Manager可能把它当成已安装的扩展，列表状态会乱。我还会看一眼__pycache__文件夹，有时候Python缓存的旧字节码会让新装的扩展行为诡异，清掉最省心。
Manager自己出问题的时候，重装是最干脆的办法。把custom_nodes/ComfyUI-Manager整个删掉，重新克隆一份最新的仓库，重启ComfyUI。重装之前我会把Manager的设置文件或者配置文件扫一眼，有些自定义设置能留下来就留下来。重装之后第一件事是跑一次更新检查，确认Manager是最新版本，再把之前装过的扩展一个个重新装回去。这个过程听起来麻烦，实际用起来比重头排查环境问题快得多。我现在的习惯是每隔一段时间就重装一次Manager，顺便清理一下环境，扩展管理这块少了很多莫名其妙的毛病。
4.1 扩展更新检测、批量更新与版本锁定
Manager面板里那个"Check for updates"按钮我点得挺勤。每次打开ComfyUI，第一件事就是扫一眼有没有扩展亮着更新提示。检测机制其实挺简单，Manager会把本地记录的git commit跟远程仓库比对一下，两边不一致就标成待更新。我遇到过一种情况，某个扩展明明远程没动，本地却一直提示更新，后来发现是仓库地址被作者改了，旧地址重定向导致比对逻辑犯迷糊。这种时候重新装一遍那个扩展，比跟更新按钮较劲省事。
批量更新我用得比较克制。面板里有个"Update All"的选项，一次把所有待更新的扩展全部拉最新版。听起来很爽，我第一次用的时候也觉得很爽，爽完之后发现三个扩展互相打架，整个工作流跑不起来。后来我学乖了，批量更新之前先把custom_nodes文件夹整个复制一份，命名带上日期，出问题直接换回去。更新的时候我会盯着日志，哪个扩展拉得快、哪个卡在git clone半天不动，一眼就能看出来。卡住的那种多半是仓库太大或者网络抽风，单独拎出来手动更靠谱。
版本锁定这个功能知道的人不多，我用了一段时间才摸清门道。Manager允许你把某个扩展固定在一个特定版本，不让它跟着远程仓库跑。操作方式是在扩展详情里找到commit hash，填进锁定框，之后更新检测就会跳过它。我一般会把那些跟核心工作流强绑定、作者又更新频繁的扩展锁住，比如某些自定义节点包，新版经常引入不兼容的改动。锁版本等于给自己买了个保险，代价是享受不到新功能，得自己权衡。我现在的策略是核心依赖锁死，外围工具放开更新，出问题的影响面小很多。
4.2 Python依赖、模型依赖与节点冲突处理
Python依赖这块，我的经验是能不动就不动。扩展更新的时候经常会在requirements里加新包或者升版本，Manager装完扩展顺手就给你pip install了。问题在于你根本不知道它装了什么，等某个老节点突然报ImportError才发现环境被改了。我现在习惯在更新前跑一次pip freeze > requirements_before.txt，更新后再跑一次，两份文件一对比，哪些包变了、变了多少，清清楚楚。这个操作花不了十秒钟，排查的时候能省掉大量猜谜时间。
模型依赖比Python依赖隐蔽得多。有些扩展更新之后会依赖新的模型文件，但不会自动帮你下载，节点加载的时候直接报找不到模型。日志里一般会写清楚缺的是哪个文件、该放哪个目录，照着补就行。麻烦的是那种不报错但结果不对的情况，模型版本换了，参数不匹配，跑出来的图跟以前不一样。我碰到过一次，某个采样器扩展更新后默认用的模型版本变了，出图风格直接跑偏，找了半天才发现是模型依赖的问题。现在我更新扩展之前会扫一眼它的README或者更新日志，看看有没有提到模型变更。
节点冲突是最让人头疼的一类。两个扩展注册了同名的节点，或者调用了同一个底层库的不同版本，表现是其中一个能用另一个就哑火。Manager本身不检测这种冲突，得自己观察。我的办法是更新完之后挨个打开常用工作流，看节点上的红色报错和黄色警告。黄色警告一般是节点能加载但版本不匹配，红色就是彻底挂了。碰到冲突我会用二分法排查，把最近更新的扩展先禁用一半，跑一遍看问题还在不在，逐步缩小范围。这个过程有点笨，但比瞎猜有效得多。
4.3 更新后兼容性验证与回滚策略
更新完扩展我不会马上投入正式工作，先跑一轮验证。验证用的是一张固定的测试工作流，里面放了各种类型的节点，采样、加载、图像处理、控制网都有。这张图跑通了，说明基本兼容性没问题。跑不通的话，我会看是哪个节点红了，对应到哪个扩展，心里就有数了。测试工作流我放在单独的文件夹里，不跟正式项目混在一起，免得验证过程把正经文件搅乱。这个习惯是之前吃过亏养成的，当时更新完直接开新项目，跑到一半崩了，根本分不清是新项目的问题还是扩展的问题。
回滚策略我准备了两层。第一层是文件夹级别的备份，更新前把整个custom_nodes复制一份，出问题直接删掉换回去，最粗暴也最有效。第二层是Manager自带的版本回退，在扩展详情里可以切回历史版本。两层各有适用场景，文件夹备份适合大面积翻车，比如好几个扩展一起更新完集体罢工；单个扩展回退适合精准打击，就某一个节点出问题，其他都好好的。我一般先用单个回退试试，修不好再上文件夹备份。回退之后记得清一下__pycache__，不然Python可能还在读旧的字节码，回退了跟没回一样。
兼容性验证里有个容易被忽略的点是ComfyUI本体版本。扩展更新往往跟着本体版本走，本体太老或者太新都可能出问题。我更新扩展之前会先看一眼本体有没有更新提示，有的话先把本体更到最新，再更扩展，顺序反过来容易踩坑。本体更新本身也有风险，所以我一般挑不忙的时候做这件事，留出足够时间处理意外。更新完本体和扩展，跑一遍测试工作流，再跑一个正式项目的小样，两关都过了才算稳。这套流程听起来繁琐，跑熟了也就十几分钟的事，比出了问题再回头救火轻松多了。
5.1 环境隔离、备份机制与变更记录
环境隔离这件事我踩过坑才重视起来。最早我把所有扩展一股脑塞进同一个ComfyUI目录，什么测试版、稳定版、魔改版全混在一起，结果某个扩展更新把共享的Python包版本顶掉了，整个环境连锁崩溃。后来我搞了两套ComfyUI，一套是主力生产环境，只装经过验证的扩展，另一套是沙盒环境，新扩展新版本先往沙盒里扔，跑通了再搬到主力环境。两套环境用不同的conda虚拟环境隔离Python依赖，目录也分开放，互不干扰。这么做硬盘多占几十个G，但省下来的排错时间值回票价。偶尔我也用便携版做第三套临时环境，专门测试那种来源不明或者改动特别大的扩展，测完直接删掉，干净利落。
备份机制我分三层来做。第一层是自动的，用系统自带的定时任务每天凌晨把整个ComfyUI目录打包压缩到另一块硬盘上，保留最近七天的版本。第二层是手动的，每次大批量更新扩展之前，我会把custom_nodes文件夹单独复制一份，命名带上日期和操作内容，比如custom_nodes_backup_20250115_before_batch_update。第三层是云端，把关键配置文件、工作流文件和自定义节点清单同步到网盘，万一硬盘挂了还能从云上拉回来。三层备份听起来夸张，真正救过我一次的是第二层手动备份，某次批量更新后Manager自己都打不开了，直接从备份文件夹换回去，十分钟恢复生产。云端那层目前还没用上，希望永远用不上。
变更记录我用最土的办法——一个Markdown文件。每次动扩展之前，在里面写一行：日期、操作类型、涉及哪些扩展、操作前有没有备份、操作后有没有异常。格式不讲究，能看懂就行。比如“2025-01-10 更新了Impact Pack和WAS Node Suite，更新前备份在D盘backup文件夹，更新后测试工作流跑通，但某个ControlNet节点报黄警告，暂未处理”。这个记录文件放在ComfyUI根目录下，跟工作流文件放一起，找起来方便。坚持记了几个月之后我发现它的真正价值不在当时，而在两个月后某个扩展突然出问题，翻记录能快速定位到是哪次更新引入的。没有这份记录，全靠脑子回忆，基本等于抓瞎。
5.2 安全审查、来源可信与权限最小化
扩展来源审查我有一套自己的土标准。优先选GitHub上star数超过五百、最近半年有commit、issue区有人回复的项目。star数不代表绝对安全，但至少说明用的人多，真出问题有人帮你踩过雷。那些刚注册的账号、仓库里只有一两个commit、README写得含糊其辞的扩展，我一般会犹豫很久。实在需要用，先扔沙盒环境跑一周，观察有没有异常网络请求或者文件读写。我还会扫一眼扩展的__init__.py和nodes.py，看看有没有明显的可疑操作，比如往系统目录写文件、调用subprocess执行来路不明的命令、或者把本地路径往外发。看不懂代码没关系，搜一下关键词也能筛掉一部分明显不靠谱的。
权限最小化这块，我的做法是ComfyUI不用管理员权限跑。Windows上专门建了一个普通用户账户跑ComfyUI，Linux上就更简单了，单独开一个用户，家目录之外的地方不给写权限。这样即使某个扩展藏了恶意代码，它能祸害的范围也有限。另外我把扩展的自动更新关掉了，Manager默认会提示更新，但不会自动装，每次更新都得我手动点确认。这个设置牺牲了一点便利性，换来的是我对环境变更的完全掌控。还有个小习惯，装新扩展之前先看一眼它的requirements.txt，如果里面列了一堆莫名其妙的包，或者版本号写得特别宽泛，我会多留个心眼，装完之后对比一下pip列表的变化。
安全审查里容易被忽略的是模型文件。有些扩展会引导你下载来源不明的模型，.pth或者.safetensors文件里藏东西不是没可能。我的原则是模型只从 civitai、HuggingFace 官方仓库或者作者明确指定的链接下载，下载完核对一下文件大小和哈希值。Manager本身不校验模型完整性，这个活只能自己干。碰到扩展要求下载模型但没给明确来源的，我一般会去它的GitHub issue区翻翻，看看有没有人讨论过这个问题。没人讨论、作者也不回应的，我宁可不装这个扩展。安全这事没有百分百，但多花五分钟排查，能避开绝大多数低级风险。
5.3 日常巡检、故障预案与可持续维护
日常巡检我安排在每周五下午，花二十分钟走一遍固定流程。先打开Manager面板看有没有异常标红的扩展，再翻一遍ComfyUI启动日志，搜一下error和warning关键词，看看有没有反复出现的报错。然后检查磁盘剩余空间，custom_nodes文件夹膨胀得很快，模型文件又大，空间不够的时候各种奇怪问题都会冒出来。最后跑一遍那张固定的测试工作流，确认核心功能正常。这套流程走熟了很快，大部分时候什么都没发现，但偶尔能提前逮住一两个小毛病，趁没扩大之前处理掉。巡检记录我直接写在变更记录文件的最上面，按周分段，翻起来一目了然。
故障预案我准备了一份“急救清单”，打印出来贴在显示器旁边。上面列了几条：Manager打不开怎么办、扩展全部报红怎么办、Python环境彻底崩了怎么办。每条对应三到五个具体步骤，比如“Manager打不开：第一步检查custom_nodes/ComfyUI-Manager文件夹是否存在，第二步看启动日志里有没有ImportError，第三步尝试手动pip install缺失的包，第四步从备份恢复整个Manager文件夹”。这份清单是我几次翻车之后总结出来的，照着做不一定能解决所有问题，但至少不会手忙脚乱乱操作。清单每隔几个月更新一次，把新踩的坑和对应的解法补进去。
可持续维护的核心是别让环境越来越臃肿。我每个季度做一次大扫除，把三个月没用过的扩展卸载掉，清理__pycache__和pip缓存，删掉过期的备份文件夹。卸载扩展之前先确认没有工作流依赖它，用Manager的禁用功能观察一周再彻底删除。另外我会定期整理工作流文件，把废弃的试验项目归档到单独文件夹，主目录只留常用的。这套习惯坚持下来，ComfyUI目录始终保持在可控的规模，出问题的时候排查范围小很多。维护这件事没有一劳永逸的办法，扩展生态在变、ComfyUI本体在变，能做的就是保持节奏、留好退路、记录清楚，剩下的交给时间。
