杀戮尖塔Mod开发入门：JDK8+Maven+ModTheSpire环境配置全攻略

简介：面向《杀戮尖塔》模组开发初学者的入门指南，旨在帮助没有Java与Mod经验的玩家从零搭建MOD开发环境，并完成第一个可运行的MOD项目。教程围绕modthespire、stslib和basemod三大支持库展开，清楚解释它们如何在游戏本体与自定义代码之间建立接口，同时覆盖IntelliJ IDEA安装、Maven环境变量配置、pom.xml编辑与依赖声明等关键环节。资源以1个PDF文档封装，大小约1.5MB，结构紧凑，包含游戏本体安装、创意工坊支持库订阅、开发环境搭建、构建步骤以及Java语法基础等章节，并配有控制台输出、变量、函数、类作用域、监听函数与继承等示例讲解。通过Maven构建时如何指定Steam游戏库路径、如何引用BaseMod依赖等细节也有直观展示，适合希望快速入门的玩家边看边练。目前已有2121人学习下载，能够帮助读者从环境准备到代码实现逐步建立起对MOD结构的基本认知，适合作为杀戮尖塔Mod开发的第一份学习资料。

1. 做杀戮尖塔Mod前，先把三件事想清楚

杀戮尖塔的Mod开发，说到底是给一个Java 8时代的老游戏写外挂代码，这句话决定了后面所有的版本选择。很多第一次上手的人栽在同一个地方：按最新教程装了最新JDK和最新Maven，结果ModTheSpire加载器根本不认，或者构建出的jar包进游戏就闪退。花了一晚上，最后发现是版本和路径的问题。这篇教程把游戏本体、三大支持库、IDE、Maven这一整条链路的安装和配置走一遍，所有参数都给你拆开讲，照着做就能把第一个能加载的jar跑出来。适合以前没配过Java环境、对创意工坊目录结构不熟、或者卡在pom.xml上不知道怎么改的人。装好这套环境，你才能开始谈写卡牌、写事件、改机制。

2. 装依赖：游戏本体、ModTheSpire、BaseMod与stslib的下载与订阅

2.1 游戏本体：买了不一定能马上开发

游戏本体是全部工作的基础，但“装了游戏”和“能开发Mod”是两回事。很多教程把这一步标个“略”，实际上这里有个前置条件：至少用普通模式启动过一次游戏，让Steam把游戏文件完整解压落盘。新下载的游戏有时候文件还没就绪，直接开Mod加载器会报文件缺失。

开发时我们需要的是游戏根目录下的这个文件：

SteamLibrary/steamapps/common/SlayTheSpire/desktop-1.0.jar

这是游戏的主程序jar，也就是Mod要注入的目标本体。后面的pom.xml会直接用系统路径引用它，所以在开工之前，先找到你的SteamLibrary在哪。Steam默认装的路径通常是C:\Program Files (x86)\Steam\steamapps，但很多人的游戏库在别的盘，这个路径记下来，后面配置里要反复用。

如果游戏刚装好，我的建议是先普通模式启动一次，看看能不能正常进游戏。能进，再关掉，继续配环境。别一上来就想着上Mod，先确认本体是好的，否则后面所有报错你都没法判断是游戏问题还是Mod问题。

2.2 创意工坊订阅三大库：每个库的职责先分清

杀戮尖塔的Mod生态依赖三个Steam创意工坊模组：ModTheSpire、BaseMod、stslib。这三者分工不同，订阅之前先把职责理清楚，后面排查问题会省很多时间：

• ModTheSpire：Mod加载器。没有它，游戏启动时不会扫描和加载任何Mod jar。它负责识别ModTheSpire.json、执行@SpireInitializer注解、打印加载日志。也就是说，你的Mod写了代码，靠的是它来拉起。
• BaseMod：Mod API支持库。提供大量与游戏交互的接口，比如监听抽牌事件、受伤事件、战斗结束事件，以及注册卡牌、角色、药水的API。写Mod基本离不开它。
• stslib：扩展库。提供了不少现成的卡牌动作、UI组件和机制模板，不是每个Mod都必须用，但推荐先订阅上，一方面测试别人的Mod经常需要它，另一方面以后你用到特定功能时不用再回头补。

订阅方式很简单：在Steam客户端里打开《杀戮尖塔》的商店页面，进入创意工坊，分别搜索这三个名字，点订阅。等Steam自动下载完成即可。

需要特别提醒一点：订阅只是加入下载队列，不等于已经下载完成。Steam创意工坊的模组是异步下载的，你得切到Steam的“下载”页面确认这三个都到了100%，再去下一步。很多人卡在“我订阅了为什么游戏里看不到”这个问题上，原因往往就是下载根本没完成。

2.3 确认三个jar的落盘位置

创意工坊订阅的模组下载完成后，会落在SteamLibrary的workshop目录里，路径规律是：

SteamLibrary/steamapps/workshop/content/646570/<模组ID>/<模组文件>.jar

这里的646570是杀戮尖塔在Steam创意工坊的内容ID。三个依赖库中，BaseMod和ModTheSpire的jar路径在后续pom.xml里会直接用到，必须提前确认。下面是我这边的路径示例：

注意1605833019和1605060445这两个数字，是BaseMod和ModTheSpire在创意工坊里的固定ID，后面配置依赖时要用。stslib的ID不用强行记，到时候在workshop目录里翻一下就能找到，但你要记住它存在。

打开资源管理器，把上面的路径逐个走一遍，确认这些jar文件都真实存在。这一步偷懒不得——pom.xml里的systemPath写的是绝对路径，路径错一个字符，构建就会报“系统找不到指定的路径”，而且报错信息往往要到很后面才暴露，排查起来相当难受。

如果你用的是Mac或Linux，路径结构类似，只是前缀从E:\SteamLibrary变成/home/你的用户名/.steam/steam/steamapps之类的挂载位置，原理完全一样，照着后面的逻辑替换即可。

3. 搭开发环境：JDK 8、IDEA社区版与Maven的Windows配置

3.1 为什么选JDK 8而不是最新版

杀戮尖塔本体是Java 8时代的工程，Mod最终要注入到这个老工程里运行。官方推荐和大多数Mod作者使用的都是JDK 8，你去看pom.xml里的编译配置，写的是source 1.8和target 1.8，意思就是编译出Java 8版本的class文件。

有人会问：我用JDK 17编译时把target设成1.8行不行？行是行，但没必要给自己找麻烦。高版本JDK在编译老项目时经常报一些莫名其妙的警告和错误，比如Invalid source release或者对某些废弃API的报错，调试起来纯属浪费时间。配环境的原则是匹配目标运行时，不是追求工具最新版。

下载JDK时选8系列的最新更新版本即可，装完后在命令行验证：

java -version

期望输出：

java version "1.8.0_202"

如果输出版本号还是1.8开头，说明装对了。如果你机器上已经装了更高版本的JDK，也不用卸载，后面在IDEA里新建项目时单独给这个项目指定JDK 8的路径就行，互不干扰。我已经不止一次看到有人因为不想动原有环境，用高版本JDK硬编，结果在target 1.8和依赖包之间反复报错，最后还是乖乖装了8。装一次，一劳永逸。

3.2 IDEA社区版：免费够用

Java开发的IDE基本就是在Eclipse和IntelliJ IDEA之间选，两个都有免费版本。这篇教程以IDEA为例，因为它的Maven支持和代码提示对新手更友好，而且社区版已经覆盖了开发Mod需要的全部功能。

到IDEA官网下载Community版本，也就是社区版。安装过程中按默认选项走即可，建议勾选“创建桌面快捷方式”和“添加到PATH”，后面在命令行里执行maven命令会更方便。安装完成后先不要急着建项目，下一步先把Maven配好，因为IDEA新建Maven项目时要调用本机的Maven配置。

3.3 Maven：下载、解压、配MAVEN_HOME

Maven是一个构建工具，负责拉依赖、编译、打包、输出jar。杀戮尖塔Mod项目里，pom.xml描述了项目结构，Maven按这个文件去执行构建。Windows下的配置步骤如下：

下载Maven的二进制压缩包，版本选3.3.9，与这篇教程配套的pom.xml版本一致。解压到一个路径中不含中文、不含空格的目录，比如E:\Maven\apache-maven-3.3.9。含中文或空格的路径在后续构建时可能引发奇怪的报错，直接避掉比事后排查划算。

然后是设置环境变量：

1. 右键“此电脑”，选择“属性”，进入“高级系统设置”，点击“环境变量”。
2. 在系统变量区域点击“新建”，变量名填MAVEN_HOME，变量值填Maven解压后的完整路径，也就是E:\Maven\apache-maven-3.3.9。
3. 找到系统变量里的Path，双击编辑，点击“新建”，填入%MAVEN_HOME%\bin。
4. 点击确定保存所有对话框，然后新开一个命令行窗口。

这里有个高频翻车点：很多人改完环境变量后，在一个旧的命令行窗口里执行命令，发现mvn不存在，就怀疑配置错了。环境变量在旧窗口里不会刷新，必须全部关掉重开才生效。新开窗口这一步不是仪式感，是实打实的坑。

3.4 组合验证：java与mvn一起跑

打开新命令行窗口，依次执行：

java -version mvn -version

mvn -version的输出应该包含类似这样的信息：

Apache Maven 3.3.9 Java version: 1.8.0_202

只要这两条都能正常输出，开发环境就通了。记住这个组合命令，以后排查环境问题第一条就是它。Java和Maven任何一个输出异常，你的Mod项目整个就没法构建，所以先把这两行跑顺再往下走。

4. 建项目：pom.xml依赖注入与ModTheSpire.json注册

4.1 在IDEA里新建Maven项目

打开IDEA，创建新项目，选择Maven类型。这里有一步容易困惑：IDEA会问你要不要选archetype模板，这里是不要勾选任何archetype的，直接按最简单的骨架创建。

填写项目信息：GroupId填org.example，ArtifactId填tutorial，项目名取tutorial。ArtifactId会作为工程标识的一部分，后面生成的jar包默认也叫这个名字，建议取一个不带空格、全小写的名字，避免后续路径和文件名出问题。

创建完成后，IDEA右下角通常会弹出一个提示，说检测到Maven配置发生变化，这时点击“Import Changes”或“Enable Auto-Import”。如果你没看到提示，等Maven自动导入完成也可以。这时候项目目录结构大致是这样的：

tutorial/ ├── .idea/ # IDE辅助文件，不用管 ├── src/ │ ├── main/ │ │ ├── java/ # 存放Java代码 │ │ └── resources/ # 存放json、图片等素材 │ └── test/ # Maven自动生成的测试目录 └── pom.xml # Maven构建配置

.idea文件夹是IDEA自己的，与Mod无关。src/main/java是你写代码的地方，src/main/resources放ModTheSpire.json这类资源文件。Maven会自动处理test目录相关的细节，暂时不用管。

4.2 pom.xml逐块拆解：路径、依赖、构建

pom.xml是这个项目的命根子，它负责告诉Maven三件事：依赖哪些jar、编译成什么版本、构建完把jar复制到哪里。下面这个是我配好的完整配置，注意steam.path用的是正斜杠：

<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>tutorial</artifactId> <version>0.1</version> <packaging>jar</packaging> <name>tutorialMod</name> <description>tutorial</description> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <steam.path>E:/SteamLibrary/steamapps</steam.path> </properties> <dependencies> <dependency> <groupId>bin</groupId> <artifactId>BaseMod</artifactId> <scope>system</scope> <version>1.0</version> <systemPath>${steam.path}/workshop/content/646570/1605833019/BaseMod.jar</systemPath> </dependency> <dependency> <groupId>bin</groupId> <artifactId>SlayTheSpire</artifactId> <scope>system</scope> <version>1.0</version> <systemPath>${steam.path}/common/SlayTheSpire/desktop-1.0.jar</systemPath> </dependency> <dependency> <groupId>bin</groupId> <artifactId>ModTheSpire</artifactId> <scope>system</scope> <version>1.0</version> <systemPath>${steam.path}/workshop/content/646570/1605060445/ModTheSpire.jar</systemPath> </dependency> </dependencies> <build> <finalName>tutorialMod</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.0</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.8</version> <executions> <execution> <phase>package</phase> <goals> <goal>run</goal> </goals> <configuration> <target> <copy file="target/tutorialMod.jar" tofile="${steam.path}/common/SlayTheSpire/mods/tutorialMod.jar"/> </target> </configuration> </execution> </executions> </plugin> </plugins> </build> </project>

逐块说明一下关键参数。

properties里的steam.path是整个配置文件的基础路径，后面所有系统依赖都用${steam.path}拼接。这个值要填你的Steam库根目录，路径分隔符建议用正斜杠。Windows下很多人习惯写E:\SteamLibrary\steamapps，但在XML里反斜杠是转义符，与后面的字符组合后可能被解析成别的东西。写成E:/SteamLibrary/steamapps是更稳妥的写法，能少踩一个坑。

dependencies里三个依赖是Mod开发的基石：BaseMod.jar提供API接口，desktop-1.0.jar是游戏本体，ModTheSpire.jar是加载器。注意这里没有引入stslib，因为它不是每个Mod都直接用到。等你后续代码里真的要调用stslib里的类时，再把它的jar路径以同样方式追加一条依赖即可。三个依赖的scope都标为system，意思是Maven不走中央仓库拉取，直接读你本机的文件。version填1.0只是占位符，system范围下的依赖版本号不会被实际校验。

build里的finalName决定了输出jar的名字，这里填tutorialMod。maven-compiler-plugin配置了source和target都是1.8，即编译产物的Java版本。maven-antrun-plugin则是把package阶段输出的jar文件复制到游戏的mods目录，这样构建完直接启动游戏就能在加载器里看到。这里的tofile路径后半段common/SlayTheSpire/mods需要你在游戏根目录下手动创建一个mods文件夹，否则antrun复制时会报目标路径不存在。

所有依赖的路径，都要和你在2.3节里实际确认过的位置一一对应。尤其是workshop/content/646570/后面的数字ID，不能凭记忆写，去资源管理器里亲眼确认过再填进配置。

4.3 ModTheSpire.json：让加载器认识你的Mod

打开src/main/resources目录，在里面新建一个文件，命名为ModTheSpire.json。这个文件的作用是告诉ModTheSpire加载器：我这个Mod叫什么、是谁写的、依赖谁、版本是多少。内容如下：

{ "modid": "tutorial", "name": "tutorialMod", "author_list": ["A", "B"], "description": "新手教程mod", "version": "0.0.1", "sts_version": "03-29-2018", "mts_version": "2.6.0", "dependencies": ["basemod"] }

各字段的含义：

modid是这个Mod的唯一标识，加载器靠它区分不同的Mod，所以全小写且不要有空格。它最好和你在4.1节里填的ArtifactId保持一致，后面写代码时包名也会用到它，三者对齐能省很多不必要的加载报错。name是显示在ModTheSpire加载列表里的名字，可以随意。author_list是一个数组，可以写多个作者，用方括号和逗号分隔。description是一段文本描述，会显示在游戏的Mod菜单里。version和mts_version代表你的Mod版本号和ModTheSpire的版本号。dependencies数组里写basemod，表示你的Mod在加载时要先加载BaseMod，这在游戏里会表现成加载顺序的依赖关系。

sts_version对应的是游戏版本，这里填的是教程所用的示例版本。你实际填的时候可以打开ModTheSpire的加载日志，里面会显示它识别到的游戏版本信息，以日志为准。

JSON格式的注意点集中在括号配对：花括号{}表示对象，方括号[]表示数组，逗号分隔同级元素。写错了IDE会直接标红，但如果IDE没标红也不代表没问题——这个文件里如果有多个对象，漏一个逗号这种错误IDE经常能发现。

4.4 执行package构建并确认产物

所有配置写完，开始构建测试。在IDEA右侧找到Maven面板，展开Lifecycle，双击package。这个操作会按顺序走完validate、compile、test、package整个生命周期，最终在target目录下生成jar文件。也可以直接在IDEA的Terminal里执行：

mvn package

两种方式等价，区别仅是前者用的是IDEA内置的Maven配置，后者用的是你命令行里配置的独立Maven。我一般直接用mvn package，这样环境变量对不对一目了然，不会被IDEA内置配置掩盖问题。

构建成功后，检查两个地方：

1. target/tutorialMod.jar是否生成——这是Maven的输出产物。
2. 游戏根目录的mods文件夹里是否出现同名jar——这是antrun插件复制过去的结果。

只要这两个文件都存在，配置就通了。然后启动游戏，注意要用withmod模式的启动方式进入。在ModTheSpire的加载界面里勾选BaseMod、ModTheSpire和你刚输出的tutorialMod，点运行。进入游戏后打开Mod菜单，应该能看到你在ModTheSpire.json里写的名称和描述信息。

此时这个Mod还没有任何功能，只是个空壳，但它已经证明整条链路是通的。接下来全部的工作，就是往这个壳里写逻辑。

5. 避坑排查：环境配置与构建环节的常见问题

5.1 构建显示BUILD SUCCESS，但游戏里看不到我的Mod

现象：mvn package跑完，日志输出BUILD SUCCESS，IDEA的target目录里jar也存在，但启动游戏后，ModTheSpire界面里根本没有这个Mod的选项。

原因：最典型的两个。一是jar没有被复制到ModTheSpire实际扫描的目录里。你要确认加载器到底扫的是哪个目录——大多数情况下是游戏根目录下的mods文件夹，但如果你把jar直接扔到结合了创意工坊的目录里，扫描范围可能会被加载器配置影响。二是ModTheSpire.json没被正确打进jar包内部，或者json格式有误，加载器解析失败后直接跳过。

解决：先解开jar看内部结构。把jar用压缩软件打开，确认ModTheSpire.json在jar包的根目录下，而不是躺在某个子文件夹里。然后检查游戏mods目录下的jar文件是否真的存在且大小与target下的产物一致。最后在游戏里点运行时注意看加载日志，它会打印每个Mod的加载状态，被跳过的项目会显示具体原因，这是最直接的判据。日志里记载的信息远比IDE里那行BUILD SUCCESS真实。

5.2 路径里用反斜杠，Maven报“系统找不到指定的路径”

现象：pom.xml里steam.path写的是E:\SteamLibrary\steamapps，构建时提示找不到路径，但是资源管理器里路径明明存在。

原因：XML规范里反斜杠是转义字符，后面跟着的字符会被组合解析。\S、\s这类组合在XML解析时行为不稳定，路径就这样被悄悄改写了。这个问题在Windows用户里极其常见。

解决：把steam.path里的反斜杠全部改成正斜杠，E:/SteamLibrary/steamapps。Maven在Windows下完全支持正斜杠路径。如果你特别想用反斜杠，那就写成E:\\SteamLibrary\\steamapps，双反斜杠是XML里的正确转义方式，但可读性差得多。从这以后，我凡是写XML里的路径一律正斜杠，不是玄学，是避免解释器做多余事。

5.3 命令行执行mvn提示“不是内部或外部命令”

现象：新开一个CMD窗口，执行mvn -version，系统提示mvn不是内部或外部命令，也不是可运行的程序。

原因：Maven的bin目录没有正确加入Path环境变量。这一步常见的错误有：MAVEN_HOME变量名拼错、Path里写成了%MAVEN_HOME%\bin;多余的分号、或者是修改环境变量后没有新开终端窗口直接就在旧窗口里跑了。

解决：重新打开环境变量编辑界面，确认MAVEN_HOME指向Maven解压目录本身，不是bin目录；确认Path里的条目是%MAVEN_HOME%\bin；然后彻底关掉所有命令行窗口，重新打开一个再试。这个问题的排查顺序，永远是先看变量值，再看窗口是否新开。我见过最离谱的情况是用户把MAVEN_HOME直接设成了E:\Maven\apache-maven-3.3.9\bin，然后又在Path里加了一次bin，双重叠加，后果就是mvn执行时报找不到某个文件，排查起来绕了很大一圈。

5.4 修改pom.xml后IDEA报依赖错误，右侧Maven面板一片红

现象：复制教程的pom.xml后，IDEA的Maven面板刷新时显示一堆依赖错误日志，右键项目跑package直接报错。

原因：多数情况下是依赖路径里的jar文件不存在。system scope的依赖不会自动从远程下载，路径只要有一点偏差，IDE就会显示红色报错。另外有可能是复制XML时漏了标签，比如<properties>里少写了一个闭合标签，整个pom结构就崩了。

解决：先看IDEA的Event Log或Maven面板的输出，它会具体报告哪个依赖的哪条路径失效。回去逐一核对2.3节里那张表格，尤其是workshop目录下的两个数字ID，最常错的就是这里。XML结构问题则借助格式化工具，或者直接在IDEA里打开pom.xml，IDE的XML解析器会告诉你第几行有语法错误。改完之后点Maven面板顶部的刷新按钮重新导入，而不是直接跑构建。

5.5 加载Mod后日志显示类找不到或版本不匹配

现象：ModTheSpire加载时，日志打印ClassNotFoundException，或者提示某个类的方法签名对不上。

原因：最可能的是ModTheSpire和BaseMod的版本与你当前游戏版本不匹配。游戏更新后，创意工坊里的BaseMod和ModTheSpire如果没有同步更新，Mod运行时会引用到过期的API。另一种可能是你的jar包里混入了编译期打包进去的旧依赖类，干扰了类加载。

解决：把创意工坊里的三个库重新订阅并强制更新到最新版，同时确认你的sts_version和mts_version与日志中显示的实际版本一致。这个不用修改代码就能解决，纯粹是环境匹配问题。

6. 验证跑通：从加载日志到第一个监听函数

构建成功只是一个开始，真正证明Mod活着，要看游戏里跑起来之后的行为。我每次装完环境，都会先做一次空壳验证，再写一段代码做交互验证。

先写第一个能产生输出的小类，在src/main/java下建一个包，名字取小写的modid，然后在包里新建一个类文件，比如Tutorial.java：

package tutorial; import com.evacipated.cardcrawl.modthespire.lib.SpireInitializer; @SpireInitializer public class Tutorial { public Tutorial() { } public static void initialize() { new Tutorial(); System.out.print("hello world! 5*6+30="); System.out.print(5 * 6 + 30); System.out.print("end of line!\n2+2=" + 4); } }

这段代码里，@SpireInitializer注解告诉ModTheSpire，这个类的initialize()方法是整个Mod的入口。initialize()里new Tutorial()是调构造函数创建对象，然后连续三行输出打印字符串和表达式计算结果。这段代码加载成功后，ModTheSpire的日志框里能看到hello world! 5*6+30=60这样的输出，开头还会带一个类似2ms的时间标记，表示加载这个类花了多长时间。看到这个log，环境才叫真正的通。

在IDEA里执行mvn package，把新jar构建并复制到游戏mods目录，然后以withmod模式启动游戏。这次留意ModTheSpire的日志面板或游戏的log输出窗口。如果控制台出现了这些输出，无脑下一步即可。

光有输出还不够，我要再验证一步：Mod是否真的在和游戏里的对象互动。把类改成这样：

package tutorial; import basemod.BaseMod; import basemod.interfaces.PostDrawSubscriber; import com.evacipated.cardcrawl.modthespire.lib.SpireInitializer; import com.megacrit.cardcrawl.cards.AbstractCard; @SpireInitializer public class Tutorial implements PostDrawSubscriber { public Tutorial() { BaseMod.subscribe(this); } public static void initialize() { new Tutorial(); } @Override public void receivePostDraw(AbstractCard abstractCard) { System.out.println(abstractCard.name); } }

PostDrawSubscriber是BaseMod提供的一个接口，Mod实现了它并在构造函数里BaseMod.subscribe(this)完成订阅，之后每次玩家抽牌，游戏都会调用receivePostDraw方法，参数就是被抽到的那张牌的对象。abstractCard.name是这张卡的名字，输出到log里。如果你进了游戏抽一张牌，日志里就出现这张牌的名字，说明你的Mod已经能接收游戏事件、读取游戏对象，整个开发链路彻底打通了。

从这以后，每次新配环境，我强制自己走一遍固定验证流程：先跑java -version和mvn -version确认基础环境，再构建空壳Mod确认加载，最后用监听函数确认事件互动，三关全部过了才放心开始写正式代码。这套流程救过我很多次——有次我把ModTheSpire.json里的modid改了一个字母，构建日志一点错没有，但游戏里出现了两个Mod条目，旧的那个怎么都加载不出代码，排查到最后才发现是modid、包名、类名三者没对齐。从那以后，每次构建前我都会把modid、包名、类名这三样东西对照着读一遍，再走一遍上面的验证清单。希望帮到你。

本文还有配套的精品资源，点击获取