彻底解决 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
- 新版本 Protobuf 移除了
GetPrototype方法，导致兼容性崩溃
这个问题非常常见，尤其是在 2025–2026 年期间，很多插件的依赖约束不严格，会让 pip 自动把 Protobuf 升级到最新版。而且几乎每次重新启动都会出现 Protobuf 的升降级安装操作，严重拖慢启动时间。
二、问题原因深度分析
通过日志分析和依赖回溯，我发现问题由以下几个因素共同导致：
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() → 被移除 于是出现启动报错。
三、环境信息（可复现）
为了让大家能够 100% 复刻修复过程，我把环境也公开出来：
- 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
这个版本是“黄金兼容版本”：
- 满足 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
不需要手动 pip install，WebUI 会自动处理依赖。
启动成功的标志：
- 无
GetPrototype报错 - 无 onnx 编译错误
- 所有插件正常加载
- 可以正常生成图片
五、修复成功验证
启动日志应显示：
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 覆盖，导致版本再次被升级。
3. 不要随意升级 Protobuf
Protobuf 4.x+ 对 WebUI 生态几乎完全不兼容。
4. 网络配置非常关键
错误的代理设置会导致依赖安装失败，从而触发各种奇怪的报错。
5. 应用猴子补丁
如果你愿意折腾，可以尝试我们实践过的“猴子补丁”办法，专门针对 在不降级 Protobuf 版本的情况下，解决 Protobuf 的兼容性问题。
【技术分享】ComfyUI中protobuf版本兼容性问题的优雅解决方案：猴子补丁实战
七、结语
通过统一锁定 Protobuf 版本，我们成功解决了 WebUI 启动报错问题，同时保证了 roop、ControlNet 等插件的正常运行。
如果你也遇到了类似问题，直接按照本文步骤操作即可实现修复。