第一次把模组塞进星露谷物语的人，十有八九会在同一个地方卡住：文件解压完、丢进文件夹、点开游戏，屏幕上什么都没有。问题往往不在模组本身，而在这款像素农场游戏原版根本没有"读取外部模组"的能力，你需要先给它装一个翻译官——SMAPI 模组加载器。它的全称是 Stardew Modding API，由社区长期维护，做的事情说白了就三件：在游戏加载前把外来的资源文件接住、在游戏运行中把事件和指令转译给模组、在出问题时把日志原原本本吐给你看。没有它，任何.xnb之外的模组内容都只是一堆躺在硬盘里的压缩包。
这篇内容面向三类人：完全没碰过模组、想从零把第一个模组装起来的新玩家；装过但老是报错、日志一看就头疼的中间玩家；以及想给朋友写一份"照着做就行"的操作说明的老玩家。我会把安装器每一步在做什么、为什么要这么选讲清楚，再把我这几年帮人排查时反复遇到的坑一条条列出来——尤其是那个让 90% 新手原地罚站的"文件夹多套了一层"问题。整篇默认你手上是正版游戏，装在正规购买渠道的平台里，这不是道德说教，是模组生态的基本前提：加载器要靠安装器自动定位游戏目录，盗版路径一旦对不上，后面的报错会变得极其难排查。
1. 先把"为什么要装加载器"这件事想明白
1.1 原版游戏为什么吃不下外部模组
星露谷物语的内容组织方式很朴素：地图、贴图、对话、物品数据全被打包成.xnb格式的归档文件，游戏启动时按索引一次性读进内存。这套结构对单机游戏来说效率很高，但它的缺点同样明显——文件是死的数据，没有"给你一个钩子，你在这上面挂东西"的设计。你直接把一张改过的图丢进去，游戏不认识它；你写一段逻辑想让角色多一个技能，游戏里根本没有地方去调用这段逻辑。
SMAPI 的位置就卡在这里。它在游戏进程启动的那一刻先把自己注入进去，接管资源加载路径，然后提供一个中间层：模组通过它注册"我要改哪个资源"，加载器在游戏真正读取之前把改动应用上去。所以你会看到装完 SMAPI 后游戏目录里多了一个StardewModdingAPI.exe，启动它才等于带着加载器启动。这个文件不是游戏的替代品，它只是一个"先开门再请人进屋"的前置程序。
顺带解释一个新手常有的误会：装了 SMAPI 并不等于装了模组。加载器本身不改动任何游戏内容，装完之后你的画面、剧情、数值和原版完全一致。它只是一个空壳运行环境，真正干活的是后面放进Mods文件夹里的那些东西。
1.2 加载器在后台替你做的三件事
第一件事是资源拦截。游戏要读取"春季作物贴图"这张资源时，SMAPI 会先问一圈：有没有模组要改这个资源？有就应用，没有就放行原版。这套机制决定了模组之间可以叠加修改同一张图，也决定了为什么"加载顺序"有时候会影响最终效果。
第二件事是事件转发。游戏里每天开始、每次进入建筑、每次对话、每次按键，SMAPI 都会把这些时刻抽象成事件抛给模组。模组作者不需要去逆向游戏代码，只要在事件上挂一个函数就行。这也是为什么模组生态能繁荣——门槛被拉低到了"会写基本逻辑"的程度。
第三件事是错误隔离与日志记录。原版游戏崩溃，你只能看到一个黑屏。有了加载器，某个模组在初始化时抛异常，SMAPI 会把它单独捕获、标记为加载失败、继续把其他模组跑完，最后在控制台和日志文件里写清楚是哪个模组的哪个文件出了问题。这个能力在排查阶段价值极高，后面第 5 章会专门讲怎么读它。
注意：加载器的"隔离"不是万能的。模组如果在运行中途修改了存档数据结构并且写盘，那部分损坏是不可逆的。所以第 2 章会先讲备份，别跳过。
1.3 什么样的玩家值得走这条路
我的判断标准很直白：如果你只打算玩一两周、通关一次就卸载，那原版体验已经足够完整，装模组的边际收益不高。但如果你属于下面几种情况，投入半小时把环境搭好是稳赚的。
- 已经玩过一个完整周目，想换个节奏，比如改掉每日时间流速、调整体力消耗曲线。
- 对界面信息密度不满意，想显示作物剩余天数、NPC 好感进度这类数据。
- 想和朋友联机但觉得原版协作体验太松散，需要一些便利性改动。
- 单纯对"这游戏能改成什么样"好奇，愿意折腾。
反过来说，如果你追求的是"零风险、零维护"，那模组不适合你。模组需要跟着游戏版本更新，游戏本体一次大版本升级，往往意味着一批模组失效、需要等作者适配。这是整个生态的常态，接受不了就别碰。
2. 动手前的三件事：版本、备份、环境
2.1 版本对齐是最大的隐形门槛
装模组翻车的原因里，版本错配占的比例比"模组有 bug"高得多。这里有两层对齐关系必须同时满足：加载器版本要匹配游戏版本，模组要求的最低加载器版本要低于你装的加载器版本。
第一层是硬性的。游戏本体每次大版本更新（比如从 1.5 到 1.6），底层接口会发生变动，旧版加载器直接无法工作。所以你要做的是：先确认自己游戏的版本号（主菜单右下角或者平台库里的版本信息），再去看加载器发布页上标注的兼容范围。不要图省事下最新版就完事——如果你的游戏版本偏旧，装最新加载器反而会起不来。
第二层是软性的但更常见。每个模组的manifest.json里都有一个字段写着它要求的最低加载器版本。你的加载器低于这个数，模组会被直接跳过，控制台里显示一行"需要更高版本的 SMAPI"。这种情况不是坏了，是根本没用上。
| 场景 | 表现 | 处理方向 |
|---|---|---|
| 加载器版本低于游戏版本 | 启动闪退或黑屏，日志开头就报错 | 换与游戏版本匹配的加载器 |
| 加载器版本高于游戏版本 | 启动报接口不匹配 | 降级加载器 |
| 模组要求的最低版本高于当前加载器 | 模组被跳过，控制台标黄 | 升级加载器 |
| 模组本身版本太老 | 加载成功但功能异常或报空引用 | 找作者的新版本或替代品 |
我的习惯是装之前先在自己文档里记一行：游戏版本号 + 加载器版本号 + 安装日期。听起来有点强迫症，但当你三个月后回来发现某个模组突然不工作时，这一行记录能省掉半小时的排查。
2.2 存档和游戏目录的备份姿势
这件事必须放在安装之前做，不是"建议"，是"必须"。加载器安装过程本身不会动存档，但装完之后你会开始往里丢模组，而模组对存档的影响是不可预知的。
存档位置在用户数据目录下，Windows 上大概是%appdata%\StardewValley\Saves，macOS 和 Linux 在各自对应的应用数据目录里。整个Saves文件夹直接复制一份，改个名字加上日期，放到桌面或者移动硬盘都行。这个操作三十秒，但它在你手滑装了一个会改存档结构的模组时能救命。
游戏本体目录也建议整个复制一份做冷备份。理由很实际：加载器安装器会往游戏目录里写文件、创建文件夹、可能修改平台的启动配置。虽然它自带卸载功能，而且卸载得挺干净，但万一你中途断电、或者装到一半手动关掉了窗口，目录可能处于半安装状态。有备份就能直接整个换回来，不用去猜哪个文件是残留。
注意：备份要覆盖"安装前"的状态。很多人是先装完发现不对，再去备份，那备份的已经是污染后的目录了，没有任何意义。
2.3 运行环境的检查与安装
加载器不是纯绿色程序，它依赖 .NET 运行时。较新的加载器版本通常要求 .NET 8 桌面运行时，稍旧的版本要求 .NET 5 或 6。你不需要提前去猜，因为安装器在检测不到运行时会直接告诉你缺哪个版本、给出对应页面。
我在这里的建议是：别自己先去网上下一个"最新版 .NET"装上。版本号差一位就可能不兼容，而且桌面运行时和普通运行时是两回事，装错了安装器还是认不出来。正确做法是先跑安装器，让它告诉你缺什么，再按它的提示装。
Windows 上装运行时的过程就是下载安装包、双击、一路下一步，装完可能需要重启一次。macOS 和 Linux 用户走的是另一条线，加载器会通过脚本调用系统的运行时，如果系统里没有对应版本，脚本会报错退出。这种情况下按脚本输出的提示装对应版本的运行时即可。
装完运行时可以做一次快速验证：新开一个终端窗口，输入dotnet --list-runtimes，如果输出列表里出现了对应版本号（比如 8.x.x 的 Desktop Runtime），说明环境到位了。这一步看着多余，但它能排除掉一大类"安装器一闪而过"的诡异问题——很多时候不是加载器的问题，是运行时根本没装上。
3. 完整安装流程实录
3.1 Windows 上的安装器操作
拿到加载器压缩包后，先把它解压到一个临时目录，不要在压缩包里直接双击运行——那样脚本会在临时路径下工作，找不到游戏目录。解压出来应该能看到几个文件，其中带install on Windows字样的批处理文件就是入口。
双击它，会弹出一个命令行窗口。窗口里会先做环境自检，然后列出一个数字菜单，大致是安装、卸载、退出三项。选安装那一项，回车。接下来安装器会自动去常见位置寻找游戏，包括各平台默认的安装路径。如果找到了，它会显示路径并让你确认；如果没找到，会让你手动指定游戏目录——这时候把游戏根目录（能看到游戏主程序的那个文件夹）路径粘进去就行。
确认之后，安装器开始往游戏目录写文件。你会看到它创建了Mods文件夹、smapi-internal文件夹，以及那个关键的StardewModdingAPI.exe。过程中它可能会问你是否要把启动方式改成通过加载器启动，这个选项建议选是，后面会解释为什么。
安装完成后先别急着开游戏，回到游戏目录检查一下：Mods文件夹存在且是空的，StardewModdingAPI.exe存在，smapi-internal文件夹里有一堆依赖库文件。三样齐全，基本可以判定安装成功。
实操心得：如果你的游戏装在非默认盘符或者自定义路径下，安装器的自动搜索可能失效。这时候手动指定路径是最稳的，别用移动文件夹的方式去"迁就"安装器，那会把平台识别的游戏路径也搞坏。
3.2 macOS 与 Linux 的终端操作
macOS 上，加载器提供的是一个.command后缀的脚本文件。首次双击可能被系统拦下，需要在终端里先给它加执行权限：chmod +x "install on macOS.command"，然后再双击运行。之后的流程和 Windows 类似，脚本会自检环境、定位游戏目录、写入文件。
Linux 上用的是.sh脚本，在终端里运行./install\ on\ Linux.sh或者直接bash install\ on\ Linux.sh。有一个细节要注意：如果你的游戏是通过平台安装在用户目录下，脚本一般能自动找到；但如果装在别处，脚本会提示你输入路径，这时候要输入绝对路径，相对路径它解析不了。
macOS 上还有一个常见坑：从较新的系统版本开始，脚本在终端里运行时会因为权限问题无法写入应用程序目录。表现是脚本跑到一半报"权限不足"。解决办法是用sudo运行，或者在系统设置里给终端授予完全磁盘访问权限。前者更快，后者更一劳永逸。
Linux 用户还要额外确认一件事：游戏的启动脚本有没有被正确替换。有些发行版下，平台启动游戏时会走一个包装脚本，加载器的安装器会尝试修改它，但如果你的环境比较特殊（比如用了沙盒化的包管理安装方式），修改可能不生效。判断方法是终端里直接运行游戏目录下的启动命令，看控制台有没有输出加载器的启动信息。
3.3 安装成功的四个验证信号
我不建议"装完就当成功"，用下面四个信号逐个确认，能省掉后面大量"到底是哪一步错了"的纠结。
信号一：控制台窗口出现。通过加载器启动游戏时，会额外弹出一个命令行窗口，里面滚动着加载器版本号、检测到的模组数量、加载耗时。这个窗口不会自动关闭，它是你和加载器交互的主要界面，后面排查问题也靠它。
信号二：标题界面版本提示。进入游戏后的主菜单，通常在角落会多出一行加载器版本信息。看到这行字，说明加载器已经注入了游戏进程，不是"装了个空壳"。
信号三：日志文件生成。游戏目录下会出现一个文本日志文件，名字里带SMAPI和latest。打开它，开头应该是加载器版本、游戏版本、运行环境版本这三行信息。如果这个文件存在但内容只有一行报错，那说明加载器起来了但没跑通，属于部分失败。
信号四：Mods文件夹被正确识别。控制台里会输出一行类似"找到 0 个模组"的信息。数量是 0 不要紧，关键是它认出了这个文件夹。如果它说"模组文件夹不存在"，那是路径问题，需要回退重装。
四个信号全部通过，环境就算搭好了。这时候可以正式开始装第一个模组。
4. 装第一个模组：从下载到跑起来
4.1 目录结构是新手翻车率最高的一关
我在帮人排查时统计过，报错原因里排第一的从来不是"版本不对"，而是文件夹多套了一层。这个坑极其隐蔽，因为从文件管理器里看，你确实把模组文件夹放进了Mods，逻辑上没毛病。
问题出在解压环节。大部分模组压缩包解开后，里面已经有一层同名文件夹了。如果你解压出来的是某个模组/某个模组/...，再把外层那个拖进Mods，最终结构就变成了Mods/某个模组/某个模组/manifest.json。加载器扫描Mods下的一级子目录，进到第一个某个模组里去找清单文件，找不到，直接跳过。
正确的结构只有一层：
Mods/ ├── 模组甲/ │ ├── manifest.json │ └── 其他文件... └── 模组乙/ ├── manifest.json └── 其他文件...判断标准很简单：打开Mods下的任意一个子文件夹，第一眼就该看到manifest.json。如果看到的还是另一个文件夹，那就把内层那个提上来，外层删掉。
注意：模组文件夹的名字本身不影响加载，加载器只认里面的清单文件。所以你可以把文件夹改成中文名方便识别，比如把一长串英文改成"界面信息增强"，不会出问题。但清单文件本身不能改名字，也不能改内容格式。
4.2 清单文件里该看什么
manifest.json是模组的身份证，加载器靠它判断"这是什么、谁做的、版本多少、依赖谁"。你不需要会写，但需要会看几个字段，因为它们直接决定模组能不能跑起来。
| 字段 | 作用 | 出问题时的表现 |
|---|---|---|
| 名称与作者 | 日志里的显示名 | 无关紧要，但方便对号入座 |
| 版本号 | 当前模组版本 | 冲突排查时的依据 |
| 唯一标识 | 全局唯一 ID | 两个模组 ID 相同会导致其中一个被跳过 |
| 最低加载器版本 | 版本门槛 | 低于此值模组被跳过，控制台标黄 |
| 依赖列表 | 需要哪些前置 | 前置缺失时模组加载失败或功能残缺 |
| 内容包指向 | 是否为内容类补丁 | 缺前置时整包失效 |
用记事本或者任意文本编辑器打开就能看，注意别手滑改了里面的标点——JSON 格式对逗号和引号极其敏感，少一个逗号整个文件就解析失败，加载器会直接报"清单文件格式错误"。
有一个特别容易忽略的点：唯一标识重复。当你从不同渠道下载了同一个模组的两个版本，或者一个整合包里带了重复项，加载器会检测到两个相同的 ID，然后只保留其中一个。表现是"我明明装了两个不同的模组，怎么只生效一个"。这时候去日志里搜"重复"相关的提示，把多余的那份删掉就行。
4.3 前置依赖的链条怎么理顺
模组生态里有一类东西叫"前置"，它自己不做具体功能，只是提供一套通用的能力，让别的模组在上面搭。最常见的是"内容补丁类"前置——它提供了一套声明式的资源修改机制，其他改贴图、改数据的模组都依赖它来生效。
这就形成了依赖链：你要装的模组依赖前置 A，前置 A 又可能依赖前置 B。缺任何一环，链条就断。加载器会在控制台里明确告诉你缺了谁，通常格式是"某个模组需要 X，但 X 未安装"。
我的处理顺序是：先看模组发布页上的依赖说明，把所有前置一次性下齐，再统一放进Mods。不要一个一个试，那样每次重启游戏都要等加载，效率太低。放进之后重启一次，看控制台有没有"缺失依赖"的提示，没有就说明链条通了。
有一种情况需要额外说明：有些模组的依赖是"可选"的。清单里会标注某个依赖不是必需的，装了会解锁额外功能，不装也能跑。这类依赖的缺失不会导致模组被跳过，但你在日志里可能看到一行提示。看到这种提示不用慌，属于正常状态。
4.4 启动验证与首次运行观察
所有东西放好之后，通过加载器启动游戏。注意是启动加载器那个可执行文件，不是原版游戏主程序——如果你之前选了把平台启动方式改成走加载器，那直接在平台里点开始就行。
控制台窗口会开始滚动。你要关注的是三段内容：开头是环境信息，中间是模组加载列表，结尾是加载结果统计。加载列表里每一项前面会有一个标记，正常的、被跳过的、加载失败的分得很清楚。
第一次装模组，建议只装一个，跑通再往上加。这个习惯能让你在出问题时立刻定位到"就是刚才加的那个"。反过来，一次性丢二十个进去然后发现报错，你只能二分法一个个排除，多花好几倍时间。
进入游戏后做一次实际验证：如果装的是界面类模组，看看界面上有没有多出东西；如果装的是内容类模组，去对应的场景看看资源有没有变化。有些模组需要在新的一天开始时才生效，有些需要重进存档，这些在模组说明里一般会写。验证通过，第一个模组就算装成了。
实操心得：养成"装完模组先看控制台再进游戏"的习惯。控制台里黄色的提示大多无害，红色的错误必须处理。很多人直接关掉控制台进游戏，玩了半小时发现某个功能没生效，回头再找原因，成本高得多。
5. 常见报错与排查实录
5.1 读懂控制台和日志
排查的第一步永远是拿到准确的错误信息，而加载器把这件事做得相当友好。控制台窗口是实时输出，但它会滚动，容易漏；日志文件是完整记录，适合逐行看。
日志的结构大致分四段：环境信息（版本、路径）、模组加载明细（每个模组的加载结果）、警告与错误汇总、退出信息。你要找的是第三段。里面通常会把"被跳过的模组"和"加载失败的模组"分开列，每一条都带着模组名和原因。
几个高频关键词值得记住：表示"跳过"的词通常伴随"需要更高版本"或"缺少依赖"；表示"失败"的词通常伴随异常堆栈；如果看到"重复"字样，那是 ID 冲突。异常堆栈看着吓人，但你只需要看第一行——它通常写着"空引用"或者"文件未找到"，后面的几十行是调用链，对新手意义不大。
还有一个容易被忽略的地方：用户数据目录下的崩溃日志文件夹。加载器本身跑通了，但游戏进程中途崩了，相关的记录会落到那里。它是控制台日志的补充，两边对照着看，基本能还原出完整的事故现场。
5.2 高频问题速查表
下面这张表是我这些年被问得最多的问题汇总，按出现频率排序。
| 现象 | 最可能的原因 | 处理方式 |
|---|---|---|
| 游戏启动后没有任何模组生效 | 启动的不是加载器，是原版程序 | 改为通过加载器启动 |
| 控制台显示找到 0 个模组 | Mods里的文件夹多套了一层 | 把内层提到一级，删掉外层 |
| 某个模组被跳过，提示版本不足 | 模组要求的最低加载器版本更高 | 升级加载器到对应版本 |
| 模组加载了但功能没变化 | 缺前置，或需要重进存档 | 补齐依赖，重启并重进存档 |
| 启动直接闪退，无控制台 | 运行时缺失或版本不匹配 | 按安装器提示装对应运行时 |
| 两个模组只有一个生效 | 唯一标识重复 | 删除重复版本中的一份 |
| 改动后画面错乱、贴图丢失 | 多个模组改了同一资源，顺序冲突 | 调整加载顺序或二选一 |
| 联机时客机看不到变化 | 主机装的内容类模组客机也需要 | 双方模组列表保持一致 |
表格里的每一条我都处理过至少一次。其中"多套一层"和"启动的不是加载器"这两条加起来能占到全部问题的六成以上，遇到"什么都没生效"这种描述，先查这两项，别急着怀疑模组本身。
5.3 几个我踩过的坑
第一个坑：在游戏运行时替换模组文件。加载器在启动时读一次模组列表，进了游戏之后再往Mods里丢东西，它不会重新扫描。有少数加载器版本支持在控制台里触发重载，但内容类模组的资源已经加载进内存，重载往往不彻底，表现是"界面改了但数据没改"。稳妥做法永远是：彻底退出游戏，改文件，再启动。
第二个坑：存档里的模组痕迹会残留。有些模组会往存档里写自定义数据，比如记录某个自定义物品的位置。你把模组卸载了再进这个存档，游戏读到不认识的数据，可能报错或者出现空物件。这种事不一定发生，但一旦发生就很难修。所以卸载内容类模组之前，先用那个存档做一次"清空回原版"的测试——把模组移走，进游戏保存一次，再退出。如果这一步就报错，说明存档已经被深度绑定，那就别卸了，换个新存档玩。
第三个坑：整合包未必比手动装省事。整合包的好处是一次装一堆，坏处是里面某一个模组出问题时，你很难判断是哪个。而且整合包的更新节奏往往落后于单个模组，游戏本体一升级，整合包不能用了，你手动装的那些反而能单独更新。我的建议是：新手阶段用少量手动装的模组建立认知，熟悉之后再考虑是否用整合包。
第四个坑：以为"警告"可以无视。控制台里的黄色提示大部分确实无害，比如"某个模组针对旧版本编译"这种。但有一类警告需要留意：内容补丁类模组在应用修改时如果目标资源不存在，会输出警告并跳过。单次跳过不影响游戏，但如果一次启动里有几十条这种警告，说明你的模组和当前游戏版本已经脱节了，只是还没到崩溃的程度。
6. 模组多了之后：管理与维护
6.1 分组启用与存档隔离
当你手上的模组超过二十个，管理本身就会变成负担。我的做法是按用途分组，在Mods外面建几个平行文件夹，比如"界面增强""便利性调整""内容扩展""暂时停用"，Mods里只放当前要用的。想换玩法就把文件夹整体挪进挪出，比一个个找快得多。
这个做法有个前提：加载器只扫描Mods这一层，你在外面建多少文件夹它都不管。所以挪动是安全的，不会破坏什么配置。
更进一步的隔离是存档与模组配置绑定。有些模拟经营类玩家会同时维护两三个不同风格的存档，对应不同的模组组合。这种情况下建议给每个组合单独记一份清单，写清楚这个存档用了哪些模组、版本号是多少。听起来繁琐，但当你三个月后想回到某个存档继续玩，模组已经更新了好几轮，没有清单你根本还原不出当时的状态。
6.2 更新模组不炸存档的做法
更新分两种情况，处理方式完全不同。
加载器本身的更新相对安全。做法是重新跑一次安装器，它检测到已有安装会走升级流程，覆盖程序文件但保留Mods文件夹。升级完启动一次，看控制台有没有新的报错。如果升级后反而一堆模组失效了，那说明这次升级跨了大版本，需要等模组作者适配，这时候可以考虑回退到旧版加载器——但要注意，旧版加载器可能不兼容新版游戏，得两头对齐。
模组的更新风险更高，尤其是内容类模组。作者在新版本里改了数据结构，你的存档里还是旧结构，更新后进游戏可能直接报错。所以我的流程是：更新前先把存档复制一份，更新后进游戏跑一天，保存，退出，再进一次确认没问题。两次都能正常进，才算更新成功。
有一个反直觉的经验：不要盲目追新。一个模组稳定运行、你也没遇到问题，那就没必要更新。更新的收益是修 bug 和加功能，成本是引入新的不确定性。在模组生态里，"能用就别动"是一条被反复验证过的原则。
6.3 性能观察与瘦身
模组装多了，启动变慢是必然的。加载器在启动时会输出每个阶段的耗时，控制台里能看到总加载时间。正常情况下十几秒到一分钟都算合理，具体取决于模组数量和硬盘速度。
真正影响游戏内流畅度的是那些"每帧都在跑逻辑"的模组，比如实时计算路径、实时重绘界面的。判断方法是：进游戏后观察帧率，然后把可疑模组停用再对比。加载器控制台里提供了一些诊断命令，输入帮助命令能看到可用命令列表，其中有查看性能统计和补丁统计的，对定位"谁在拖后腿"很有用。
瘦身的原则是按需启用。很多玩家装了几十个模组，实际常用的就那几个。每隔一段时间清理一次：把一个月没触发过的模组移出Mods，观察一周，确认没影响再彻底删掉。这个过程有点像整理衣柜，你会发现真正需要的远比想象中少。
实操心得：我给自己定了一条线——
Mods里常驻不超过二十个。超过就强制清理。这条线不是为了性能，是为了可维护性：模组越多，出问题时定位成本呈指数上升，而且每次游戏更新后的适配工作量也会压垮你。
7. 写在最后的几句实在话
这套东西我从最开始的手忙脚乱到现在的流程化操作，中间踩的坑基本都写在上面的章节里了。如果只让我留一句话给准备入坑的人，那就是：先把环境验通，再一个模组一个模组地加。九成的挫败感来自于"一口气装二十个然后全崩"，而不是模组本身有多难。
另外提一个我最近才养成的小习惯：每次大改动之前，在文档里写三行——改了什么、为什么改、出问题怎么退回。三行字，一两分钟，但它把"折腾"变成了一件可逆的事。可逆的实验才叫实验，不可逆的那叫赌博。
真遇到卡住的地方，先去翻日志文件，别急着在群里发"我的模组不生效怎么办"。日志里九成情况下已经写清楚了原因，只是你没往那个方向看。把日志里那几行红字贴出来，别人帮你判断的速度会快十倍——这对你自己、对帮你的人，都是更省时间的方式。
