ComfyUI 安装使用教程：环境配置、模型导入与首个工作流

安装前检查

先明确目标：是体验基础文生图、导入现有工作流，还是建设长期生产环境。目标不同，安装路径、模型数量和扩展需求也不同。第一次安装建议只完成核心启动和基础工作流，不要同时安装大量自定义节点。准备一块空间充足的磁盘，确认系统更新、显卡驱动和浏览器可正常使用，并决定输入输出是否包含敏感素材。

建立安装记录，写下核验日期、官方仓库、选择的安装方式、程序目录、模型目录和备份位置。不要把访问凭据写入教程或工作流。若设备已经运行其他本地 AI 工具，先检查 Python 环境、端口和模型目录是否会冲突，避免直接复用一个无法回滚的公共环境。

选择官方安装路径

从ComfyUI 产品页确认官方仓库与当前入口，再在桌面、Windows 便携或手动安装之间选择。桌面或便携方式适合快速开始，手动安装适合需要控制依赖、后端和目录的人。不要从不明网盘下载所谓一键整合包，因为其中可能包含未知节点、修改过的启动脚本和来源不清的模型。

选择后保存原始下载地址和说明。官方入口也会变化，旧教程的文件名和步骤可能已经过期。若团队使用，应先由一台测试设备验证，再把经过批准的安装方式写入内部文档，而不是让每个人从不同来源自行安装。

系统与显卡

官方项目说明支持多种操作系统和 GPU 后端，但具体依赖与性能会变化。先根据当前官方 README 选择对应路径，确认驱动和后端能够被系统识别。不要把某个显存数字当作永久最低要求；模型、分辨率、批次和卸载策略都会改变资源需求。

安装前记录设备信息和可用磁盘。首次验证只用基础模型、单张低复杂度任务，观察模型加载、生成、输出保存和连续执行是否稳定。若设备只能通过大幅降低任务规格才能运行，应把限制记录下来，而不是宣称与正常目标等价。

目录准备

建议将程序、模型、输入、输出、临时文件和备份分开。程序目录用于核心与节点，模型目录保存权重，输入目录放测试材料，输出目录按项目归档。路径尽量使用清晰短名称，避免把程序装在系统关键目录、同步盘或权限复杂的位置。

团队环境可以为批准模型设置只读目录，把实验模型放在独立位置。若计划让多个界面共享模型，先保留唯一原始副本和校验值，再使用官方支持的额外搜索路径。不要为了消除报错把同一文件复制到多个目录，这会让后续更新和许可审计失去依据。

下载与首次启动

按官方安装路径下载并解压或安装，首次启动时观察终端和界面日志。核心目标是确认服务只监听预期地址、浏览器可以打开、没有立即报依赖错误，并能看到基础界面。不要用管理员权限运行普通任务，也不要在首次启动时把服务暴露到公网。

如果启动过程需要下载依赖，等待完成并保留日志。网络中断后不要连续重复点击，先查看哪个文件失败、是否留下不完整缓存、代理是否只对部分进程生效。首次成功后关闭并重新启动一次，确认不是依赖临时进程或浏览器缓存造成的偶然成功。

模型来源与许可证

ComfyUI 是界面和工作流引擎，不自动提供所有模型的使用权。模型应来自项目明确链接、模型作者或可信官方发布页。记录名称、来源 URL、许可证、文件大小、校验值、下载日期和用途。商业、公开发布或客户项目尤其需要确认模型和训练素材相关限制。

不要把文件能加载等同于许可清楚。LoRA、VAE、文本编码器、放大模型和自定义节点也可能有独立条款。若来源页消失，已有记录可以帮助判断是否继续使用。无法确认来源的文件先隔离，不应进入批准模型目录。

模型放置

根据模型类型放到当前官方文档对应目录，或通过额外模型路径配置共享位置。完成后重启或刷新模型列表，确认界面显示的名称与文件一致。文件名过于模糊时可以在台账中维护规范名称，但不要随意改名导致已有工作流无法匹配。

若模型没有出现，依次检查文件是否完整、扩展名是否正确、目录层级是否符合扫描规则、额外路径配置是否被加载，以及启动日志是否报告权限问题。不要同时修改多个路径；每次只改变一个变量并重新验证。

加载基础工作流

使用核心项目提供或界面内置的基础模板，避免一开始导入包含大量第三方节点的复杂工作流。基础文生图流程应能识别模型加载、文本条件、潜空间、采样、解码和保存几个主要阶段。先观察节点输入输出颜色和类型，再看参数值。

加载后不要立即排队。逐个确认模型选择、输出尺寸、批次和保存目录，移除不需要的在线 API 节点。若模板引用了本机不存在的模型，用自己已核验的模型替换，并记录修改。基础工作流的目的不是追求最佳效果，而是建立可重复的系统检查。

节点连接

连线表示一个节点的输出传入另一个节点的输入。连接失败通常意味着数据类型不匹配，例如把图像输出接到要求模型对象的输入。遇到问题时从最终保存节点向前追踪，确认解码、采样、条件和模型链路完整。不要通过随机添加转换节点来掩盖对类型的不了解。

给节点分组并添加说明，可以让复杂图保持可读。基础链路稳定后，再复制一份工作流进行实验。对常用区块保持一致命名，例如输入、生成、修正、放大和输出。清楚的结构能让其他人快速判断某条线的用途。

提示词与参数

先使用简单、可检查的提示词，固定模型和工作流，只改变一个因素。正向条件描述主体、环境和视觉目标，负向条件只保留明确不希望出现的内容。不要堆叠大量互相矛盾的词；结果异常时，简化提示比继续增加词更容易定位问题。

采样、步数、引导、尺寸和随机相关参数会共同影响结果，但合适范围取决于模型与工作流。教程不写死数字。建立自己的测试矩阵：每次固定大部分变量，记录修改项、输出和判断。只有在相同任务上比较，参数经验才可复用。

队列生成

确认工作流无缺失节点和红色错误后，再提交单个队列任务。观察日志中的模型加载、执行顺序和输出路径，检查生成文件是否可打开。第一张图成功后，再连续提交少量任务，确认缓存、资源释放和文件命名稳定。

批量前设置清晰命名与项目目录，估算磁盘空间，并决定失败策略。若队列中某个输入损坏，系统是停止还是继续，需要在生产前验证。不要让浏览器页面的“已完成”替代输出检查，仍要确认文件数量、尺寸和内容符合目标。

保存工作流

使用工作流 JSON 保存节点结构，并同时记录模型、节点、输入要求和核验日期。文件名应包含用途和阶段，而不是“final-final”。为生产流程维护批准版和实验版，实验成功后再通过评审更新批准版。

工作流可能包含本地路径、文件名或提示内容，分享前先检查敏感信息。若媒体文件保存了工作流元数据，也要按同样标准处理。工作流备份应进入版本化目录，但大型模型不要重复塞入每个工作流包。

导入工作流

导入外部 JSON 或媒体工作流后，先查看缺失节点和模型提示，不要立刻执行。列出每个缺失项的用途、仓库和许可，判断是否真的需要。某些复杂工作流可以用核心节点重建，减少安装第三方代码的数量。

在隔离环境中完成第一次导入，使用非敏感输入，并监控网络与文件写入。导入成功后，重新保存一份本地批准版，附上依赖清单和修改说明。原始工作流保留只读副本，便于比较后续变化。

自定义节点最小权限

自定义节点是本地代码，应按普通软件依赖审查。优先选择官方组织或维护清晰、用途明确的仓库，阅读安装脚本和依赖。使用普通用户权限运行，限制程序可访问的目录，不在包含客户原始素材的主环境中测试未知节点。

通过 Manager 安装也不能跳过审查。每次只增加一个节点包，验证核心启动、基础工作流和目标功能。记录节点来源、安装日期和用途。暂时不用的节点先禁用，确认没有工作流依赖后再移除。

更新与备份

更新前备份工作流、节点清单、关键配置、启动参数和一组回归输入。模型通常体积较大，可保存来源与校验而不是重复复制，但无法重新获取的合法资源应有受控备份。不要在紧急交付前更新核心、后端和所有节点。

先在副本环境更新，按顺序验证核心启动、基础工作流、批准节点和生产流程。官方提醒普通提交可能破坏自定义节点兼容，因此生产环境应优先使用经过验证的稳定状态。若失败，回滚整个环境比逐个猜测依赖更可靠。

启动失败

先读取第一条有效错误，而不是只看最后一行。确认启动脚本路径、运行用户、端口、磁盘和依赖是否正确。若浏览器打不开，区分进程未启动、端口冲突、监听地址错误和防火墙阻挡。不要在问题未定位时反复重装。

最小化环境：禁用自定义节点，使用基础配置启动。若核心仍失败，问题多半在程序、依赖或后端；若核心成功，再逐个恢复节点。保存完整日志和最近变更，便于回溯。

依赖冲突

依赖冲突常发生在多个节点要求不同包或版本时。表现可能是导入错误、函数缺失或启动后运行失败。先确认冲突来自核心还是某个节点，查看节点安装记录。不要在主环境直接反复升级降级所有包。

解决方案是隔离和最小变化：在副本中只调整冲突包，验证基础与目标工作流，再更新清单。长期生产可以为关键流程保留独立环境，避免一个实验节点改变所有任务的依赖。

模型路径错误

界面找不到模型时，检查文件类型、目录、额外搜索路径、权限和启动日志。路径配置中的相对位置可能基于不同工作目录，复制别人的配置时尤其容易出错。使用绝对路径时不要把个人目录写进共享工作流。

确认配置生效后再刷新列表。若多个界面共享模型，检查是否存在失效链接或权限差异。不要将未知文件重命名成常见模型名来绕过识别，这会破坏台账和复现。

缺失节点

导入工作流提示缺失节点时，先记录节点名称和它在流程中的作用。搜索原作者说明或官方仓库，不要只根据名称安装第一个同名项目。核验仓库归属、依赖、许可证和维护状态，再决定安装或用核心节点替代。

安装后重新打开工作流并检查节点接口。有时节点包存在，但接口已变化，旧工作流仍无法连接。此时需要找到兼容说明或重建相关区块，不应盲目安装多个分支。

工作流不兼容

不兼容可能来自核心变化、节点接口、模型类型、后端或旧参数。先在原始副本上确认错误，再复制工作流进行修复。沿数据流定位第一个不匹配节点，比从最终报错向后猜测更有效。

如果团队主要依赖传统参数面板，可参考Stable Diffusion WebUI 产品页评估是否保留现有流程；若只需简化常见生成，可参考Fooocus 产品页了解维护状态。迁移前先导出模型与素材台账，不要把工具转换误当成模型许可转换。

显存不足

先确认任务规格和模型是否符合设备能力，再降低批次、尺寸或同时加载的组件。关闭其他占用显存的程序，观察日志是否发生卸载或后端错误。不要只凭系统任务管理器的一个瞬时值判断原因。

若缩减任务后能运行，记录新的能力边界。生产验收应使用真实任务连续执行，而不是只生成一张测试图。长期频繁触发资源不足，说明工作流或设备需要重新规划，而不是无限堆叠优化参数。

异常图片

黑图、噪点、颜色异常或结构崩坏可能来自模型与 VAE 不匹配、提示词、采样、输入范围、节点顺序或损坏文件。回到基础工作流和已知输入，固定随机相关参数，只替换一个组件。若基础正常，再逐段恢复复杂处理。

不要把所有异常都归因于显卡。检查模型来源和完整性，确认解码节点与模型类型匹配，查看是否有节点对尺寸或颜色空间做了意外处理。保存异常样本与日志，便于对比修复。

下载不完整

大模型和依赖下载中断后，文件可能存在但无法读取。比较来源页大小和校验值，确认缓存是否保存了部分内容。删除或隔离损坏文件后从同一可信来源重新下载，不要用不同镜像拼接。

网络不稳定时可使用支持续传且能校验的下载方式。下载完成后再移动到批准模型目录。出现压缩流或读取缓冲区错误时，优先检查文件完整性，而不是修改模型节点参数。

安全检查

检查程序监听地址、API 是否需要、浏览器访问范围、输入输出目录权限、自定义节点、模型来源和外部网络连接。对敏感项目关闭不需要的 API 节点，限制网络出口，使用独立目录和普通用户。不要把工作流、日志或截图中的本地路径和客户文件名公开。

定期复核依赖与仓库状态，移除无人维护且非必要的节点。许可证检查覆盖核心、节点、模型、输入素材和输出用途。安全与合规不是安装结束后的补充步骤，而是每次导入、更新和分享工作流都要重复的门禁。

FAQ

第一次安装一定要用 Manager 吗

不需要。先用核心节点完成基础工作流更容易确认环境正常。只有明确需要第三方节点时再安装 Manager，并把 Manager 和节点本身分别审查。

可以直接使用别人图片里的工作流吗

可以导入检查，但不能假定安全和完整。它可能引用缺失节点、未知模型、本地路径或在线服务。应在隔离环境审查依赖，用非敏感输入验证后再保存批准版。

更新后旧工作流打不开怎么办

先使用备份环境确认旧工作流原本可运行，再比较核心、节点和模型变化。恢复到无扩展基础状态，定位第一个不兼容组件。若没有备份，只能根据清单和日志逐项重建，因此更新前记录非常重要。

总结

可靠的 ComfyUI 入门不是“安装后生成一张图”，而是建立可重复流程：从官方入口安装，核验模型与许可，完成基础工作流，保存依赖记录，再逐步增加节点。每次只改变一个变量，可以显著降低排错难度。

长期使用要把工作流、节点、模型、权限和更新当作一个系统管理。基础模板、最小权限、回归输入和可恢复备份，是复杂节点生态仍能保持稳定的关键。若尚未确定界面路线，可先看 本地 AI 绘图工具排行；准备把试用扩大到长期工作前，再用 ComfyUI 完整评测复核维护成本与安全边界。