测试、兼容与发布

能够在开发者设备上启动只是第一步。可发布 MOD 还需要明确版本、可重复安装、可卸载、不会悄悄破坏存档，并能让其他开发者定位问题。

分层测试

1. 文件级： 检查 XML、CSV、图片、模型和清单格式。
2. 加载级： 只启用当前 MOD，确认入口与资源全部加载。
3. 新世界： 验证生成、配方、物品和行为。
4. 保存重进： 退出后重新进入，检查数据能否还原。
5. 兼容测试： 与明确支持的其他 MOD 组合测试。
6. 升级测试： 从上一发布版本升级，检查旧世界迁移。
7. 卸载测试： 按文档移除后，确认游戏是否仍能启动。

版本信息

发布包至少写明：

MOD 名称与版本：
作者与项目主页：
游戏版本：
API / 加载器版本：
目标平台：
安装方法：
卸载方法：
是否影响存档：
已知冲突：
更新日志：
许可协议：

“适配 2.x”通常不够精确。社区 API 可能在相同游戏大版本下更改接口或加载格式，应该同时写出 API 的具体分支或构建号。

封装前清理

• 删除调试日志、临时纹理、测试存档和编译缓存；
• 只保留运行必需的 DLL、数据和素材；
• 检查压缩包最外层路径，避免用户解压后多套一层目录；
• 用一份全新安装环境按照 README 从头安装；
• 计算并公布文件校验值，便于确认下载完整性。

发布规范

• 名称与功能描述必须真实，不用尚未实现的特性宣传。
• 测试版应明确风险和反馈渠道，不伪装成稳定版。
• 未获许可不打包他人的代码、素材或游戏本体。
• 基于他人项目修改时保留作者、来源和许可证信息。
• 会修改或删除存档数据的操作必须在安装说明前部醒目标出。
• 停止维护时说明最后支持版本，避免用户误判兼容性。

错误报告模板

游戏版本：
API / 加载器版本：
MOD 版本：
平台与系统：
是否为新世界：
同时启用的其他 MOD：
复现步骤：
预期结果：
实际结果：
错误日志：

不要只提交“闪退了”或一张截掉堆栈的截图。完整日志、复现步骤和最小 MOD 组合能显著缩短排查时间。

移植到其他 API

移植不是简单替换程序集引用。需要逐项核对目标框架、生命周期方法可见性、组件/子系统接口、数据库结构、内容加载方式和存档格式。先让最小入口在新 API 加载，再逐个恢复功能。

参考资料

• MOD 架构、工具与排错
• SCAPI 1.9 项目搭建
• 语雀资料迁移对照