之前帮朋友在云服务器上折腾过一个MC整合包服，前前后后崩了十几次，不是在凌晨三点崩，就是在人最多的时候崩，把我折腾得够呛。后来我把搭建流程、参数调优、防崩自启整套方案重新梳理了一遍，实测跑了几周没再出问题。这篇东西就是把那段时间踩过的坑和最终的稳定方案写出来，给想搭MC服务器但又不想整天盯着控制台的朋友一个参考。
先说清楚这篇博文覆盖什么：从零开始搭一个原版或模组服，把服务端调稳，最后做一层崩溃自动重启的保命机制。适合刚接触MC服务端的小白，也适合搭过服但总被崩服问题折磨的老手。我的方案以Linux系统为主，Windows的玩法会在对应章节提一嘴，核心思路是一样的。
1. 搭建前的需求拆解：服务器到底是给谁玩的
动手之前先想明白一个问题：这服务器是几个人玩，玩什么内容，打算跑多久。这三个问题的答案，直接决定你后面选配置、选服务端、调参数的方向，步骤错了没关系可以改，方向错了就是整台重来。
1.1 人数规模与硬件配置怎么匹配
MC服务器的负载核心在内存和CPU单核性能上，这不是随便选个高配机器就能解决的活。官方服务端（Vanilla）本身是单线程设计，就算你买32核的CPU，主线程该卡的还是卡，因为这个游戏的主循环只跑在一个核上。所以选硬件时，我向来是优先看单核频率，其次才是核心数。
- 2-5人小型好友服：2核4G内存起步，视距控制在6-8，跑原版或轻量模组没什么压力。如果是Windows系统，建议4G内存往上，因为系统本身就要吃掉1.5G左右。
- 5-15人中型社区服：建议4核8G内存，Linux系统，可以跑中型整合包或者带少量插件的生存服。这个规模是模组服最尴尬的区间，内存给少了必卡，CPU单核频率低了必卡。
- 15人以上：直接上4核16G甚至更高，视距按服务器预算来，所有优化手段全部拉满。
内存计算公式可以按“基础4G + 在线人数 × 0.5G”来估，模组服在这个基础上再加2-4G。我搭的那个10人左右的整合包服，开了8G内存，高峰期占用接近6G，留了2G余量给系统缓冲，这样才不会频繁触发GC卡顿。
1.2 服务端选型：别一上来就下官方客户端
很多人第一次搭服，顺手就在MC官网下了个客户端，然后问怎么开服，这是最大的误区。客户端和服务端是两套东西，服务端需要专门的服务器文件。
常见的服务端选择，按场景来分：
| 服务端类型 | 适用场景 | 说明 |
|---|---|---|
| Vanilla官方端 | 纯原版体验 | 原汁原味，但没有任何优化，人多必卡 |
| Paper | 插件服首选 | 性能优化极好，API兼容主流插件 |
| Spigot/Bukkit | 插件服 | Paper的前身，优化不如Paper，新开服不建议 |
| Forge/Fabric | 模组服 | 模组加载器，整合包通常绑定特定版本 |
| Arclight/CatServer | 模组+插件混合 | 想同时跑模组和插件时的折中选择 |
我的建议是：不玩模组就无脑选Paper，玩模组就老老实实跟着整合包要求的加载器走。Paper对原版服务端的优化幅度大到什么程度？同一个世界，Paper能比Vanilla多带一倍人还不怎么掉TPS，背后是区块加载、实体运算、红石处理等一系列底层逻辑的重写。我实测过同一个机器上原版和Paper的TPS对比，原版在8人左右开始掉到十几，Paper到20人还能稳定在20左右。
2. 环境准备与基础搭建：一步一步把服务端跑起来
这部分我把从零到能进服的完整流程走一遍，以Linux服务器为例，Windows的命令行工具不同，但下载文件、改配置文件的核心逻辑完全一样。
2.1 服务器系统与Java环境配置
系统我推荐Debian系（Ubuntu或Debian本身），原因是包管理方便，教程多，遇到问题搜得到。CentOS已经停止维护，新服务器建议别用了，而且很多新版Java在CentOS 7上装起来麻烦得很。
Java版本是MC服务端最容易踩的坑。不同MC版本对应不同Java版本：
- MC 1.16及以下：Java 8
- MC 1.17-1.20.4：Java 17（1.17需要Java 16，但用17也能跑）
- MC 1.20.5及以上：Java 21
- 高版本模组包：大概率是Java 17或21，具体看整合包文档
检查Java版本用java -version，如果没有或者版本不对，装对应版本。以Ubuntu装Java 17为例：
sudo apt update sudo apt install openjdk-17-jdk装完验证一下java -version输出的是17.x版本再继续。有个很多人忽略的细节：如果你服务器本身跑着其他Java程序，改系统默认Java版本可能影响那些程序，建议用update-alternatives --config java来切换默认版本，而不是直接删掉旧版本。
2.2 服务端文件下载与目录规划
新建一个专门跑MC的目录，别把文件丢在root家目录里。我的习惯是：
mkdir -p /srv/mc-server cd /srv/mc-server下载服务端文件有两个途径：Paper官网的API下载，或者对于整合包就用启动器配套的Server文件。Paper下载最新版的方式是用API：
curl -o paper.jar https://api.papermc.io/v2/projects/paper/versions/1.20.4/builds/latest/downloads/paper-1.20.4-latest.jar如果对这个自动查找build编号的API不熟，更稳的方式是直接去Paper官网页面，手动点最新版本的下载链接。下载完确认一下文件大小，低于1MB的八成是下载了错误页面。
第一次启动服务端前，需要先同意EULA协议。这个协议的签署方式是：
echo "eula=true" > eula.txt有些教程让你跳过这步，但实际不签协议服务端直接退出，没有捷径。
2.3 首次启动与核心配置文件解析
启动服务端，命令是：
java -Xms4G -Xmx4G -jar paper.jar nogui第一次启动会生成一堆文件：server.properties、bukkit.yml、spigot.yml、paper-global.yml等。生成完这些文件后，服务器会启动然后自动关闭，这是正常的首次初始化行为，别慌。
server.properties是核心配置文件，我用一个简单的sed脚本做初始调整：
sed -i 's/motd=A Minecraft Server/motd=我的好友生存服/' server.properties sed -i 's/difficulty=peaceful/difficulty=normal/' server.properties sed -i 's/view-distance=10/view-distance=8/' server.properties sed -i 's/online-mode=true/online-mode=false/' server.propertiesonline-mode是我特别注意的一个参数：如果是正版服，保持true，玩家用正版账号进服；如果是离线服（俗称盗版服），改成false。但注意，如果你后面打算装登录插件，离线服必须配登录插件，否则什么人都能顶着别人的ID进服把建筑拆了，这锅服务器背不起。正版服就没有这个风险，但代价是玩家必须买正版账号。
2.4 内存参数与启动脚本封装
启动命令里-Xms和-Xmx分别代表JVM初始内存和最大内存。很多教程直接让两个都填服务器总内存，这是错误的。JVM的堆内存设置过大，会导致GC停顿时间变长，反而卡。经验法则：给MC的堆内存上限设为物理内存的50%-70%，留出至少2G给操作系统和文件缓存。
比如8G内存的机器，我一般用：
java -Xms6G -Xmx6G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar paper.jar noguiUseG1GC是G1垃圾回收器，从Java 9开始是默认GC，但对MC来说显式声明并调优停顿时间参数是值得的。MaxGCPauseMillis控制GC最大停顿目标，设200毫秒比较合理。模组服可以换成-XX:+UseZGC（Java 17+），ZGC对超大堆内存的停顿控制更好，但也更吃CPU。
把启动命令封装成可复用脚本，我的start.sh长这样：
#!/bin/bash cd /srv/mc-server exec java -Xms6G -Xmx6G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar paper.jar nogui记得chmod +x start.sh给执行权限。用exec前缀有个作用：让Java进程接管当前shell进程ID，后面做自动重启（看门狗脚本依赖这个PID）会简单很多。
3. 稳定运行的调优细节：这些问题不处理，迟早崩服
服务端能跑起来只是第一步，真正让你少熬夜的是接下来这些调优细节。我在下面几个小节里讲的，都是那些跑了一周、一个月才慢慢暴露出来的问题。
3.1 TPS、内存泄漏与GC参数
TPS（Ticks Per Second）是MC服务器健康度的核心指标，满值是20，代表每秒执行20个游戏刻（每刻50ms）。低于20说明服务器运算跟不上，玩家体感就是“卡顿”“怪物不打你”“方块半天不破”。输入/tps可以查看当前值。
有个很容易被忽略的问题：TPS掉到15左右时，不是靠堆硬件能解决的，而是要找卡顿源头。Paper提供了很好的排查工具：
/paper spark health或者安装专门的性能分析插件，查看哪些区块、实体在消耗CPU。常见的卡顿源包括：大量铁傀儡塔（铁傀儡的AI计算开销很高）、堆积的掉落物、密集的红石机器。解决办法要么是限制实体数量（spigot.yml里的max-entity-collisions、entity-activation-range参数），要么是让玩家分区建造机器。
GC参数调优是另一个大坑。默认G1GC在MC里表现不错，但需要关注GC日志，判断是不是频繁Full GC。开启GC日志的方式是加JVM参数：
-Xlog:gc*:/var/log/mc-gc.log:time,uptime,level日志文件会越来越大，记得配logrotate轮转。观察一段时间，如果Full GC频繁且每次停顿超过几百毫秒，说明堆内存偏小或存在大对象分配过多，这时候加内存或者排查插件内存泄漏才有意义。我见过一个服，插件每次保存数据都加载全量数据到内存，导致Full GC一秒一次，换了个新版插件才解决。
3.2 定期备份与自动清理机制
崩溃重启能解决“服挂了起不来”的问题，但解决不了“世界存档损坏”的问题。硬盘坏道、机房断电、误删文件，任何一个都足以让你几周的建设毁于一旦。我的备份方案分三层：
- 存档热备份：趁服务器在跑的时候，直接用
cp -r复制world文件夹。这种方式不保证完全一致，但出问题的概率很低，适合频繁备份。 - 停机冷备份：服务器关掉后复制world文件夹。一致性最好，但需要窗口期。
- 远程异地备份：把备份文件传到另一台机器或对象存储——本地服务器都炸了数据还能救。
我写了一个备份脚本，每天凌晨4点执行一次，保留最近7天：
#!/bin/bash BACKUP_DIR=/srv/backups WORLD_DIR=/srv/mc-server/world DATE=$(date +%Y%m%d-%H%M%S) screen -S mc-server -X stuff "say 服务器将在10秒后备份存档\n" sleep 10 screen -S mc-server -X stuff "save-all\n" sleep 5 screen -S mc-server -X stuff "save-off\n" tar -zcf "$BACKUP_DIR/world-$DATE.tar.gz" "$WORLD_DIR" screen -S mc-server -X stuff "save-on\n" screen -S mc-server -X stuff "say 备份完成\n" find "$BACKUP_DIR" -name "*.tar.gz" -mtime +7 -delete这里的screen -S mc-server -X stuff是往运行中的服务端控制台发送指令。save-off和save-on是暂停和恢复自动存档（对Paper来说，相当于把存档系统锁住），这样打包的world文件夹是完整一致的。如果服务端不是跑在screen会话里，这套脚本就不适用，后面讲的systemd方案有更好的处理方式。
自动清理方面，每天清理掉落物是个好习惯，尤其是有刷怪塔的服务器。在spigot.yml里可以调item-despawn-rate（默认6000刻，即5分钟），改成3000让掉落物更快消失。还可以用插件定时执行kill @e[type=item]指令。我服务器上就曾经因为一个玩家挂机刷物品机，掉落物堆了上万个，TPS直接掉到个位数，清理完立刻恢复。
3.3 网络层与端口防暴露
MC服务器默认端口是25565，装完服务端后需要在防火墙放行：
ufw allow 25565/tcp注意MC用的是TCP而非UDP。而且很多云服务器厂商的安全组规则也要单独配置，服务器内部防火墙放开了，安全组没放也不行，这个问题不知道坑了多少新手。
server.properties里还有一个参数对网络体验影响很大：network-compression-threshold。默认值是256，意思是数据包超过256字节就要压缩。对于高延迟玩家（比如连到海外的服务器），调大这个值到512或1024可以减少压缩CPU开销，但会增大网络带宽消耗。如果你服务器带宽很贵（比如按流量计费），保持默认更省钱。
关于防攻击，有一个基础但重要的设置：在server.properties里把max-players设为预期人数加几位余量，不要设成几千，因为攻击者可以靠占满玩家槽位来拒绝正常玩家进服。装一个连接频率限制类插件也值得考虑。
4. 崩服自启的实现：看门狗方案完整解析
这应该是全篇最值钱的部分。我做过三种自启方案，从简单到复杂，各有适用场景，下面逐个拆解。
4.1 方案一：Shell循环脚本（最简单，适合新手）
原理是启动一个外层脚本，它跑一个while循环，检测到服务端进程退出就立刻重启：
#!/bin/bash while true; do /srv/mc-server/start.sh echo "[$(date)] 服务器退出，5秒后重启..." >> /var/log/mc-watchdog.log sleep 5 done这个方案的问题在于：如果服务端因为某种系统性错误在启动后立即崩溃，脚本会陷入无限重启循环，疯狂刷日志。解决办法是加个“连续崩溃N次就放弃”的计数器，并发送报警通知。
#!/bin/bash FAIL_COUNT=0 MAX_FAIL=5 while true; do /srv/mc-server/start.sh FAIL_COUNT=$((FAIL_COUNT+1)) echo "[$(date)] 第 $FAIL_COUNT 次崩溃重启" >> /var/log/mc-watchdog.log if [ $FAIL_COUNT -ge $MAX_FAIL ]; then echo "[$(date)] 连续崩溃 $MAX_FAIL 次，停止重启，需要人工介入。" >> /var/log/mc-watchdog.log break fi sleep 5 done注意我故意没有用nohup或后台运行的方式，而是让脚本保持前台执行。一旦你把这个脚本丢进systemd服务里，它本身就变成了服务的生命周期管理者，崩溃重启都由systemd接管。
4.2 方案二：systemd服务 + Restart参数（最推荐，Linux首选）
如果服务器操作系统是Linux，系统自带的systemd就是最好的看门狗，不需要额外装任何东西。把MC服务注册成systemd服务：
[Unit] Description=Minecraft Server After=network.target [Service] WorkingDirectory=/srv/mc-server ExecStart=/srv/mc-server/start.sh ExecStop=/srv/mc-server/stop.sh Restart=on-failure RestartSec=10s User=mc-server Group=mc-server [Install] WantedBy=multi-user.target核心参数是Restart=on-failure，它告诉systemd只要服务异常退出（非0退出码）就自动拉起。RestartSec=10s是控制重启间隔，给系统留出释放资源的时间，太短容易造成端口占用冲突。
有人会问，MC服务端正常关闭（比如stop命令退出）时，退出码是0，不会触发重启；只有崩溃、被kill这种非正常退出才会重启。这个逻辑区分很重要。
配合ExecStop，我写了一个干净的停止脚本stop.sh，保证关服时先把存档刷盘再退出：
#!/bin/bash cd /srv/mc-server screen -S mc-server -X stuff "say 服务器即将关闭，请退出游戏\n" sleep 5 screen -S mc-server -X stuff "stop\n"但如果MC进程不是在screen会话里跑，那ExecStop的screen指令就无效了。这里有个更标准的做法：系统向Java进程发送SIGTERM信号时，JVM默认会直接退出，不会跑MC的关服逻辑，存档可能损坏。所以更稳妥的方式是用ExecStop=/bin/kill -TERM $MAINPID，并且给Java配置一个关闭钩子（在start.sh里加trap 'screen -S mc-server -X stuff "stop"' SIGTERM）。这套我实际用了几个月，关服时存档100%完好。更简单的办法是用rcon协议远程发送stop命令，需要开RCON端口，安全性弱一些。我的实践是：用小插件把终端指令接线到ConsoleCommand，再配合systemd的ExecStop调脚本发送stop，这样最干净。
正确设置User和Group，不要用root跑服务端，这是安全底线。用root跑导致的文件权限混乱问题，轻则出现奇怪报错，重则整个服务器被黑。我专门建了个mc-server用户：
useradd -m -s /bin/bash mc-server chown -R mc-server:mc-server /srv/mc-server4.3 方案三：外部监控脚本（最可靠，适合重要服务器）
systemd方案虽然好，但有一个盲区：如果MC进程没退出，但服务端卡死（表现为TPS为0、玩家全部掉线、端口还在但数据不响应），systemd认为进程还在，不会重启。这种“假死”状态在大量加载区块或某个诡异bug出现时偶尔会发生，普通看门狗束手无策。
要处理假死，就需要一个外部监控脚本，周期性地给服务端发送指令，确认它“还活着”。方法是通过RCON端口发指令：
#!/bin/bash rcon-cli --host localhost --port 25575 --password yourpassword "list" > /dev/null 2>&1 if [ $? -ne 0 ]; then systemctl restart mc-server echo "[$(date)] 服务端假死，已重启。" >> /var/log/mc-watchdog.log fi配合cron每2分钟执行一次：
*/2 * * * * /usr/local/bin/mc-healthcheck.sh如果RCON不方便，也可以用端口探测工具nc -z localhost 25565仅检测TCP连通性。但这种方式只能探到端口在听，探不到服务端是否真正响应，效果打折。
RCON密码不要写在明文脚本里。我用的做法是给脚本单独建一个文件，权限设成600，并且脚本运行时以独立的非root用户执行，降低泄露面。
4.4 崩溃日志分析与自愈扩展
自启只能解决“起不来”的循环，不能解决“为什么崩”的根因。每次崩溃后，第一件事是去看日志：
logs/latest.log：服务端日志，会记录崩溃前的最后动作。crash-reports/目录：Paper等生成的标准崩溃报告，信息非常详细，包含崩溃线程、相关mod或插件、堆栈信息。
常见的崩溃原因有三种：内存耗尽（OutOfMemoryError）、插件冲突（多见于模组服）、区块损坏。区块损坏的修复方式是用工具把损坏区块删除，比如MC官方的区域文件编辑器或第三方工具，让服务器重新生成该区块。
把崩溃日志分析做进自愈流程里是我在稳定方案里一直在迭代的方向。例如连续崩溃3次后，脚本自动备份错误日志并调用一个分析脚本，把最后100行日志发给管理员——通过webhook或邮件。虽然不能自动修bug，但至少你不用开电脑盯日志才能发现服务器挂了。
5. 实操中的高频故障与排查速查表
这部分我把实际操作中遇到过的、以及身边朋友踩过的高频问题整理成速查表。不追求面面俱到，只收录真正影响使用的常见问题。
| 现象 | 原因 | 排查与解决方案 |
|---|---|---|
启动报错Java version is too old/new | Java版本不匹配 | 用java -version确认版本，按MC版本安装对应JDK |
| 启动后秒退 | 未同意EULA | 确认eula.txt内容是eula=true |
| 玩家能进，但世界空白 | 内存不足/WORLD加载失败 | 查看latest.log和crash-report，增加Xmx内存，必要时恢复备份 |
| TPS低于15 | 实体堆积/红石机器太多 | 用spark分析，优化不合理设计，限制实体数量 |
| 重启后存档丢失 | 上次非正常退出 | 确保关服用了stop，定期用save-all先刷盘再备份 |
| 面板显示离线但进程在跑 | 服务端假死 | 接上外部RCON监控脚本，重启进程 |
| 端口可以ping通但连不上 | 安全组/防火墙未放通 | 检查ufw和安全组两部分 |
| 服务器一切正常但很卡 | 所在机房网络质量差 | 更换线路、查看网络延迟、减小视距 |
| 插件装不上/报错 | 插件版本与服务端核心不匹配 | 对照插件支持的MC版本与服务端版本，确认兼容性 |
| 模组服启动到一半崩溃 | 模组冲突/内存不足 | 看crash-report，禁用冲突模组，调大Xmx |
还有一个经常被忽略但很容易导致崩服的“隐藏BOSS”：服务器系统盘满了。MC服务端只要在跑，就会持续写日志、写区块文件，再加上备份占用，磁盘说满就满。磁盘满时Java写文件失败，服务端不会自动退出，但会出现各种诡异bug——比如存档回退、玩家物品消失、区块加载异常。所以监控脚本里一定要加上磁盘使用率检查：
#!/bin/bash DISK_USAGE=$(df /srv/mc-server --output=pcent | tail -1 | tr -d ' %') if [ $DISK_USAGE -gt 90 ]; then echo "[$(date)] 磁盘使用率超过90%，请及时清理" >> /var/log/mc-watchdog.log # 可选的清理动作：删除超过7天的备份 find /srv/backups -name "*.tar.gz" -mtime +7 -delete fi放到cron里每天跑一次就行。
6. 工具链选型与替换思路
搭建稳定MC服务器，除了服务端本身，周边工具选对了能省掉大量手动作业。我的最终工具链如下，都在实战中跑过：
| 功能 | 工具 | 选型理由 |
|---|---|---|
| 服务端 | Paper 1.20.4 | 性能比原版好，插件生态全 |
| Java | OpenJDK 17 | 满足MC版本需求，与G1GC搭配良好 |
| 进程守护 | systemd | 系统原生，内存占用几乎为零 |
| RCON发送 | mcrcon编译版 | 轻量、支持脚本调用 |
| 存档备份 | tar + crontab | 无额外依赖，简单可靠 |
| 性能排查 | spark插件 | TPS采样、卡顿定位能力强 |
| 崩溃告警 | webhook脚本 | 第一时间知道服务器状态 |
一些朋友会用Docker跑MC服务器，我个人的看法是：可以但没必要。Docker的隔离特性确实能解决环境依赖问题，但其进程生命周期和自启逻辑与systemd重叠，还得自己处理磁盘和网络映射。除非你要在一台机器上跑多个隔离服务端，否则直接用systemd更简单、更容易排查。
模组服的替换选择也提一下：如果玩的是CurseForge上的整合包，启动器一般自带一个用于服务端的脚本或说明，跟着走就行。整合包服务端通常需要预先带模组文件、配置文件，启动还可能要指定内存参数和nogui模式，这些细节在整合包说明文档里都有，不用额外发挥。
7. 最终稳定方案的完整组装
把前面所有内容串起来，我最终在服务器上跑的那套方案，按顺序执行如下步骤就可以完整复制：
- 系统层面：装好Linux系统，更新包，安装OpenJDK 17。
- 创建用户和目录：
useradd -m -s /bin/bash mc-server，/srv/mc-server目录给足权限。 - 下载Paper服务端到目标目录，首次运行生成配置，改eula和server.properties关键参数。
- 写start.sh和stop.sh，加上JVM参数，chmod给执行权限。
- 写systemd服务文件，填入User、ExecStart、Restart等字段，
systemctl daemon-reload后启用。 - 配置RCON密码，让healthcheck脚本通过RCON探活，配合cron每2分钟运行一次。
- 写备份脚本，每天凌晨执行，保留最近7天，磁盘占用超阈值自动清理。
- 安装spark插件用于性能监控，定期查看TPS和GC日志。
把这套跑起来之后，我朋友那服务器连续30多天没重启过，期间有过一次内存波动和一次疑似区块加载卡顿，但都被健康检查在1分钟内自动恢复了。玩家都以为我天天盯着服务器，其实我基本没怎么登录过后台。
有人问，既然有自动重启了，是不是可以高枕无忧？我的回答是：自动重启是最后一道保险，不是第一道防线。真正让服务器稳定的，是内存余量是否充足、服务端类型选得对不对、插件装得少而精、备份有没有及时做。如果你在凌晨四点被一个“崩服告警”吵醒，打开日志一看是内存溢出，你并不会因为服务器自动恢复而高兴——你只会懊恼自己当初为什么没多给两个G内存。
8. 边角经验：那些教程里不会写但你有机会踩中的细节
最后补几个零散但实用的经验，都是我在无数个深夜查日志总结出来的。
第一，不要让服务端的配置文件和启动脚本在root用户下生成，再切到普通用户跑。这样会导致普通用户没有权限修改配置，每次改配置都要提权，烦人且危险。建好目录后直接切到目标用户去操作，权限从一开始就正确，后面省心太多。
第二，保存日志是一个低成本高回报的习惯。在start.sh里把stdout和stderr重定向到独立日志文件（比如/var/log/mc-server.log），而不是让systemd自己接管输出。否则journalctl -u mc-server会因日志体量巨大而变卡，而且没有自动轮转容易塞满磁盘。
exec java ... -jar paper.jar nogui >> /var/log/mc-server.log 2>&1第三，有人问过我用Windows服务器行不行，答案是可以，但系统本身比Linux占资源，性能普遍差约10%-20%，而且系统的自动重启依赖计划任务配合，比systemd绕一些。Windows唯一的好处是图形界面操作直观，适合不熟悉命令行的朋友。如果你确实非Windows不可，把思路迁移过去即可：用任务计划程序轮询进程，崩溃后重新执行启动脚本。但记住不要用cmd的start命令直接起Java，否则日志输出会丢失，排查问题难上加难。
最后再讲一个小技巧：新版本Paper的服务端配置文件里，有一个max-auto-save选项，控制自动保存间隔。默认设置一般是自动的，但对模组服来说，频繁自动保存会带来明显的卡顿峰值，尤其在线人数多的时候。我建议手动设置成600秒一次，离谱吗？不，配合好备份脚本，这个间隔是完全可接受的，而且能显著减少保存瞬间的TPS抖动。如果担心崩溃丢数据，保存间隔短一些就找好平衡点，比如120秒。
我踩过最冤的一次坑是：服务器一切正常，但玩家每隔几分钟集体卡一下，TPS曲线图上一堆眼状凹陷。排查了半天发现是某个插件在频繁写数据库，每次写入都触发世界自动保存。关掉自动保存、改为手动定时后，曲线图平滑得跟心电图痊愈了似的。这类问题，不亲眼见过一次，根本想不到是这个原因。
搭建稳定MC服务器本质上是系统工程。服务端选型、JVM参数、系统配置、备份策略、监控告警、重启机制，每个环节相互关联，任何一环掉链子都能让你从“服务器管理员”变回“熬夜陪聊客服”。希望这篇东西能帮你少熬几个夜。至少我知道，下次我朋友再让我搭服，这套方案可以直接复制过去，然后安心睡觉。
