彻底解决 Stable Diffusion WebUI 启动报错：AttributeError: ‘MessageFactory’ object has no attribute ‘GetProto

彻底解决 Stable Diffusion WebUI 启动报错：AttributeError: ‘MessageFactory’ object has no attribute ‘GetPrototype’

Stable Diffusion web UI

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

sd-webui-roop

【技术分享】ComfyUI中protobuf版本兼容性问题的优雅解决方案：猴子补丁实战

告别环境崩溃：ONNX 与 Protobuf 版本兼容性指南

一、问题背景

最近在维护 Stable Diffusion WebUI（v1.10.1）环境时，很多朋友反馈，在安装了 sd-webui-roop 插件后，启动时会遇到一个棘手的 Protobuf 版本冲突错误：

AttributeError: ‘MessageFactory’ object has no attribute ‘GetPrototype’

这个报错信息其实指向了一个非常典型的问题，通常意味着三件事：

• 你环境里的 Protobuf 被自动升级到了 4.x / 5.x / 6.x 等新版本。
• 而像 ControlNet、roop 这类插件，依赖的却是 Protobuf 3.x 时代的旧版 API。
• 新版本直接移除了旧方法 GetPrototype，导致插件一调用就崩溃。

这可不是个案。尤其是在最近两年，很多插件的依赖约束写得不严格，pip 在安装时就会自作主张，把 Protobuf 一路升级到最新版。更糟的是，这个过程可能每次重启 WebUI 都会重复一次，不仅导致报错，还严重拖慢了启动速度。

二、问题原因深度分析

通过梳理日志和追溯依赖关系，问题根源逐渐清晰，主要是以下几个环节的连锁反应：

1. sd-webui-roop 的 requirements.txt 没有限制 Protobuf 版本

打开它的依赖文件，原始内容是这样的：

insightface==0.7.3 onnx==1.14.0 onnxruntime==1.15.0 opencv-python==4.7.0.72 ifnude cython

注意到问题了吗？整份文件里，对 protobuf 只字未提，没有任何版本约束。

2. onnx==1.14.0 的内置依赖要求 protobuf>=3.20.2

然而，这个要求只有下限，没有上限。于是 pip 在解析依赖时会做出这样的判断：

protobuf >= 3.20.2 → 那安装最新版（比如 6.33.4）完全符合要求

就这样，Protobuf 被悄无声息地升级到了不兼容的新版本。

3. ControlNet 等插件依赖 Protobuf 3.x 的旧 API

这步是压垮骆驼的最后一根稻草。从 Protobuf 4.x 开始，官方对 Python API 进行了大量不向后兼容的改动，其中一个被移除的方法就是：

MessageFactory.GetPrototype() → 已废弃删除

当插件尝试调用这个不存在的方法时，启动报错便不可避免。

三、环境信息（可复现）

为了确保大家能完全复现并验证修复过程，这里公开我的具体环境，供你参考对照：

• 操作系统：Windows 11 专业工作站版 26H1（28020.1371）
• Python：3.11.13（基于 EPGF 架构，非 CPython/Anaconda）
• 虚拟环境：.venv
• CMake：4.2.1
• pip：25.3
• WebUI：v1.10.1（最终稳定版）
• 关键插件：sd-webui-roop（最新版）、sd-webui-controlnet v1.1.455

四、完整修复方案（可直接操作）

理论分析完毕，下面是经过实战验证的、一步步的修复操作。跟着做，基本都能解决问题。

步骤 1：修改 3 个关键文件，统一锁定 protobuf==3.20.2

为什么是 3.20.2 这个版本？可以说它是当前环境下的“黄金兼容版本”：

• 它满足了 onnx==1.14.0 的最低要求（>=3.20.2）。
• 它属于 3.x 系列，完美保留了旧版 API。
• 它足够稳定，避免了某些边缘情况下的编译问题。

需要动刀的文件共有三个：

1）stable-diffusion-webui/requirements.txt

在文件中添加或修改对应行：

protobuf==3.20.2

2）stable-diffusion-webui/requirements_versions.txt

同样，添加或修改对应行：

protobuf==3.20.2

3）extensions/sd-webui-roop/requirements.txt

在文件末尾追加一行：

protobuf==3.20.2

修改完成后的完整内容应如下所示：

insightface==0.7.3 onnx==1.14.0 onnxruntime==1.15.0 opencv-python==4.7.0.72 ifnude cython protobuf==3.20.2

步骤 2：保持 webui-user.bat 网络配置正确（避免下载失败）

环境配置不对，一切白费。下面是我使用的、能够稳定运行的配置示例：

【SD WebUI踩坑】启动报错 Expecting value: line 1 column 1 (char 0) 的终极解决方案

@echo off set HTTP_PROXY=http://127.0.0.1:7897 set HTTPS_PROXY=http://127.0.0.1:7897 set NO_PROXY=127.0.0.1,localhost set HF_ENDPOINT=https://hf-mirror.com set PYTHON=.venv\Scripts\python.exe set GIT= set VENV_DIR=.venv set COMMANDLINE_ARGS=--xformers --gradio-queue --disable-nan-check call webui.bat

这里有两个关键点值得注意：

• 务必设置 NO_PROXY，否则很容易引发神秘的 Expecting value 类报错。
• 通过 HF_ENDPOINT 使用镜像源，能显著加速模型文件的下载。

步骤 3：重新启动 WebUI

完成以上修改后，直接重新启动 WebUI 即可。无需手动执行 pip install 命令，启动脚本会自动处理依赖安装。

成功启动的标志非常明确：

• 启动日志中不再出现 GetPrototype 相关报错。
• 没有关于 onnx 的编译错误信息。
• 所有已安装插件（如 roop, ControlNet）均显示加载正常。
• 能够顺利进入界面并正常生成图片。

五、修复成功验证

如何确认修复真的生效了？查看启动日志，你应该能看到如下关键信息：

Requirement already satisfied: protobuf==3.20.2

同时，插件成功加载的提示也应出现：

roop - INFO - roop v0.0.2 ControlNet - INFO - ControlNet v1.1.455

最终，图片生成进度条会安稳地走到 100%，大功告成。

六、经验总结（非常重要）

解决这个问题后，有几点深度经验值得记录和分享：

1. Protobuf 3.20.2 是 WebUI 的“最佳兼容版本”

这个版本巧妙地平衡了多方需求：既满足 onnx>=1.13.0 的硬性门槛，又兼容 ControlNet、roop 等插件依赖的旧版 API，同时还能规避一些潜在的编译错误。

2. 必须同时修改 3 个文件

只改一处是没用的。插件自身的 requirements.txt 优先级很高，如果不同步锁定版本，在后续安装中它又会把 Protobuf 版本“拉”上去，导致问题复现。

3. 不要随意升级 Protobuf

在这个生态里，Protobuf 4.x 及以上版本几乎可以视为“不兼容版本”。除非所有插件都明确声明支持，否则坚守 3.x 系列是更稳妥的选择。

4. 网络配置非常关键

看似无关的网络代理设置，往往是许多依赖安装失败和诡异报错的源头。一个正确的配置能帮你省去大量排查时间。

5. 备用方案：应用猴子补丁

当然，如果你是一名喜欢深究的技术爱好者，还有一种更“硬核”的解决方案：通过“猴子补丁”（Monkey Patch）的方式，在不降级 Protobuf 版本的前提下，动态修复 API 兼容性问题。这为我们提供了另一种解题思路。

【技术分享】ComfyUI中protobuf版本兼容性问题的优雅解决方案：猴子补丁实战

七、结语

通过统一锁定 Protobuf 版本这一核心操作，我们成功绕开了版本冲突的陷阱，确保了 Stable Diffusion WebUI 及其重要插件的稳定运行。环境配置从来不是魔法，而是对依赖关系的精确管理。

如果你也碰到了同样的启动报错，不必焦虑，直接参照本文的步骤操作，问题大概率能迎刃而解。