本文为 2025.11.08 基岩社小课堂的内容，2026.02.05经过整理后的手稿。可供希望了解整合包的玩家、想要成为整合包创作者的新人、希望获取灵感的作者参考。欢迎斧正！

讲课人：@Polaris_Light​

认识整合包&整合包格式

整合包是将多个模组进行整合后打包发布的Minecraft，基于是否对模组原有的内容进行修改可分为原生整合包与魔改整合包。

• 原生整合包：不对游戏内容进行任何修改，仅整合模组并调整配置文件，通常为生电整合包或基础整合包。

• 魔改整合包：使用魔改模组或自制模组对游戏内容进行修改的整合包。通常所说的整合包都是指魔改整合包。

Minecraft EULA 明确禁止直接分发 Minecraft 本体，整合包只会包含模组、修改文件与必要的资源文件。由于大部分模组都可以通过Curseforge和Modrinth下载，因此在更多场景下整合包分发的是一张模组自动下载列表，而非模组本身。

在满足以上条件的前提下，整合包分为如下几种格式：

• Curseforge 格式/ MCBBS 格式

  • MCBBS 是 Curseforge 格式的超集，现在已经很少使用。

  • overrides/

  • manifest.json

    • 定义了模组加载器（Forge，Fabric，NeoForge…）、加载器版本和需要下载的模组。

    • 模组不分服务端客户端，只记录ProjectID与FileID。

    • 因此 Curseforge 格式需要发布客户端和服务端两个文件。服务端通常会直接包含所有模组。（当然也有一些奇淫巧技可以让服务端也通过Curseforge下载模组。）

• Modrinth 格式，文件后缀 .mrpack

  • overrides/

  • client-overrides/ 客户端专有的部分

  • server-overrides/ 服务端专有的部分

  • modrinth.index.json

    • 定义了模组加载器、加载器版本和自动下载的模组。

    • 相较于Curseforge格式，Modrinth格式的模组记录文件直链，区分服务端与客户端，还能自定义文件名与下载路径，意味着资源包光影也可以通过下载获取，甚至可以从其他地方进行下载。

    • 理论上 Modrinth 格式可以只分发一个文件，同时支持服务端与客户端。（服务端需要通过mrpack-install安装。）但是绝大多数作者并没有利用这个特性，会把所有模组都标成 BOTH。

• MultiMC 格式

  • 只有魔改了加载器的整合包，需要自定义启动参数时才需要使用。如 GTNH 和 M3E。

• 懒人包

  • 将所有模组直接分发而非将绝大部分模组放入下载列表。不推荐使用这种格式，会使得模组作者拿不到推广收益，有些模组作者对这点非常在意。

• 共有部分：overrides/

  • config：模组的配置文件，有些模组提供了配置项以修改游戏内容，因此需要放入整合包中。

  • mods：非自动下载的模组，一般是自己写的，或者是对家的。不同平台对这部分模组的处理也不尽相同，在下文会详细解释。

  • kubejs：KubeJS的魔改脚本与魔改数据包资源包。

  • script：CraftTweaker的魔改脚本。

  • defaultconfig：在Forge，有些模组的服务端配置会在存档生成的时候生成在存档内的 serverconfig 中；如果需要修改这些配置文件，需要加到 defaultconfig 文件夹内，使得生成存档时候自动覆盖。这个文件夹可以通过修改 fml.toml 改名。NeoForge没有这个文件夹。

  • resourcepacks：资源包

  • 由模组生成的杂七杂八的文件夹与文件。放入与否取决于文件的内容，如果不清楚就放入。

相较于服务端，整合包的格式简单许多。虽然不同格式对自动下载文件的定义不同，主体基本一致。

打包工具

当然模组自动下载列表不可能手动，需要使用工具生成。整合包打包工具的选择并不是很多，大致可以分为 GUI 和纯命令行。两种打包工具各有优缺点。

• GUI 工具对于新手比较友好，搜索模组指定模组版本更简单；但是无法进行自动化打包，也不支持服务端，使用 Git 进行版本管理也会使仓库体积过大。

• 纯命令行的工具可以进行自动化打包，可以直接导出服务端；但操作难度高，并且没有搜索功能，需要依赖 MCMOD / Curseforge / Modrinth。

下面是各个工具各自的特点：

• HMCL / PCLII / Prism 等启动器

  • 优点：GUI，可以同时搜索 Curseforge 与 Modrinth 的模组。

  • 缺点：自动下载列表依靠识别，有时候会识别错误。

• Curseforge 启动器 / Modrinth 启动器

  • 优点：有 GUI ，模组定位精准，可以直接看到模组的介绍。

  • 缺点：只能下载对应平台的模组。

• Pakku

  • 优点：命令行，支持自动化，可以直接导出服务端包。

  • 缺点：比较新，功能不太完善，有一些奇怪的 Bug。

• Packwiz

  • 优点：命令行，老牌管理工具，功能齐全，可以直接嵌入HMCL/Prism。

  • 缺点：同一模组的 Curseforge 和 Modrinth版本不能共存。Curseforge 格式不能直接导出服务端。

整合包类型

整合包创作的第一步是确定你想做的整合包的类型。

结合 Curseforge、Modrinth 和 MCMOD 的分类，可以将整合包大致分为如下几类：

• 探索/冒险/战斗：以探索世界、击败BOSS、研究装备武器饰品搭配为主的整合包，例如落幕曲。有些冒险整合包会带有剧情。

• 魔法：以各类魔法模组为核心的整合包，现在比较少见。

• 科技/专家：以搭建各类产线为主的整合包，例如黄铜协奏曲。其中内容量大、配方复杂、难度极高的整合包成为专家包，例如 GTNH、新星工程。

• 养老/种田：以大量农业模组与装饰类模组为主，带有一定科技冒险要素的整合包，通常难度较低，例如耕云钓月、香草纪元、重度机械症。

• 轻量/优化：面向原版，或者作为其他整合包的基础，一般都是原生整合，例如 XPlus、羽舲的基础优化。

• 水槽：以上的综合，模组多而杂，不突出重点，例如 ATM系列。水槽不是烂包的代名词，但是确实很多烂包都是水槽。

• 恐怖：以恐怖模组为核心的整合包，绝大部分质量不高。

更进一步的，可以以某个模组为核心，围绕其编排内容，脆骨症就是类似的思路。

模组选择

除去 Lib，模组大致可以分为如下几类：

• 冒险：添加挑战与战斗要素的模组，例如灾变。模拟经营类的模组也算在这里。

• 科技：与现实相近，包含大量机器的模组，例如格雷科技、机械动力。

• 魔法：包含魔法要素的模组。这个分类相当宽泛，里面的很多模组游玩体验类似于科技（神秘时代、植物魔法、星辉魔法）、冒险（诡厄巫法、帷幕彼端）、单纯装备（铁魔法、巫术学）。

• 农业：添加新的农作物与食物。过去农业模组大多作为水槽包中的附属，近些年来重要性明显提升，例如森罗厨房、农夫乐事。

• 装饰：添加新的建筑方块与装饰品的模组，例如群青。

• 实用：内容量较少的小物件，例如自然指南针，时间之瓶。这些模组虽小，但是很多时候会使游戏体验发生很大变化。这部分模组的选取比较考验整合包作者的积累。

• 辅助：不添加新内容、实现某种功能的模组，如 JEI。每个整合包都需要很多辅助类模组改善体验，同样考验作者的积累。

• 魔改：整合包内用于修改游戏内容的模组，如 KubeJS。

• 优化：对原版与其他模组进行性能优化的模组，如 Embeddium。

模组选择是整合包创作的关键，整合包的好坏 80% 在于模组的选择。模组选择应当契合主题，例如冒险包不应该选取过多的科技模组或将科技模组编入主线中。

个人选取模组有这么几个原则：

• 稳定性&兼容性：稳定性差或兼容性差的模组难以放在整合包内，例如各种 MCr 模组，应该避免放入这些模组。稳定性与兼容性可以通过MCMOD模组界面的下方评论来获取；如果对于模组开发有了解，也可以通过查看模组源代码（或反编译）来判断。一般来说结构混乱的模组稳定性难以保证，对原版类 Mixin 较多的模组兼容性差。

• 更新频率：更新非常慢的模组会在其他模组更新时候因为联动失效而绊脚，尤其当它是附属的时候，如机械动力的附属。这些模组需要谨慎考虑，当然也可以选择不更新模组。

• 热门模组&小众模组

  • 热门模组一般意味着代码指令高、内容丰富；但是这些模组在各种整合包中都有出现，玩家会对此感到厌烦。

  • 小众模组有时候只是宣发不够，例如很多国产模组；但是小众模组通常资料不足，需要自己游玩后通过任务书指引。当然有些模组小众是因为代码质量很差，如各种 MCr 模组，需要自己甄别。

  • 整合包需要做到热门模组与小众模组的平衡。在不需要的场合，可以大胆抛弃机械动力/农夫乐事/灾变等热门模组，使用小众模组替换。

• 优化模组的选取：

  • 可以去看 @北葵Starry​的优化小评，也可以直接在基础优化整合包的基础上增加新内容。

  • 优化并不是越多越好，大部分优化都用一部分硬件资源换了另一部分硬件资源。

  • 有些优化具有普适性，它们修正了 Mojang 的屎山代码：如 Embeddium

  • 有些优化是典型一换一：如铁氧体核心，降低了内存压力提升CPU与GPU的压力。

  • 有些优化没啥副作用但是适用面很窄：比如实体渲染优化，通常只在大量实体中有效。

  • 有些优化是假优化甚至负作用：比如著名掩耳盗铃模组 Ksyxis。

整合包魔改

百科对于原生整合的要求很严格。除非你是大佬，能做到仅依靠模组搭配就能构建充足内容，否则除了轻量/优化整合包都需要魔改来完善游戏体验。

魔改的目的如下：

• 平衡不同模组之间的数值差异；

• 解决“十七个番茄”之类的内容重复问题；

• 在模组之间进行兼容；

• 大幅度改变配方以调整模组之间的先后顺序，构建整合包的流程；

• 调整数值配方以切合整合包的剧情；

• 增加新的功能，埋彩蛋。

绝对禁止直接修改模组本体！在不得不修改模组源代码的情形下，应当在符合源代码开源协议或征得原作者同意后 Fork 模组。

汉化不属于魔改，请加到资源包内，或者在模组的 Github 提出 PR。

魔改大致有如下的方法：

• 配置文件

  • 有些模组会给出一些游戏内容的配置项，此时修改配置文件就是最方便的魔改方法，如生活调味料的配置项。

• 数据包/资源包

  • 优点：兼容性极强，可以修改所有数据驱动的内容，如配方、成就、世界生成、维度定义、战利品表等。

  • 缺点：由于数据包函数的性能问题，只能做简单的逻辑。低版本不能使用。

  • 用压缩软件打开模组，data/ 文件夹下就是该模组内置的数据包。

  • 按照模组同样的路径与文件名写配方，就能覆盖模组内的配方。

  • 特别的，写一个结构空位->结构空位的无序配方（或者其他无意义配方）可以去除配方。

  • 数据包与存档绑定，需要放在存档文件夹内。如果需要自动应用数据包，需要使用 OpenLoader 模组。KubeJS 也有类似的功能。

  • 资源包与数据包类似，但是是修改贴图。

• 魔改模组

  • KubeJS

    • 使用 JavaScript

    • 优点：可以通过检测 Event 做出逻辑，相较于直接开发模组上手难度低了许多。功能非常强大，附属模组也很多。

    • 缺点：并非无所不能，有些功能需要依靠附属模组。

  • CraftTweaker

    • 使用 ZenScript。

    • 在 1.7.10 和 1.12.2 曾广泛使用，现在也有少量整合包使用，但是附属少功能少，现在使用率很少。

  • FancyMenu

    • 修改主菜单，各类整合包内的奇怪按钮、音乐、背景图都是使用它来修改。FM 也有很多附属模组，提供新的功能。

    • 缺点：整合包体积过大的罪魁祸首，启动时会造成明显卡顿。因此个人不是很喜欢使用 FM。

  • FTBQuests

    • 目前唯一好使的任务模组，功能完善。但是在 Modrinth 平台分发的整合包没法使用 :(

    • 补充：任务检测多个物品是怎么做的？安装Item Fliter和FTB X MOD Compat。使用 Item Fliter 模组的 AND 过滤器和 Tag 过滤器。这是 Item Fliter 曾经是 FTBQuests 前置的原因。

    • 补充：如果需要加图片，可以通过资源包。按照命名空间搜索加入、有些整合包会放一个机器的图在任务里面，按照机器摆任务；或者直接将机器作为地图，任务按照机器摆。机器的图可以通过 Fabrishot 或 IsoRender 生成；但是这两个模组都是 Fabric 的，需要互联。

  • HQM/BQ/成就写任务/帕秋莉手册写任务：过于难使，现在很少有人使用。

  • 其他魔改模组

    • 百科可以搜到一些零散的魔改模组

    • OEI，OEF，OEB：解决“十七个番茄”的问题。因为 Forge 本身对 Tag 定义不清楚，有不同模组把作物加到不同 Tag 的问题： forge:barries/blueberry, forge:barries/blueberries, forge:blueberry, forge:blueberries。 以前要一个个把这些做完加到所有 Tag 中，再把一些硬编码的配方改成 Tag。现在方便许多。这个模组也可以用来 ban 物品，比 KubeJS 方便许多且没有卡 Bug 空间。

    • Attributizer：直接修改盔甲的属性，使用KubeJS 也可以做到。

    • 物品阶段：在冒险包很常用，在完成某些条件之前不能获取下一阶段的物品。

    • Bad Mobs：禁止生物生成。使用数据包也可以做到，但是技术要求比较高。

    • CEMD：改掉落，数据包也能做但是比较繁琐。

    • ……

• 自制模组

  • 优点：无所不能，可以做非常深入的模组兼容。

  • 缺点：学习成本非常高，有这个技术力的人通常会选择做模组开发者而非整合包作者。

更进一步&测试整合包

一般来说，完成模组的选取与魔改后整合包基本就算完成了。（当然这两步不会简单，还需要经玩家反馈后调整。）在这之后，你还可以做这样的操作：

• 做一条整合包的剧情线，不过这通常在整合包开发最开始就已经确定了；

• 统一游戏内各种 UI 的风格；

• 构建整合包的服务端，在服务端整活；

• 测试整合包需要的配置，想办法优化配置要求；

• 让整合包支持本地化；

• 开源整合包以供其他人参考；

• 如果使用命令行攻略，可以考虑写自动化测试；

• ……

此外我强烈建议在完成整合包后需要进行测试。最直接的方法就是以玩家的身份自己玩一遍，这样测试最充分，也能测试出游戏内容中的 Bug；不过通常耗时极长。如果时间有限，最少也需要在常用的启动器中安装后稍微玩一点，测试初期的游戏内容与整合包的稳定性。

如果有服务端，无论是使用ServerPackCreator生成的还是工具导出的，都需要本地开一次以测试是否能正常启动。

切忌让玩家来测试整合包，这是不负责任的表现。

整合包发布

整合包完成后，有以下几个平台可以发布。记得在 MCMOD 创建整合包标签页并填写发布的地址。

• Curseforge

  • 要求 Curseforge 格式，不能包含可执行文件，所有可以在 Curseforge 平台上下载的模组必须放入自动下载列表中，一些要求非常严格的模组不能放入整合包内。Curseforge 上没有的模组（如只有 Modrinth 上的）需要列在 Approved Non-CurseForge Mods 表格中（但是这个是谷歌表格）；如果一个模组的开源协议合适但是不在 Approved Non-CurseForge Mods 表格中，可以提交工单。

  • 整合包提交时 Curseforge 的工作人员会指出哪些部分存在问题，且审核周期非常快。如果没有什么大问题，通常会在一天内通过。（模组基本可以秒过。）

  • 补充：服务端通常是直接分发所有模组，但是有些模组要求不能直接分发本体，会被 Curseforge 拒绝。此时可以写一个脚本读取 manifest.json 自动下载模组，这在 Curseforge 是允许的。

• Modrinth

  • 要求 Modrinth 格式。由于版权限制，有些模组不能放入，比如所有 FTB 模组…… 此外对于非 Modrinth 的模组要求也比较严格，相对繁琐。

  • Modrinth 格式对服务端支持好，但是 Modrinth 客户端不分双端，需要手动修改自动下载列表。因此很多整合包也不区分……

  • 审核非常慢……整合包通常需要一周以上审核时间，这还不包括调整的时间。

  • 补充：PCL 导出 Modrinth 格式，但是只是借用格式，不符合 Modrinth 网站的要求。

• Github

  • 适合支持自动构建的整合包发布，但是国内访问有困难。

• 国内平台：Xyebbs，BBSMC，Minebbs 等

  • 对整合包格式与模组的要求非常宽松，非必要不审核。

  • 对国内整合包的支持好，在国外曝光会有明显劣势。

• 网盘：……懂的都懂。