崩溃日志在哪、长什么样
崩溃后第一件事：打开 .minecraft/crash-reports/ 目录，最新的 txt 就是崩溃报告（启动失败则在启动器日志里）。报告虽长，关键信息只有三段：第一段 Description（一句话说明哪炸了）；第二段抛出异常的调用栈（java.lang.XXXException 那几行）；最后 Suspected Mods（游戏自己怀疑的模组列表，准确率约七成）。90% 的排查只需这三段。
注意： 看不懂英文调用栈没关系——直接把报告丢进 AI 或粘贴到模组社区，比逐行读快得多。
四类常见冲突对照表
崩溃信息千变万化，但根因基本逃不出四类：
| 冲突类型 | 典型报错关键词 | 成因 | 解法 |
|---|---|---|---|
| Mixin 注入失败 | MixinApplyError / MixinTargetNotFound | 两个模组改同一处游戏代码，或版本不匹配 | 降级其一，或找兼容补丁 |
| 注册 ID 冲突 | Duplicate key / Registry entry already exists | 两个模组注册了同名物品/方块 | 改 config 里的 ID 前缀 |
| API 缺失 | NoSuchMethodError / NoClassDefFoundError | 缺少前置（Fabric API/KotlinLib 等） | 安装缺失的前置库 |
| 版本错配 | expects Minecraft 1.x.y | 模组版本与游戏版本不符 | 下载对应游戏版本的模组 |
二分法排查流程
Suspected Mods 列表不确定时用二分法：1）把 mods 文件夹里一半模组移出去，启动测试；2）崩溃消失→元凶在移出的那一半；崩溃依旧→在留下的那一半；3）对可疑的那一半再对半，重复 3-4 轮就能锁定单个模组。100 个模组最多 7 轮定位。进阶技巧：先按「最近新装」优先排除——八成冲突来自最新加入的模组。
防患于未然
装模组前做三件事能避开 90% 的冲突：1）核对游戏版本+加载器（Forge/Fabric）完全一致；2）逐个补齐前置库；3）大版本更新时不要直接覆盖 mods 文件夹——新建实例分批迁移。配合 Debug 工具模组（如 Spark 性能分析）和整合包平台的依赖解析，可以把排查时间从小时级降到分钟级。
注意： 改 config 前先备份原文件。手滑改错 ID 前缀导致的「存档物品消失」比冲突本身更难恢复。
✓ 最后验证于 Minecraft 1.22（2026-09-22） Minecraft 的机制随版本不断变化，本攻略仅在所标注版本下保证有效。