摘要
在 Windows 上搭建 ComfyUI，往往不是卡在某一条命令，而是悄无声息地陷入一场“环境雪崩”——Python 能跑、CUDA 已装、显卡也在，却偏偏哪里都不对。本文完整记录了我在使用「绘世启动器 + ComfyUI 便携包」过程中，连续遭遇 Python 多版本冲突（3.10 / 3.11 / 3.14）、CUDA 与 PyTorch 版本错配、启动器与 venv 环境脱节、Git 命令失效，以及 GitHub 插件（Impact-Pack / sam2）在国内网络环境下反复拉取失败等一系列真实问题，并逐一拆解其底层原因与修复路径。通过这次实践我逐渐意识到，AIGC 环境配置真正的难点并不在技术本身，而在多个工具对“默认环境”的隐含假设相互冲突。本文适合所有正在 Windows 上折腾 ComfyUI 的新手与进阶用户，帮助你少踩坑、快定位，把环境真正跑稳。
一、背景说明：为什么这次环境会“全面崩溃”
这次环境问题的集中爆发，并不是某一个步骤“装错了”，而是多个工具在同一台 Windows 机器上叠加使用时，彼此的默认假设发生了冲突。
在开始配置 ComfyUI 之前，我的 Windows 环境中已经长期存在多个 Python 版本：
Python 3.10、3.11 以及最新的 3.14，并且它们分别被不同的软件、脚本和开发工具使用。这在日常开发中并不罕见，但也为后续问题埋下了隐患。
本次实际使用的组合是：
- 绘世启动器
- ComfyUI 便携包（ComfyUI-aki-v3）
- NVIDIA 显卡环境（CUDA）
- PyTorch（CUDA 版本）
- GitHub 插件体系（Impact-Pack / SAM2）
- 国内网络环境 + 代理工具（Clash）
这些组件单独使用时问题不大，但一旦组合在一起，就会出现一个典型问题：
每一个工具都假设“系统环境是干净且唯一的”，而现实恰恰相反。
例如：
- Python 工具默认认为：系统里只有一个 Python
- 启动器默认认为：系统 Python 就是运行 Python
- PyTorch 默认认为：安装它的 Python 就是运行它的 Python
- GitHub 插件默认认为：网络环境稳定、GitHub 可直连
- 国内网络现实却是：GitHub 访问不稳定，代理状态随时变化
这些“合理但不现实”的默认假设，在同一台 Windows 机器上叠加后，最终导致了一系列看似无关、实则强相关的问题集中爆发，包括：
- Python 版本混乱
- CUDA / PyTorch 无法识别
- 启动器与命令行行为不一致
- 插件安装过程中 GitHub 克隆反复失败
因此，本次环境“全面崩溃”的核心原因并不是操作失误，而是：
多个工具在同一环境中叠加运行，而它们都默认用户的系统是“干净的”。
理解这一点，是后续所有问题能够被逐一拆解和解决的前提。
二、问题一：Python 版本混乱（3.10 / 3.11 / 3.14 冲突）
在所有问题中，Python 版本混乱是第一个、也是最致命的根因。
后续出现的 PyTorch、CUDA、插件安装异常，本质上都可以追溯到这一点。
2.1 现象表现
在实际排查过程中，最让人迷惑的不是报错本身，而是“每个地方看到的 Python 版本都不一样”：
- 在 PowerShell / CMD 中执行
python -V，显示的是 Python 3.14 - 进入 ComfyUI 自带的
venv后，python -V却是 Python 3.10 - 绘世启动器的环境检测中，显示的 Python 与命令行结果不一致
- PyTorch 安装成功，但运行时却出现：
- 模块找不到
- CUDA 不可用
- 运行路径与安装路径不一致
这些现象单独看都不算“致命错误”，但组合在一起，就会让人产生一种错觉：
“明明都装好了，为什么就是跑不起来？”
2.2 核心原因
问题的根本并不复杂，但非常典型——Windows 下多 Python 共存 + 默认 PATH 机制。
具体来说，核心原因有三点：
- Windows 的 PATH 中存在多个 Python
- 系统 Python（可能是 3.14）
- 其他软件自带的 Python
- ComfyUI 实际需要使用的 Python 3.10
- 启动器默认调用的是“系统 Python”
- 启动器并不会自动识别 venv
- 如果不手动指定，它只会从 PATH 中找第一个
python.exe
- ComfyUI 对 Python 版本是“有要求的”
- 当前稳定版本的 ComfyUI + PyTorch 生态，明确推荐 Python 3.10
- 使用 3.11 / 3.14 虽然可能安装成功，但极易在运行期出问题
这就造成了一个典型错位：
你以为你在用 venv 的 Python 3.10，
但启动器实际上还在调用系统里的 Python 3.14。
2.3 解决方案
解决思路只有一个：彻底让“运行 Python”与“预期 Python”对齐。
具体操作步骤如下：
- 单独安装 Python 3.10
- 不要覆盖系统 Python
- 指定一个清晰、固定的安装目录
- 使用 venv 进行环境隔离
- 所有依赖（PyTorch、ComfyUI 插件）只安装在 venv 内
- 不再向系统 Python 安装任何依赖
- 在绘世启动器中手动指定 Python 路径（关键步骤）
将启动器中的 Python 路径明确设置为：
E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\python.exe
这一操作的意义在于：
- 强制启动器使用 venv 的 Python
- 避免 PATH 顺序、系统环境变量带来的不确定性
- 确保 PyTorch、CUDA、插件全部运行在同一解释器下
在完成这一步之后，Python 相关的“玄学问题”基本会一次性消失。
2.4 关键经验总结
这次踩坑之后，有一个经验非常值得反复强调：
永远不要相信系统 python，要相信 venv。
在 Windows + 深度学习 + 启动器 + 插件生态的组合下：
- 系统 Python 只适合“存在”
- venv 才适合“运行”
- 启动器不做强制约束，就必须由使用者来“钉死路径”
这是后续所有问题能够继续排查和解决的前提条件。
三、问题二：CUDA / PyTorch 版本不匹配报错
如果说 Python 版本混乱 是“地基问题”，
那么 CUDA / PyTorch 不匹配，就是在地基不稳的情况下继续往上盖楼，最终必然塌。
这一问题在 Windows + NVIDIA 显卡 + 启动器环境中极其常见。
3.1 现象表现
在排查过程中，出现了以下典型现象：
- 绘世启动器环境检测中提示：CUDA 无效
- 在 Python 中执行：
import torch
torch.cuda.is_available()
返回结果为：
False
- 但从硬件层面来看：
- 显卡型号明确：RTX 4070 Laptop
- NVIDIA 驱动已安装
- 系统层面 GPU 工作正常
也就是说，系统“看得到 GPU”，但 PyTorch “用不到 GPU”。
3.2 核心原因
这类问题通常不会只有一个原因，而是两个常见错误叠加导致的：
原因一：PyTorch 安装在“错误的 Python 环境”
- 系统 Python ≠ venv Python
- PyTorch 可能被装在：
- 系统 Python
- 其他软件自带 Python
- 但 ComfyUI 实际运行的是 venv 内的 Python
结果就是：
你安装了 PyTorch，但运行时用的不是它所在的解释器。
原因二：CUDA 版本与 PyTorch 不匹配
- PyTorch 的 CUDA 是内置运行时（不是系统 CUDA Toolkit）
- 不同 PyTorch 版本对应不同 CUDA 构建：
- cu118
- cu121
- cpu-only
如果：
- 安装了 CPU 版 Torch
或 - 安装了 CUDA 版本，但与显卡 / 驱动不兼容
都会导致 cuda.is_available() == False。
3.3 解决方案
解决原则只有一句话：
在 venv 中，显式安装“与显卡和驱动匹配的 CUDA 版 PyTorch”。
具体操作如下。
第一步：确保已经进入 venv
E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\activate
第二步：安装 CUDA 版 PyTorch（以 CUDA 12.1 为例）
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121
说明：
- 不要用默认 PyPI
- 不要让 pip 自行判断
- 明确指定 PyTorch 官方 CUDA 构建源
第三步：验证安装结果
python -c "import torch; print(torch.__version__); print(torch.cuda.is_available())"
期望输出结果为：
- PyTorch 版本号正常
torch.cuda.is_available()返回True
3.4 结果
在完成上述操作后，环境状态恢复正常：
- CUDA 成功启用
- PyTorch 正确识别 GPU
- 显卡信息显示为：RTX 4070 Laptop
- ComfyUI 推理阶段不再回退到 CPU
至此，计算层的问题被彻底解决，后续插件与节点的问题，才有继续排查的基础。
四、问题三：启动器使用了“错误的 Python”
在完成 Python 版本与 PyTorch / CUDA 的修复之后，表面上看环境已经“能跑了”，但一个新的问题随之出现：
命令行可以正常启动 ComfyUI，但启动器的一键启动却反复失败。
这一现象往往会让人误判问题已经回到 CUDA 或 PyTorch，其实完全不是。
4.1 现象
具体表现为：
- 在 venv 环境中，通过命令行手动执行
python main.py，ComfyUI 可以正常启动 - 浏览器可以访问
http://127.0.0.1:8188 - 但使用绘世启动器的 一键启动：
- 环境检测反复报错
- 提示 Python / CUDA 异常
- 与命令行运行结果明显不一致
换句话说，同一套代码，在不同入口下表现完全不同。
4.2 原因
原因并不复杂，但非常容易被忽略：
启动器默认调用的是“系统 Python”，而不是 venv 中的 Python。
即使：
- venv 已经正确创建
- PyTorch / CUDA 已在 venv 中配置完成
- 命令行明确使用的是 venv Python
只要启动器没有被显式告知：
“你应该用哪个 python.exe”
它就会继续从系统 PATH 中寻找默认 Python（本例中为 Python 3.14），从而再次造成环境错位。
这也是为什么会出现：
- 启动器报错
- 命令行却一切正常
两者并不在同一个 Python 运行环境中。
4.3 解决方案
解决这一问题的关键在于：
不要试图“让启动器自己判断”，而是直接强制指定路径。
具体操作步骤如下：
- 启用绘世启动器的「专家模式」
- 在高级设置中，手动配置：
- Python 路径覆盖
- Git 路径覆盖（后续插件安装依赖）
其中，Python 路径必须明确指向 ComfyUI 所使用的 venv：
E:\Aicg\Comfyui\ComfyUI-aki-v3\venv\Scripts\python.exe
这一设置的效果是：
- 启动器不再使用系统 Python
- 所有检测、启动、插件安装行为，全部在 venv 中执行
- 命令行与启动器的行为彻底对齐
4.4 关键结论
这一步完成后，可以得到一个非常重要的结论：
启动器 ≠ venv，必须手动对齐它们。
启动器只是一个“入口工具”，并不会自动理解你的 Python 隔离策略。
在多 Python、多环境并存的 Windows 系统中：
- 不显式指定路径 = 不可控
- 一键启动想稳定，必须先把“解释器”钉死
这一点解决之后，后续所有插件、依赖与网络问题，才有继续讨论的意义。
五、问题四：Git 无法使用 / GitHub 插件拉取失败
在解决了 Python、CUDA 与启动器的问题之后，环境表面上已经趋于稳定，但在安装插件时，新的问题集中爆发——Git 与 GitHub 相关操作频繁失败。
这一阶段的问题，往往最消耗时间，也最容易让人误以为“前面的配置全白做了”。
5.1 现象
具体表现包括：
- 在终端中执行
git --version，提示命令不存在 - 通过绘世启动器或命令行安装插件失败
- Impact-Pack 无法安装完成
- 其依赖的
sam2仓库始终无法拉取成功
从现象上看，像是 Git、网络、代理、Python 全部“同时出了问题”。
5.2 原因一：Git 未加入 PATH
在排查过程中，首先确认的是 Git 是否真的可用。
实际情况是：
- Git 已经安装过
- 但安装完成后，终端并未刷新
- 或 Git 路径尚未加入当前会话的 PATH
这会直接导致：
- Git 已存在，但命令行无法识别
- 启动器调用 Git 时同样失败
解决方式
最简单、也是最容易被忽略的一步：
- 完全关闭并重新打开 PowerShell / CMD
- 验证 Git 是否可用：
git --version
where git
当终端能正确输出 Git 版本号与路径时，才能确认 Git 本身没有问题。
5.3 原因二：GitHub 网络不稳定（核心问题）
在确认 Git 可用之后，Impact-Pack 的安装仍然失败，错误信息开始集中指向 GitHub 拉取阶段。
典型报错
RPC failed; curl 56 Recv failure
fatal: early EOF
本质分析
这一类报错有一个非常重要的特征：
- 并非“连不上 GitHub”
- 而是 在拉取过程中连接被中断
这说明：
- GitHub 在当前网络环境下是“可访问但不稳定的”
- 尤其是：
- 仓库体积较大
- 使用
git clone/pip install git+https://...方式 - 位于国内网络或代理环境中
需要明确的一点是：
这类问题并不是配置错误，而是网络现实。
即便：
- Python 正确
- Git 正确
- 代理已开启
- GitHub 网页可以访问
也仍然可能在 clone 阶段反复失败，尤其是像 sam2 这样体量较大的研究仓库。
这一节的结论，其实非常现实，也非常重要：
并不是所有 GitHub 插件，都适合在当前网络环境下“一次性安装成功”。
六、代理与 GitHub：正确的判断方法
在插件安装阶段，很多问题会被笼统地归结为“网络不行”或“代理没开好”，但如果缺乏明确的判断手段，就很容易陷入反复试错。
因此，有必要先明确一件事：
GitHub 是否“真的能访问”，必须用 Git 本身来验证，而不是靠浏览器感觉。
6.1 判断 GitHub 是否“真的能访问”
一个非常可靠、且成本极低的判断方式是使用 Git 的只读请求：
git ls-remote https://github.com/facebookresearch/sam2
这一命令的特点是：
- 不下载仓库内容
- 只请求 GitHub 返回远程引用信息（refs）
- 能直接验证 Git + 网络 + 代理 是否整体可用
根据执行结果，可以快速得出结论：
- ✅ 有输出（大量 hash 与 refs）
说明：- GitHub 可访问
- Git 代理配置生效
- 网络是“通的”
- ❌ 无输出 / 超时 / 直接报错
说明：- Git 未走代理
- 或代理端口错误
- 或当前网络环境无法稳定访问 GitHub
这个判断步骤非常重要，因为它可以避免一个常见误区：
浏览器能打开 GitHub ≠ Git 能稳定访问 GitHub。
浏览器访问成功，只说明 HTTP 请求偶尔可达；
而 Git clone / fetch 属于长连接与大数据传输，对网络稳定性要求更高。
6.2 设置 Git 代理（示例）
在确认需要使用代理的情况下，应当直接为 Git 单独配置代理，而不是依赖系统或工具的“自动识别”。
示例如下（以本地代理端口 7897 为例）：
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897
配置完成后，可以再次验证：
git config --global --get http.proxy
git config --global --get https.proxy
如果配置正确，Git 的所有 HTTPS 请求都会走该代理端口。
需要注意的是：
- Git 代理只影响 Git，不影响浏览器
- pip 镜像、Python 依赖下载，与 Git 代理是两套体系
- 即便代理配置正确，大型仓库在国内网络环境下仍然可能出现中断
通过上述方法，可以把 GitHub 相关问题拆分为三个明确状态：
- Git 本身是否可用
- Git 是否正确走代理
- 网络是否足够稳定支撑大型仓库拉取
只有在这三个条件同时满足时，插件安装才“有成功的可能”，而不是“靠运气”。
八、最终状态总结（当天成果）
在对上述问题逐一拆解并修复之后，整个环境最终回到了一个可控、稳定、可复现的状态。回顾当天的实际成果，可以明确确认以下几点：
- ✅ Python 版本问题已解决
系统 Python 与 ComfyUI 运行 Python 完全隔离，运行环境明确锁定在 Python 3.10。 - ✅ venv 与启动器成功对齐
启动器不再调用系统 Python，而是显式使用 ComfyUI 对应的虚拟环境，命令行与一键启动行为保持一致。 - ✅ CUDA / PyTorch 工作正常
PyTorch 能正确识别 CUDA，torch.cuda.is_available()返回True，GPU（RTX 4070 Laptop）被正常调用。 - ✅ ComfyUI 成功启动
主程序可以稳定运行，不再出现环境相关报错。 - ✅ WebUI 正常访问
浏览器可稳定访问http://127.0.0.1:8188，基础工作流已具备运行条件。
需要特别说明的是：
插件（如 Impact-Pack / SAM2）的安装问题，并不影响上述核心成果的成立。在环境层面，ComfyUI 的基础运行条件已经全部满足，后续问题更多属于“插件与网络环境的博弈”，而非系统配置失败。
这一阶段的完成，意味着：
环境问题已经从“系统级不确定性”，降级为“可选插件的可用性问题”。
这也是从“新手踩坑阶段”迈向“可持续使用阶段”的关键分水岭。
九、经验总结与延伸阅读（写给后来者）
回顾这次 ComfyUI 环境配置的全过程，最大的收获并不是“装好了一个工具”，而是对 AIGC 工具链在真实使用环境下的运行逻辑有了更清醒的认识。
很多问题在事后看来都不复杂，但在当下却极具迷惑性。归根结底，它们并不是单点技术错误，而是多个工具之间的默认假设发生了冲突。
最后，用几句话作为本次踩坑的经验总结，也希望能帮到正在折腾环境的你：
- AIGC 环境配置的难点，不在技术本身，而在工具之间的“默认假设冲突”
- Windows 下折腾 ComfyUI，第一原则永远是：隔离环境（venv）
- 插件不是越多越好，能稳定跑起来，才是王道
- 当你卡在 GitHub，不一定是你哪里配错了，而可能只是网络现实
在完成基础环境稳定之后，后续的重点就不再是“能不能跑”，而是如何让 ComfyUI 真正服务于创作与效率，包括：
- 工作流设计
- 节点取舍
- 插件选择
- 以及如何避免重复踩坑
如果你对 ComfyUI / AIGC 工具链的实践经验与进阶思考感兴趣，也可以参考我之前整理的一篇相关文章：
👉 延伸阅读：
https://blog.csdn.net/Assert_SL/article/details/156771067?spm=1001.2014.3001.5501
后续也会持续更新更多偏实战、偏复盘、少玄学的 AIGC 使用记录，希望能对同样在路上的你有所帮助。
