1. 开服之前：先想清楚你要的到底是什么

1.1 整合包开服和原版开服完全是两码事

很多人第一次接触开服，脑子里想的是“下载一个服务端核心，双击启动，完事”。原版确实可以这么干，但整合包不行。整合包的本质是什么？它是一堆模组、配置文件、脚本、资源包、自定义合成表、自定义维度、自定义生物群系的集合体。你客户端能跑起来，不代表服务端能跑起来，因为客户端和服务端加载的内容根本不一样。

我见过太多人拿着客户端整合包直接丢进服务端文件夹，然后启动脚本一跑，满屏红字报错，接着在群里问“为什么进不去”。原因很简单：客户端整合包里有大量仅客户端模组，比如光影加载器、界面优化、按键冲突修复、小地图、物品管理器等等。这些模组在服务端加载时要么直接崩溃，要么因为找不到客户端渲染类而抛出异常。服务端需要的是服务端侧模组加上必要的双端模组，而不是把客户端那一整套原封不动搬过去。

所以第一步，你得先搞清楚你手上这个整合包的结构。打开整合包的mods文件夹，看看里面有多少个.jar文件。通常一个中型整合包有150到250个模组，大型整合包能到400个以上。你需要做的是分类：哪些是纯客户端模组，哪些是纯服务端模组，哪些是双端模组。这个分类工作没有捷径，只能一个一个查。我的经验是，打开模组的mods.toml或者fabric.mod.json文件，看它的side字段或者environment字段。如果写着client，那就是纯客户端；写着server，那就是纯服务端；写着both或者*，那就是双端。没有明确标注的，去模组的官方页面看说明，或者直接看模组名称里有没有client、gui、hud、shader、minimap、jei、rei这类关键词。

1.2 服务端核心的选择逻辑

选服务端核心这件事，直接决定了你后续的维护成本和玩家体验。目前主流的服务端核心分几个大类：原版核心、插件核心、模组核心、混合核心。整合包开服，你基本只能在模组核心和混合核心里选。

模组核心最典型的就是Forge和Fabric。Forge的历史更久，模组生态更成熟，大型整合包大多基于Forge。Fabric启动更快，更新更及时，轻量级整合包和新兴模组更倾向于Fabric。NeoForge是Forge的一个分支，近两年势头很猛，很多新版本模组开始只支持NeoForge。Quilt是Fabric的分支，但生态规模还差得远。

混合核心就是既能加载模组又能加载插件的那种，比如Mohist、Magma、Arclight。这类核心的好处是你可以同时用模组和插件，比如用插件来做经济系统、领地保护、权限管理，用模组来提供游戏内容。但坏处也很明显：兼容性问题多，更新滞后，遇到模组冲突时排查难度翻倍。我的建议是，如果你不是特别需要某个插件功能，优先用纯模组核心。稳定压倒一切。

选核心的时候还要注意版本匹配。整合包是基于哪个游戏版本做的，你就得用对应版本的核心。1.12.2、1.16.5、1.18.2、1.20.1这几个版本是目前整合包最集中的版本。1.12.2虽然老，但模组数量庞大，很多经典整合包都在这个版本。1.20.1是当前的新宠，模组更新活跃。你拿到整合包的第一件事，就是确认它的游戏版本和模组加载器类型，然后去下载对应的服务端核心。

1.3 硬件资源的真实需求

开服这件事，硬件是绕不过去的坎。我见过太多人用一台老笔记本或者低配云主机就想开整合包服，结果TPS掉到个位数，玩家走两步退一步。整合包服务端对硬件的要求比原版高出一个数量级，因为模组会大量增加方块类型、实体类型、合成表、维度、生物AI计算量。

内存方面，原版服务端2GB能跑，整合包服务端起步就得4GB，中型整合包建议6到8GB，大型整合包16GB都不嫌多。但内存不是越大越好，Java的垃圾回收机制决定了你给太多内存反而会导致GC停顿时间变长。我的经验是，4GB到8GB是一个比较合理的区间，具体看整合包规模和玩家数量。CPU方面，单核性能比多核重要，因为Minecraft服务端的主逻辑线程是单线程的。你搞个32核的服务器，主频只有2.0GHz，那还不如一个4核4.5GHz的机器。硬盘一定要用SSD，机械硬盘加载区块的速度会让你怀疑人生。网络带宽方面，每个玩家大约需要100Kbps到200Kbps的上传带宽，10个玩家就是1到2Mbps，再加上模组同步的数据量，建议至少10Mbps上行。

2. 从零开始：整合包服务端的搭建流程

2.1 获取服务端文件与目录规划

搭建整合包服务端的第一步，是拿到正确的服务端文件。很多整合包的作者会直接提供服务端包，通常在整合包的发布页面会有“Server”或者“服务端”的下载选项。如果有官方服务端包，优先用官方的，因为作者已经帮你把纯客户端模组剔除了，配置文件也调整好了。如果没有官方服务端包，你就得自己从客户端整合包里提取。

自己提取的流程是这样的：先创建一个干净的服务端目录，然后把客户端整合包里的mods文件夹复制过来，接着逐个检查模组，把纯客户端模组删掉。同时还要复制config文件夹、scripts文件夹（如果有）、defaultconfigs文件夹（如果有）、kubejs文件夹（如果有）。resourcepacks和shaderpacks不需要复制，那是纯客户端的。saves文件夹也不要复制，那是单人存档。

目录结构规划也很重要。我习惯把服务端放在一个独立的目录里，比如/home/mcserver/，下面再分server、backups、logs、tools几个子目录。server放服务端本体，backups放备份，logs放日志归档，tools放一些辅助脚本。这样结构清晰，出了问题也好排查。

2.2 启动脚本的参数配置

启动脚本是服务端的命门，参数配不好，轻则性能差，重则频繁崩溃。Forge和Fabric的启动方式略有不同，但核心参数是相通的。下面是一个我常用的启动脚本模板，你可以根据自己的情况调整：

#!/bin/bash java -Xms6G -Xmx6G \ -XX:+UseG1GC \ -XX:+ParallelRefProcEnabled \ -XX:MaxGCPauseMillis=200 \ -XX:+UnlockExperimentalVMOptions \ -XX:+DisableExplicitGC \ -XX:+AlwaysPreTouch \ -XX:G1NewSizePercent=30 \ -XX:G1MaxNewSizePercent=40 \ -XX:G1HeapRegionSize=8M \ -XX:G1ReservePercent=20 \ -XX:G1HeapWastePercent=5 \ -XX:G1MixedGCCountTarget=4 \ -XX:InitiatingHeapOccupancyPercent=15 \ -XX:G1MixedGCLiveThresholdPercent=90 \ -XX:G1RSetUpdatingPauseTimePercent=5 \ -XX:SurvivorRatio=32 \ -XX:+PerfDisableSharedMem \ -XX:MaxTenuringThreshold=1 \ -Dusing.aikars.flags=https://mcflags.emc.gs \ -Daikars.new.flags=true \ -jar server.jar nogui

这套参数的核心逻辑是：固定内存分配，避免动态调整带来的性能波动；使用G1垃圾回收器，并针对Minecraft的工作负载做了调优；禁用显式GC调用，防止模组代码触发不必要的垃圾回收；启用AlwaysPreTouch，让JVM在启动时就分配好所有内存页，减少运行时的内存分配开销。-XX:MaxTenuringThreshold=1这个参数让对象更快进入老年代，减少新生代GC频率，对模组服这种大量长期存活对象的场景很有效。

注意：-Xms和-Xmx建议设置成相同的值，避免JVM在运行过程中动态调整堆大小。如果你给8GB内存，那就两个都写8G。不要写-Xms4G -Xmx8G，那样会导致堆扩展时产生额外开销。

2.3 核心配置文件的手动调整

服务端启动一次之后，会在根目录生成server.properties文件。这个文件里的每一项都影响服务端的运行行为，我挑几个整合包开服必须关注的讲。

level-type这一项，原版默认是default，但很多整合包会要求改成biomesoplenty或者terraforged之类的模组维度生成器。如果你不改，地图生成会出错，轻则地形异常，重则直接崩溃。generator-settings这一项，如果整合包有自定义地形生成配置，需要把对应的JSON字符串填进去。max-tick-time建议改成-1，因为模组加载和世界生成经常超过原版的60秒限制，不改的话服务端会在启动时自动关闭。sync-chunk-writes建议改成false，可以提升区块保存性能，代价是极端情况下可能丢失少量区块数据，但整合包服一般都有定期备份，问题不大。network-compression-threshold建议改成256，模组服的数据包比原版大很多，压缩阈值调低可以节省带宽。view-distance和simulation-distance这两个是性能杀手，整合包服建议view-distance设6到8，simulation-distance设4到6，再高的话TPS扛不住。

3. 模组筛选与兼容性处理

3.1 纯客户端模组的识别与剔除

前面提到了纯客户端模组的识别方法，这里展开讲一下具体的操作。打开mods文件夹，按文件名排序，然后逐个看。以下这些类型的模组，基本可以确定是纯客户端的，直接删掉：光影加载器（比如Iris、OptiFine、Rubidium、Embeddium的客户端部分）、小地图（JourneyMap、Xaero‘s Minimap）、物品管理器（JEI、REI、EMI）、界面优化（AppleSkin、BetterF3、Detail Armor Bar）、按键管理（Controlling、Mouse Tweaks）、音效优化（Sound Physics Remastered、Presence Footsteps）、粒子优化（Particle Tweaks）、动态光源（Dynamic Lights）、第一人称模型（First Person Model）、聊天优化（Chat Heads）、缩放（Zoomify）。这些模组在服务端加载时，要么因为找不到客户端渲染类而崩溃，要么虽然能加载但完全不起作用，白白占用内存。

但要注意，有些模组名字看起来像客户端模组，实际上是双端的。比如JEI在服务端加载时不会崩溃，但它也不会提供任何功能，删掉更干净。AppleSkin是纯客户端的，删。Controlling是纯客户端的，删。Mouse Tweaks是纯客户端的，删。JourneyMap有服务端组件，但服务端组件只用于多人同步玩家位置，如果你不需要这个功能，也可以删。我的原则是：不确定的模组，先留着，启动一次看日志，如果报错再删。但纯客户端模组能删就删，减少内存占用和潜在冲突。

3.2 服务端侧模组的补充与替换

有些模组在客户端和服务端的行为不一样，或者服务端需要额外的模组来支持多人游戏。比如FTB Chunks在服务端需要配合FTB Teams和FTB Library才能正常工作。JourneyMap的服务端组件需要单独下载。Spark是一个性能分析模组，服务端装上可以方便地排查TPS问题。LagGoggles可以检测哪些方块或实体导致卡顿。ClearLag可以定期清理掉落物，但整合包里如果有自己的清理机制，就不需要额外加。

还有一些模组是专门为服务端设计的，比如AI Improvements可以优化生物AI性能，FastFurnace和FastWorkbench可以加速熔炉和工作台的合成逻辑，Clumps可以把经验球合并在一起减少实体数量。这些模组在客户端装不装都行，但服务端装上能明显提升性能。不过要注意，有些模组会改变游戏机制，比如FastFurnace改变了熔炉的燃烧速度，如果整合包有自定义的熔炉配方，可能会冲突。加之前先看模组说明，确认兼容性。

3.3 配置文件同步与差异处理

整合包的配置文件分两种：一种是客户端和服务端都需要一致的，比如模组的功能开关、合成表、维度配置；另一种是只需要客户端或者只需要服务端特定的。最稳妥的做法是，把客户端整合包的config文件夹整个复制到服务端，然后根据服务端的需要进行调整。

常见的需要调整的配置项包括：forge-client.toml和forge-server.toml（Forge的客户端和服务端配置是分开的）、fabric-loader相关的配置、模组自己的-client.toml和-server.toml文件。有些模组会把配置分成common、client、server三个文件，你只需要关注common和server，client的可以不管。如果整合包用了defaultconfigs文件夹，那个文件夹里的配置会在世界创建时复制到世界的serverconfig文件夹里，也需要同步。

提示：如果你不确定某个配置文件是否需要同步，最简单的办法是先把客户端的config整个复制过去，启动服务端，看日志里有没有配置相关的警告或错误。如果有，再针对性调整。不要一开始就手动精简，那样容易漏掉关键配置。

4. 启动、调试与性能调优

4.1 首次启动的日志解读

第一次启动整合包服务端，大概率不会一帆风顺。你需要学会看日志。日志文件在logs/latest.log，启动过程中的所有信息都在里面。重点关注这几类信息：ERROR级别的报错，通常是模组加载失败或者配置错误；WARN级别的警告，可能是模组版本不匹配或者功能冲突；Missing or unsupported开头的行，说明某个模组依赖缺失；Duplicate mod开头的行，说明有重复模组；Mod X requires Y开头的行，说明依赖关系没满足。

如果服务端在启动过程中直接崩溃，日志的最后几行会告诉你崩溃原因。常见的崩溃原因包括：内存不足（OutOfMemoryError）、模组冲突（NoSuchMethodError、ClassNotFoundException）、配置文件格式错误（JsonParseException）、世界生成失败（Exception generating new chunk）。根据报错信息去搜索，通常能找到解决方案。如果日志里没有明显报错，但服务端就是起不来，试试删掉config文件夹重新生成，或者用二分法排查模组：先禁用一半模组，看能不能启动，能就说明问题在另一半里，然后继续二分，直到定位到具体模组。

4.2 TPS与内存监控

服务端跑起来之后，你需要持续监控它的健康状态。TPS（每秒游戏刻）是最核心的指标，正常应该是20，低于15就会明显卡顿，低于10基本没法玩。查看TPS的方法：在游戏里输入/forge tps或者/neoforge tps，或者装个Spark模组用/spark tps。内存使用情况可以通过/spark health或者JVM的监控工具查看。如果发现内存持续增长不释放，可能是某个模组有内存泄漏，需要用Spark的堆转储功能分析。

TPS低的常见原因：实体过多（尤其是掉落物、经验球、村民）、区块加载过多（view-distance设太大）、红石电路高频运行、模组本身的性能问题。排查方法：用Spark的/spark profiler命令采样一段时间，然后看报告里哪个方法占用CPU时间最多。如果是某个模组的方法，考虑更新模组版本或者找替代方案。如果是原版机制的问题，比如村民AI，可以用AI Improvements之类的模组优化。

4.3 常见崩溃与排查速查表

5. 长期维护与玩家管理

5.1 备份策略与恢复流程

整合包服务端的备份比原版重要十倍，因为模组服的数据结构更复杂，一旦损坏恢复难度极大。我的备份策略是：每天自动备份一次完整的世界文件夹，保留最近7天的备份；每周手动备份一次完整服务端目录（包括模组和配置），保留最近4周的备份。备份文件要存到不同的物理硬盘或者远程存储上，不要和服务端放在同一块盘里。

自动备份可以用cron定时任务配合tar命令实现。比如每天凌晨4点执行：

#!/bin/bash BACKUP_DIR="/home/mcserver/backups" WORLD_DIR="/home/mcserver/server/world" DATE=$(date +%Y%m%d_%H%M%S) tar -czf "$BACKUP_DIR/world_$DATE.tar.gz" "$WORLD_DIR" find "$BACKUP_DIR" -name "world_*.tar.gz" -mtime +7 -delete

恢复的时候，先停服，然后把备份文件解压到对应位置，覆盖原来的世界文件夹，再启动。如果只是某个玩家数据损坏，可以只恢复world/playerdata里对应的.dat文件。如果模组配置损坏，恢复config文件夹。

5.2 玩家权限与行为管理

整合包服通常是小圈子朋友一起玩，但基本的权限管理还是要做。原版有ops.json可以给管理员权限，但更细粒度的权限控制需要插件或者模组。如果你用的是混合核心，可以装LuckPerms来做权限组管理。如果是纯模组核心，可以用FTB Ranks或者Forge Essentials。权限管理的核心原则是：最小权限原则，普通玩家只给必要的命令权限，管理命令只给信任的人。

行为管理方面，整合包服最常见的问题是玩家用模组功能破坏平衡，比如用AE2的自动化系统刷物品，用Thermal Expansion的机器无限产能，用Draconic Evolution的混沌守卫拆家。这些问题的根源在于模组本身的机制，你很难通过权限来限制。我的做法是：开服前就和玩家约定好规则，哪些模组功能可以用，哪些不能用；定期检查玩家的基地，看有没有明显异常的自动化装置；如果发现滥用，先警告，再犯就收回相关模组的权限或者直接封禁。

5.3 模组更新与版本迁移

整合包开服一段时间后，作者可能会发布更新，修复bug或者增加新内容。更新服务端的时候，不能直接把新客户端的mods文件夹覆盖过去，因为服务端的模组列表和客户端不一样。正确的流程是：先看更新日志，确认哪些模组有变化；然后下载新的服务端包（如果有），或者手动替换变化的模组；接着对比新旧配置文件，把新增的配置项合并进去；最后在测试环境启动一次，确认没问题再更新正式服。

版本迁移是更复杂的情况，比如从1.16.5升级到1.18.2，或者从Forge换到NeoForge。这种迁移基本等于重新开服，因为模组生态、世界格式、配置文件全变了。我的建议是：如果整合包没有官方迁移方案，不要自己尝试迁移，直接开新档。如果一定要迁移，先备份所有数据，然后在测试环境走一遍完整流程，确认世界能加载、玩家数据能转换、模组功能正常，再考虑正式迁移。

6. 我踩过的那些坑

6.1 内存分配的那些误区

我最开始开服的时候，觉得内存越大越好，直接给服务端分了16GB。结果TPS反而比8GB的时候还低。后来查资料才明白，JVM的垃圾回收在堆内存过大时，单次GC的停顿时间会显著增加。Minecraft服务端的主线程在GC停顿时是完全冻结的，玩家感受到的就是卡顿。所以内存分配要适度，不是越大越好。另外，-Xms和-Xmx一定要设成一样，否则堆扩展时会有额外开销。

还有一个坑是用了不合适的垃圾回收器。默认的Parallel GC在模组服上表现很差，因为模组服的对象存活时间分布很广，Parallel GC的新生代回收策略不适合这种场景。换成G1 GC之后，TPS稳定性明显提升。如果你用的是Java 17以上，还可以试试ZGC，但ZGC对内存要求更高，小内存机器不建议用。

6.2 模组冲突的排查思路

模组冲突是整合包开服最头疼的问题。两个模组单独跑都没问题，一起跑就崩溃。排查这种问题，二分法是最高效的。具体操作：把mods文件夹分成两半，先放一半模组启动，如果崩溃，说明冲突在这一半里；如果不崩溃，说明冲突在另一半里。然后对有问题的那一半继续二分，直到定位到具体的两个模组。这个过程可能很耗时，但比盲目猜测靠谱得多。

定位到冲突模组之后，解决方案有几种：更新其中一个模组到兼容版本、找替代模组、用Mixins或者配置文件禁用冲突功能、如果冲突不严重可以忽略。有些冲突是已知的，比如OptiFine和Rubidium不兼容，JEI和REI不兼容，这些在模组说明里通常会写。开服前花点时间读模组说明，能省掉很多排查时间。

6.3 世界生成的隐藏陷阱

整合包的世界生成和原版差别很大，很多整合包会替换默认的地形生成器，加入自定义生物群系、维度、结构。如果你在server.properties里没有正确配置level-type和generator-settings，世界生成会出错。我遇到过一次，服务端启动正常，但玩家进入世界后周围全是虚空，走了几百格才看到一块陆地。查了半天才发现是level-type没改成整合包要求的类型。

另一个坑是预生成世界。整合包的地形生成计算量很大，玩家探索新区域时服务端会卡顿。解决办法是用Chunky或者Chunky Border预生成世界。预生成的时候要注意，半径不要设太大，否则会占用大量硬盘空间和生成时间。一般来说，预生成半径500到1000格就够用了，再远的地方让玩家自己探索。预生成过程中服务端TPS会很低，建议在没人玩的时候进行。

6.4 玩家数据丢失的预防

玩家数据丢失是开服最严重的事故之一。常见原因包括：服务端崩溃时正在保存数据、硬盘故障、误删文件、模组bug导致数据损坏。预防措施：定期备份是最基本的，但备份频率要够高，至少每天一次。另外，服务端崩溃后不要急着重启，先检查world/playerdata里的文件是否完整，如果有.dat.tmp文件，说明保存过程中断了，需要手动恢复。还可以装FTB Backups或者Simple Backups之类的模组，它们会在服务端运行时自动备份，比手动备份更可靠。

如果玩家数据真的丢了，先别慌。检查备份里有没有最近的玩家数据，有就直接恢复。如果没有备份，看看world/playerdata里有没有.dat_old文件，那是上一次保存的备份。如果连这个都没有，那就只能让玩家重新开始了。所以，备份这件事，怎么强调都不为过。我现在的习惯是，每次更新模组或者调整配置之前，先手动备份一次，确认没问题再操作。这个习惯帮我避免了好几次灾难。