彻底解决 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 等插件的正常运行。

如果你也遇到了类似问题，直接按照本文步骤操作即可实现修复。