ModuleNotFoundError: No module named 'kornia' in ComfyUI
修复 ComfyUI 报 No module named kornia 的问题,并恢复内置的 post-processing、canny、morphology 节点。
如果 ComfyUI 日志里出现 ModuleNotFoundError: No module named 'kornia',服务本身可能还能启动,但一批内置 extra 节点会加载失败。
这次真实实验里,它没有把整个 server 打死,而是让几个内置 comfy_extras 模块导入失败,直到 kornia 被安装到同一个 Python 环境里为止。
快速处理
对 GitHub Windows 便携包:
.\python_embeded\python.exe -s -m pip show kornia
.\python_embeded\python.exe -s -m pip install "kornia>=0.7.1"
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build然后看启动日志里 post-processing、canny、morphology 那些 IMPORT FAILED 有没有消失。
真实日志长什么样
这次实验里,失败的是这些内置文件:
Cannot import ...\ComfyUI\comfy_extras\nodes_post_processing.py module for custom nodes: No module named 'kornia'
Cannot import ...\ComfyUI\comfy_extras\nodes_canny.py module for custom nodes: No module named 'kornia'
Cannot import ...\ComfyUI\comfy_extras\nodes_morphology.py module for custom nodes: No module named 'kornia'关键在于路径。这不是第三方插件,而是 ComfyUI 自己带的 extra 节点。
快速判断
| 你看到什么 | 代表什么 | 第一动作 |
|---|---|---|
No module named 'kornia',而且来自 comfy_extras | 内置 extra 节点依赖缺失 | 在当前 ComfyUI Python 里安装 kornia |
日志里已经出现 Starting server | 核心 server 没死 | 这是“节点不可用”的部分故障 |
| 只有 canny、morphology、post-processing 节点不见了 | 很大概率就是 kornia | 先修 kornia |
custom_nodes 下面的插件也报 kornia 缺失 | 可能内置和插件都在要它 | 但安装位置仍然是同一个环境 |
装完 kornia 后节点数明显增加 | 内置 extras 恢复了 | 这是最直接的验证 |
第 1 步:先看本地 requirements
实验环境里,ComfyUI\requirements.txt 有:
kornia>=0.7.1你自己的环境先查本地:
Get-Content ComfyUI\requirements.txt | Select-String "kornia"这样你可以确认:当前这套 ComfyUI 代码是不是本来就把 kornia 当运行时依赖。
第 2 步:装到真正启动 ComfyUI 的 Python 里
Windows 便携包:
.\python_embeded\python.exe -s -m pip install "kornia>=0.7.1"手动 venv:
python -m pip install "kornia>=0.7.1"实验里,这一步还顺带装了 kornia_rs,这是正常的。
第 3 步:重启,确认失败节点回来
重新启动 ComfyUI,再看日志:
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build实验环境里:
- 装
kornia之前,/object_info节点数是 657 - 装
kornia之后,/object_info节点数变成 685
而且那几个和 kornia 相关的 IMPORT FAILED 都消失了。
第 4 步:为什么它不一定算“整站启动失败”
kornia 这类问题看起来很吓人,因为日志里会打印 Cannot import ... module for custom nodes,但它不一定会把整个服务打死。
它更常见的含义是:
- 浏览器 UI 能打开
- 核心出图流程可能还能跑
- 但内置图像处理节点缺了一块
如果你的工作流确实要用 canny、morphology、post-processing,那这依然是实打实的问题。只是它和 sqlalchemy、torch、comfyui-frontend-package 这种“服务起不来”的错误不是一个等级。
不要做这些事
- 不要因为
kornia缺失就默认整个环境必须重装 - 不要把
kornia装到一个根本不启动 ComfyUI 的 Python 里 - 不要只看到 server 启动了,就忽略节点其实还没恢复
- 不要在内置 extra 节点还没恢复前,把内置问题和插件问题混在一起修
Wonderful Launcher 能帮什么
这类问题不是“浏览器能不能打开”那么简单,而是“预期的节点面有没有回来”。Wonderful Launcher 更适合这种场景,因为它能把运行时活着和节点面恢复区分开来看。
相关指南
- ComfyUI 便携版依赖损坏后,按一个报错一个包修启动
- ComfyUI No module named 警告:什么时候可以忽略
- ComfyUI Startup Failed
- ComfyUI 依赖冲突
- OpenGL dependencies not available in ComfyUI
来源与实测
- 2026-05-18 Windows 便携版实验:
No module named 'kornia'导致nodes_post_processing.py、nodes_canny.py、nodes_morphology.py导入失败 - 同一实验
ComfyUI\requirements.txt:包含kornia>=0.7.1 - 同一实验验证:安装
kornia后,/object_info节点数从 657 增加到 685
你可以手动修复,也可以下载 Windows 版 Wonderful Launcher 自动诊断插件报错、依赖缺失和环境损坏,不用盲目重装。
免费下载 Windows 版Did this fix your issue?
Your answer helps prioritize verified ComfyUI repairs.