01 先定整合包版本，再选托管
模组服托管先看软件兼容：记录整合包名称与发行版、Minecraft 版本、加载器类型和构建。Fabric 模组不能默认用于 Forge 或 NeoForge，小补丁版本也可能需要另一份文件。Fabric installation guide / Fabric 安装说明 ↗ 明确要求匹配游戏与加载器。
不存在适合所有整合包的“最佳 Minecraft 版本”。从实际想玩的包出发：核心模组尚未支持新版时，新版就不是这组玩家的合理默认值。采用作者支持的组合，不单独升级其中一个组件。
02 服务端包不等于复制客户端实例
作者提供服务端发行包时优先使用，其中可能含加载器启动脚本、配置及自定义脚本或数据，仅复制客户端 mods 目录可能不完整。客户端还可能带有不适用于无图形服务端的画面、菜单和输入模组。
| 清单项 | 上传前记录 |
|---|---|
| 核心软件 | 游戏、加载器、整合包发行版。 |
| 必需文件 | 作者列出的服务端模组、配置、脚本与自定义数据。 |
| 客户端要求 | 精确客户端包及必要资源依赖。 |
| 运行时 | 受支持的 Java 路径与启动脚本。 |
| 回退 | 完整旧世界与可用整合包副本。 |
Fabric FAQ ↗ 提供多个整合包分发平台入口。使用作者原始发行版和文档，不采用名字相似的转载包。
03 先验证全新实例，再导入世界
- 用选定服务端文件创建独立实例。
- 按文档用指定 Java 运行安装与启动脚本。
- 阅读许可，仅同意后接受，并等待启动完成。
- 匹配客户端加入，核对一个整合包特有功能。
- 停服后，将旧世界副本导入测试实例，再验收内容。
全新世界正常、旧世界失败时，应优先检查存档或配置兼容，不能直接判断商家有问题。导入验收前保留原实例，不让两个进程同时操作同一活动目录。
04 通过代表性负载判断容量
下载包大小不能直接换算所需内存。让玩家使用实际机器、实体和维度，记录内存压力、重复 tick 延迟及磁盘增长。给操作系统留余量，把全部内存分配给 Java 堆可能影响整个系统。
启动失败看 Exit-code workflow / 退出码排障；能运行但卡顿时，采集兼容的 spark profile / spark 报告。询问商家是否允许切换 Java、自定义启动脚本、完整导出和保留世界扩容，这比“支持全部模组”的宣传更有用。
05 把整合包更新作为一次受控变更
升级前记录可用版本清单，导出完整世界与必需整合包文件。阅读迁移说明，在副本测试新版本，并让常用玩家核对进度和自定义方块。被新版模组打开的世界未必能安全降级，必须保留更新前副本。
缺少 Cloth Config 等依赖时按精确加载器与版本修复，见 Dependency guide / 依赖指南。光影问题应看 Client rendering / 客户端画面排查，不要默认重装服务端。每次只做能清楚归因的小改动。