修复 ComfyUI 前后该记什么：一份可复查的环境记录

这不是别人的修复案例

下面是本站设计的记录方法，没有套用任何启动器的客户日志、遥测统计或成功案例。先写下任务、症状与失败阶段，再记录操作，避免事后只剩一句“重装就好了”。

环境记录的三层

Python 元数据可以查询分发包信息，但导入名到分发包名的映射在部分可编辑安装中不可靠；pip inspect（pip 22.2 起提供）输出环境报告；pip check 检查已安装包声明的依赖关系。123 这些都不能单独证明 GPU 算子或工作流正常。

请使用实际启动该 ComfyUI 实例的解释器；下方的 python 只是占位符。先核对 pip 版本；如果没有 pip inspect，记录版本即可，不必为生成记录贸然改动依赖。

python -m pip --version
python -m pip inspect > environment-before.json
python -m pip check

完整的 pip 报告可能包含本地路径、来源或私有仓库信息，先在本地检查和脱敏再分享。下载只读环境检查脚本，用同一解释器运行 python inspect_environment.py 可取得较短的元数据摘要。脚本自身不安装包，也不读取提示词、日志或令牌；Python 正常的启动钩子仍可能生效。分发包名称和版本也可能敏感，--include-paths 会明确加入私有解释器路径。分享前仍要检查输出。

本文建议的记录顺序

保存最小工作流和输入；记下当前节点版本与环境；每次只修改一项并写明理由；重启同一实例；使用相同输入再次运行。自定义节点隔离可以参考 ComfyUI 官方排错方式。4 禁用节点不应被记录为已经撤销它过去的依赖修改。

一条记录的字段

原错误 → 环境摘要 → 修改项 → 修改依据 → 新日志 → 原任务结果 → 是否回退。未做的检查填“未做”，只有安装成功就填“安装成功”，不填写“全部修复”。

完成后

保留仍然未知的条件和需要再次复核的触发点。本文不把试验次数、错误条数换算成独立用户数量，也不继承来源网站的 Verified 标签。

相关排查

• ComfyUI 教程里的命令该粘到哪里？PowerShell、CMD、虚拟环境分开看
• 启动日志里一堆“缺模块”：哪些要处理，哪些先记录？

2026-09-25 复核资料、脚本行为与英中文技术对应。元数据脚本通过本地单测；本站未进行 ComfyUI 修复、GPU 或工作流复现。上游说明与本站建议仍分开标识。