日志、诊断与求助
保存完整错误、生成诊断包并提交可复现的问题报告。
高质量的问题报告应该让没有看到你屏幕的人也能还原发生了什么。只有一句“启动不了”或一张最终弹窗截图，通常不足以判断问题来自应用、实例还是 WebUI。
先保存原始信息
问题发生后尽快收集：
- 操作发生的日期和时间。
- Hanafubuki 版本、操作系统和硬件平台。
- WebUI 类型、Core 版本和实例名称。
- 复现前修改过的版本、扩展、模型、参数或环境变量。
- 当前页面的失败状态和任务中心中的完整活动输出。
- Python traceback、命令退出码以及错误前后的日志。
长期保留的任务输出可能被截断或淘汰。看到截断标记时，应复制当前日志或生成诊断包，不要假设之后仍能读取相同内容。
阅读 Python traceback
找到最后一段
Traceback (most recent call last):。沿调用路径查看文件属于 Core、扩展、自定义节点还是 Python 包。
记录最后的异常类型和描述，例如
ImportError 或 RuntimeError。搜索时组合异常描述、WebUI 名称、扩展名和版本；求助时保留完整 traceback。
第一条红色文字不一定是根因。启动过程可能先记录警告，之后才出现真正导致进程退出的异常；也可能一个扩展失败但 WebUI 仍然成功启动。
选择诊断包
| 类型 | 适用情况 | 入口 |
|---|---|---|
| 实例诊断 | 某个实例安装、启动、扩展、热补丁或环境异常 | “实例管理 → 维护 → 诊断” |
| 应用诊断 | 应用运行环境、设置、平台、全局任务或多个实例同时异常 | “设置 → 日志与诊断” |
实例诊断以当前实例为主；应用诊断可以按设置包含所有实例。不要为了“信息更多”默认收集全部实例，先选择能覆盖问题的最小范围。
求助模板
问题：一句话描述实际结果和期望结果
Hanafubuki 版本：
操作系统与硬件：
WebUI 类型与 Core 版本：
实例名称：
复现步骤：
1.
2.
3.
最近改动：扩展 / 模型 / PyTorch / 启动参数 / 更新
首次错误时间：
核心异常：
完整日志或诊断包：
已经尝试的操作及结果：“已经尝试”应写明修改了什么以及错误是否变化，不要只写“网上的方法都试过”。如果运行过删除、重装依赖或 Git 重置，也必须说明，否则维护者可能基于已经改变的环境给出错误判断。
选择正确的求助渠道
- Hanafubuki 无法准备运行环境、管理任务、持久化设置或呈现窗口：提交给 Hanafubuki 维护者。
- WebUI Core 在已启动实例中报错：提交给对应 WebUI 项目。
- 只有某个扩展或自定义节点报错：先阅读其说明，再提交给扩展作者。
- 模型或工作流缺少组件、版本不匹配：联系发布者并提供所需依赖信息。
反馈 Hanafubuki 问题
确认问题来自 Hanafubuki 后，前往 Hanafubuki GitHub Issues 搜索是否已有相同反馈。新建 Issue 时请使用上面的求助模板，并附上可复现步骤、完整错误和必要日志；不要公开上传包含凭据或私人数据的诊断包。