Stable Diffusion WebUI（简称SD WebUI）在启动和运行过程中，会在控制台输出大量日志信息。很多用户一看到红色的ERROR或者黄色的WARNING就慌了神，不知道是环境崩了还是可以忽略。实际上，这些日志大多都有明确的指向性，只要掌握解读方法，绝大多数问题都能在几分钟内定位并解决。本文将按日志严重程度分类，逐条分析常见的WARNING与ERROR信息，并给出对应的处理方案。
一、先搞清楚日志的三个级别
SD WebUI的日志基于Python标准的logging模块输出，主要分为三个级别。INFO是普通信息，显示程序正在做什么，例如加载模型、启动Gradio界面等，出现这种日志完全不用管。WARNING是警告，表示程序发现了某些不正常但不致命的情况，通常功能还能正常使用，只是性能或部分特性受影响。ERROR则是错误，意味着某个操作已经失败，如果不处理，对应功能大概率无法正常工作。
一个实用的判断技巧是：看错误出现后程序是否继续往下走。如果ERROR之后紧跟着Application startup complete并且能打开网页界面，说明错误发生在非关键路径上，可以先记录下来再排查。如果程序直接退出或卡死，那就是阻塞性问题，必须优先解决。
另外建议启动时加上--log-startup参数或者重定向输出到文件，例如执行./webui.sh 2>&1 | tee startup.log（Windows下用webui-user.bat启动时可在文件末尾追加日志重定向），这样事后分析会方便很多。
二、常见WARNING信息解读与对策
1. Warning: xformers not installed或Xformers is disabled
这条警告表示没有安装或没有启用xformers加速库，SD WebUI会自动回退到普通attention计算。后果是显存占用偏高、出图速度略慢，但功能完全不受影响。如果你的显存比较紧张（8GB以下），建议在webui-user.bat的COMMANDLINE_ARGS中加上--xformers参数，前提是已经安装了对应版本的xformers。如果装了xformers仍然报这个警告，多半是xformers版本与Torch版本不匹配，需要重新安装匹配版本。
2. torch.cuda.is_available()返回False相关警告
日志中出现CUDA is not available或者提示将使用CPU运行时，说明PyTorch检测不到NVIDIA显卡。常见原因有三类：一是显卡驱动过旧，去NVIDIA官网更新驱动即可；二是安装了CPU版本的Torch，需要重新安装CUDA版本；三是显卡本身不支持（例如部分AMD或集成显卡），此时只能考虑使用CPU模式或换用针对AMD优化的启动分支。CPU出图的速度会慢一个数量级以上，要有心理准备。
3. Warning: images out of focus或采样器警告
某些版本在切换到不推荐的采样器或参数组合时会出现提示性警告，例如DPM adaptive类采样器在高步数下的提醒。这类警告属于建议性质，出图质量由你自己判断，不需要强制修改。但如果警告中包含sampler相关的降级信息，说明当前版本的k-diffusion库不支持该采样器，程序已经自动替换成默认采样器，此时需要留意实际效果是否达标。
4. 权重文件哈希或元数据警告
加载模型时出现Couldn't read hash或pickle相关的警告，通常是模型文件来自第三方站点，元数据格式与标准不一致。这不影响出图，只影响模型列表页显示的哈希值。可以放心忽略，或者用工具重新计算一次哈希缓存即可。
三、高频ERROR信息与排查方案
1. RuntimeError: CUDA out of memory
这是新手遇到最多的错误，本质是显存被耗尽。典型日志片段如下：
RuntimeError: CUDA out of memory. Tried to allocate 2.00 GiB (GPU 0; 8.00 GiB total capacity; 1.50 GiB already has been allocated)
从日志可以直接读出关键信息：总显存8GB，已占用1.5GB，还需要2GB分配失败。对策按优先级排列：第一，降低分辨率，1024x1024改512x512显存需求会下降到约四分之一；第二，在启动参数中加入--medvram或--lowvram，让程序分块加载模型；第三，关闭其他占用显存的程序，比如浏览器开着大量标签页、后台挂着游戏或视频软件；第四，减少批量出图数量，batch size改为1；第五，启用--xformers降低attention计算的显存开销。
2. OSError: Cannot find index.json for lora或模型目录为空
报错信息中包含Couldn't find Stable Diffusion in ...或者指向models目录下找不到checkpoint，说明程序的工作目录配置有误。SD WebUI默认在安装目录下的models/Stable-diffusion中查找模型文件，如果你把模型放在了别的盘，需要用--ckpt-dir参数指定路径，或者直接把safetensors文件复制到默认目录。注意路径中不要包含中文和空格，历史上不少报错都是路径问题导致的。
3. Error loading pickled data或safetensors加载失败
这条错误常见于下载不完整的模型文件。判断方法是看文件大小是否与发布页一致，如果明显偏小说明下载被中断，重新下载即可。另一种情况是模型本身损坏或版本过旧（比如SD1.5的模型放在了仅支持SDXL的部署里），此时日志通常会附带具体的字段缺失信息，按提示更换匹配的模型版本。出于安全考虑，也建议优先下载safetensors格式而非ckpt格式，前者不会执行任意代码。
4. Address already in use端口占用错误
日志出现OSError: [Errno 98] Address already in use（Windows下是WinError 10048），说明7860端口被占用，通常是上一次启动的WebUI没有完全退出。找到残留的Python进程结束掉，或者用--port 7861换一个端口启动。批量处理时可以用命令查看占用端口的进程：
# Linux/Mac 查看占用7860端口的进程 lsof -i :7860 # Windows下使用 netstat -ano | findstr 7860
拿到进程号PID后，Linux用kill -9 PID，Windows在任务管理器中结束对应进程即可。
5. Gradio或依赖库版本冲突
日志中出现ImportError或ModuleNotFoundError，并且模块名看起来是gradio、pydantic之类的基础库，说明依赖环境被破坏。常见诱因是手动pip安装了某个插件要求的包版本，把原有依赖覆盖了。最省事的处理方式是删除venv目录后重新启动，让程序重建虚拟环境；如果网络慢，可以先配置国内镜像源。装插件时也要养成习惯，优先选择仍在维护的扩展，长期不更新的扩展是环境损坏的主要来源。
四、建立自己的日志排查流程
面对一条陌生报错，推荐按固定流程处理：第一步，完整复制错误堆栈的最后一行，因为真正的错误原因通常在最后一行，上面的堆栈只是调用链；第二步，用最后一行的关键短语搜索，优先看GitHub仓库的Issues区，那里聚集了最同质化的问题场景；第三步，回顾报错前你做过什么改动，新装的扩展、新换的模型、新改的参数，八成问题都出在最近的变更上；第四步，做最小化复现，禁用所有扩展启动（加--disable-all-extensions参数），如果问题消失，就用排除法逐个启用扩展定位元凶。
还有一个容易被忽略的点：报错信息里包含大量环境细节，例如PyTorch版本、Python版本、显卡型号和显存大小。在社区提问时，把这些信息连同完整堆栈一起贴出来，往往能更快得到有效答复。养成阅读日志的习惯，比盲目重装环境高效得多，也能让你对SD WebUI的运行机制有更深的理解。