企业官网建设流程全解析

1. 为什么偏偏是 Mac Mini 来跑 MC 服务器

1.1 从一台闲置小主机说起

手里这台 Mac Mini 是去年换下来的，M 系列芯片，16GB 统一内存，512GB 固态。平时放在桌角吃灰，偶尔拿来当个下载机。直到某天晚上，几个老伙计在群里嚷嚷着要重开一个 Minecraft 服务器，我才突然意识到——这玩意儿不就是现成的服务器吗？

低功耗、静音、体积小、性能够用，这几个标签贴在 Mac Mini 身上简直完美。你可能会问，为什么不用云服务器？我算过一笔账：一台能稳定跑 10 人左右模组生存的云主机，月付少说也要大几十到上百块，一年下来够买半台二手 Mac Mini 了。而且云服务器的 CPU 单核性能往往很拉胯，MC 这游戏偏偏又极度吃单核性能，主频上不去，TPS 就稳不住，人一多就卡成幻灯片。

Mac Mini 的 M 系列芯片，单核性能在消费级里属于第一梯队，功耗却只有十几瓦到几十瓦。7×24 小时开着，一个月电费也就几块钱。再加上 macOS 本身是 Unix 内核，跑 Java 版服务端天然友好，命令行工具齐全，拿来当 MC 服务器再合适不过。

1.2 这套方案到底能解决什么问题

说白了，这个项目的核心目标就三个：稳定、低延迟、低成本。

稳定指的是服务器能长时间不崩、不卡顿、不丢档。低延迟指的是同城或同省的朋友连进来，延迟能压在 20ms 以内，打怪挖矿没有明显的操作滞后感。低成本则是指硬件一次性投入之后，后续几乎没有额外开销，电费忽略不计。

适合谁来参考？如果你手里正好有一台闲置的 Mac Mini，或者正打算收一台二手的来当家庭服务器，又或者你是个小团体的服主，厌倦了云服务器的高昂月费和性能瓶颈，那这套方案就是为你准备的。哪怕你之前没怎么碰过命令行，跟着走也能搭起来。

1.3 先泼一盆冷水：Mac Mini 跑 MC 的先天短板

在开始之前，我得先把丑话说在前头。Mac Mini 跑 MC 服务器，并不是没有坑。

第一个坑是内存。M 系列芯片用的是统一内存，CPU 和 GPU 共享。如果你买的是 8GB 版本，那基本只能跑原版或者轻量插件服，模组服想都别想。16GB 是起步，24GB 或 32GB 才能比较从容地跑中型模组包。这个在选购二手机的时候一定要看清楚，别贪便宜买 8GB 的，到时候哭都来不及。

第二个坑是散热。Mac Mini 的散热设计偏向静音，长时间满载运行，机身会温热，但一般不会降频降得太厉害。不过如果你把它塞在密闭的柜子里，那就不行了。我实测下来，放在通风的桌面上，连续跑一周，CPU 温度稳定在 70 度上下，完全可以接受。

第三个坑是系统生态。有些 MC 服务端的插件或者工具，是专门为 Linux 写的，在 macOS 上跑需要额外折腾。比如某些基于 glibc 的二进制工具，在 macOS 上就得找替代方案或者用容器跑。这个后面会详细讲。

2. 开服前的硬件与系统准备

2.1 机型选择与内存容量的硬性门槛

先说说机型。目前市面上能买到的 Mac Mini，从 M1 到 M4 都有，M4 之后的型号性能更强，但价格也更高。如果你只是跑原版或者轻量插件服，M1 的 16GB 版本就绰绰有余了。我实测过，M1 跑 Paper 服务端，10 个玩家在线，视距开到 10，TPS 稳定在 20，内存占用大概 4 到 6GB。

如果你要跑模组服，比如那种包含几百个模组的大型整合包，那建议至少 M2 Pro 或者 M4 的 24GB 版本。模组服的内存占用是插件服的好几倍，而且模组加载本身就很吃 CPU 单核性能。我试过用 M1 16GB 跑一个 200 模组的整合包，启动就花了将近 5 分钟，进游戏后 TPS 经常掉到 15 以下，体验很差。换成 M4 24GB 之后，启动时间缩短到 2 分钟以内，TPS 基本能稳住 19 到 20。

这里给一个简单的内存对照表，方便你判断自己的需求：

注意，这里说的内存是分配给 Java 虚拟机的堆内存，不是整机内存。整机内存还要留出几个 GB 给系统和其他后台进程。所以 16GB 的机器，最多分配给 MC 服务端 10 到 12GB，再多就会开始用交换分区，性能反而下降。

2.2 系统版本与 Java 运行时的匹配

macOS 的版本建议保持在较新的稳定版，比如 macOS 14 或者 15。太老的系统可能缺少一些新的命令行工具，或者对 Java 的支持不够好。

Java 运行时的选择是个关键点。MC 服务端从 1.17 开始，官方推荐使用 Java 17。1.20.5 之后，推荐 Java 21。如果你跑的是模组服，那还要看模组加载器 Forge 或者 NeoForge 的要求。一般来说，Java 21 是目前最稳妥的选择，兼容性最好。

在 macOS 上安装 Java，我推荐用 Homebrew，省心省力。打开终端，先装 Homebrew，然后一行命令搞定：

brew install openjdk@21

装完之后，还需要把 Java 加到环境变量里。macOS 上 Homebrew 装的 OpenJDK 默认不会自动链接到系统路径，需要手动处理一下：

sudo ln -sfn /opt/homebrew/opt/openjdk@21/libexec/openjdk.jdk /Library/Java/JavaVirtualMachines/openjdk-21.jdk

然后验证一下：

java -version

如果输出显示 21 版本，那就没问题了。这里有个小坑，如果你之前装过其他版本的 Java，可能会冲突。用which java看看当前用的是哪个，如果不是你刚装的，就调整一下 PATH 的顺序。

2.3 网络环境与端口的基础配置

Mac Mini 一般放在家里，走的是家庭宽带。这里有几个事情要确认。

首先是公网 IP。如果你想让外面的朋友连进来，那你的宽带需要有公网 IP。现在很多运营商默认给的是内网 IP，需要打电话申请。这个各地政策不一样，有的免费给，有的要加钱。如果没有公网 IP，那就只能走内网穿透或者组网方案，这个后面会提。

其次是端口映射。MC 服务端默认监听 25565 端口。你需要在路由器的管理后台，把这个端口映射到 Mac Mini 的内网 IP 上。内网 IP 建议在路由器里给 Mac Mini 绑定一个固定的 DHCP 地址，免得重启之后 IP 变了，映射失效。

最后是防火墙。macOS 自带的防火墙可能会拦截入站连接。你需要在系统设置里，把 Java 进程加入允许列表，或者干脆在测试阶段临时关闭防火墙。不过我不建议长期关闭，还是加白名单比较稳妥。

提示：如果你的宽带没有公网 IP，可以考虑用 Tailscale 或者 ZeroTier 这类组网工具，把几个朋友拉进同一个虚拟局域网，然后直接用内网 IP 连接。这种方式延迟略高一点，但胜在简单，不需要折腾路由器。

3. 服务端选型与核心配置调优

3.1 Paper、Fabric、Forge 到底选哪个

服务端的选择，直接决定了你后续的玩法方向和折腾难度。

Paper是目前最流行的插件服务端，基于 Spigot 优化而来，性能好，插件生态丰富。如果你只是想和朋友玩原版生存，加点小游戏、经济系统、领地保护之类的插件，那 Paper 是首选。它的配置文件清晰，社区支持也好，遇到问题基本都能搜到答案。

Fabric是轻量级的模组加载器，启动快，对原版改动小。适合想加一些辅助模组，比如小地图、性能优化、背包整理，但又不想大改游戏内容的玩家。Fabric 的服务端配置相对简单，模组兼容性也不错。

Forge是老牌的模组加载器，大型整合包基本都用它。缺点是启动慢，内存占用高，而且不同模组之间的冲突比较常见。如果你要跑那种几百个模组的整合包，那基本没得选，只能上 Forge 或者它的衍生版 NeoForge。

我个人的建议是，先从 Paper 入手，把服务器跑起来，熟悉一下基本的运维操作。等有经验了，再根据需求切换到模组服务端。不要一上来就搞大型整合包，那样很容易被各种报错劝退。

3.2 启动参数的计算与 JVM 调优

启动参数是很多新手容易忽略的地方，但它对性能的影响非常大。默认的启动脚本往往只设置了内存上限，没有做垃圾回收的优化，跑久了就容易卡顿。

先看内存参数。-Xms和-Xmx分别是最小和最大堆内存。建议把这两个值设成一样，避免 JVM 在运行过程中动态调整堆大小带来的性能波动。比如你想分配 8GB，就写：

-Xms8G -Xmx8G

然后是垃圾回收器。Java 21 默认用的是 G1 GC，对 MC 服务端来说已经够用了。但如果你追求更低的停顿时间，可以试试 ZGC 或者 Shenandoah。不过这两个在 macOS 上的表现，我实测下来和 G1 差别不大，除非你的内存特别大，否则没必要折腾。

一个比较通用的启动参数模板是这样的：

java -Xms8G -Xmx8G \ -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 \ -jar server.jar nogui

这一长串参数看着吓人，其实核心就几个：用 G1 GC，控制停顿时间在 200ms 以内，调整新生代的比例，让垃圾回收更平滑。AlwaysPreTouch这个参数会让 JVM 在启动时就把内存全部占住，虽然启动慢一点，但运行起来更稳定，不会因为内存分配而卡顿。

3.3 服务端配置文件的逐项拆解

服务端的server.properties文件里，有几个参数直接影响性能和体验，值得单独拿出来说。

view-distance是视距，默认是 10。这个值越大，玩家能看到的范围越广，但服务端的负载也越高。对于 Mac Mini 来说，建议设在 6 到 8 之间。我实测过，视距从 10 降到 6，TPS 能从 18 提升到 20，效果很明显。玩家那边可能会觉得视野稍微近了一点，但流畅度提升是值得的。

simulation-distance是模拟距离，控制怪物、作物、红石等游戏逻辑的活跃范围。这个值默认和视距一样，但可以单独调低。比如视距设 8，模拟距离设 6，这样玩家能看到较远的风景，但只有近处的实体在活动，能省不少 CPU。

max-players是最大玩家数。这个要根据你的硬件和玩法来定。原版生存 10 个人左右，Paper 插件服 15 到 20 个人，模组服可能只能撑 5 到 8 个人。不要设得太高，否则人一多就卡。

network-compression-threshold是网络压缩阈值，默认是 256。这个值决定了多大的数据包会被压缩。对于家庭宽带来说，上传带宽通常比较有限，开启压缩能省不少流量。但如果你的 CPU 比较弱，压缩本身也会消耗性能。Mac Mini 的 CPU 足够强，保持默认或者调到 512 都可以。

sync-chunk-writes这个参数控制区块写入是否同步。默认是 true，改成 false 能提升性能，但万一服务器崩溃，可能会丢一点最近的区块数据。如果你有定期备份的习惯，可以改成 false。

4. 从零到一的完整开服实操

4.1 目录规划与文件下载

先在 Mac Mini 上建一个专门的目录，把所有服务器相关的文件都放在里面。我习惯放在用户目录下的mc-server文件夹：

mkdir -p ~/mc-server cd ~/mc-server

然后下载服务端核心。以 Paper 为例，去官网找到对应版本的下载链接，用curl直接下载：

curl -o server.jar https://api.papermc.io/v2/projects/paper/versions/1.21.1/builds/xxx/downloads/paper-1.21.1-xxx.jar

注意把 URL 里的版本号和构建号换成你实际需要的。下载完之后，先跑一次，让它生成配置文件：

java -Xms4G -Xmx4G -jar server.jar nogui

第一次运行会报错退出，这是正常的，因为它需要你同意 EULA。打开生成的eula.txt，把eula=false改成eula=true，然后再跑一次。

4.2 首次启动与 EULA 同意

第二次启动，服务端会开始生成世界。这个过程可能需要几分钟，取决于你的 CPU 性能和世界大小。你会看到控制台刷出一堆日志，最后出现Done字样，就说明启动成功了。

这时候你可以用localhost:25565在游戏里连一下，确认能进去。如果能进，说明服务端本身没问题。接下来就是配置外网访问和插件了。

注意：首次启动时，不要急着把内存设得太大。先用一个较小的值跑起来，确认没问题之后再调整。因为如果参数有问题，大内存启动失败会更浪费时间。

4.3 插件安装与权限组配置

Paper 的插件安装很简单，把下载好的.jar文件丢进plugins文件夹，然后重启服务器就行。常用的插件有 EssentialsX（基础指令）、LuckPerms（权限管理）、WorldGuard（领地保护）、CoreProtect（方块记录）等。

这里重点说一下 LuckPerms 的配置，因为权限系统是很多新手容易搞混的地方。LuckPerms 的核心概念是“组”和“权限节点”。你可以创建一个默认组，给普通玩家一些基础权限，比如/spawn、/home、/tpa。然后创建一个管理员组，继承默认组的所有权限，再加上 ban、kick、op 等管理权限。

配置的方式有两种：一种是在游戏里用指令，另一种是直接编辑配置文件。我推荐用指令，因为不容易出错。比如创建一个组：

/lp creategroup default /lp creategroup admin

然后给组分配权限：

/lp group default permission set essentials.spawn true /lp group default permission set essentials.home true /lp group admin parent add default /lp group admin permission set essentials.ban true

最后把玩家加到对应的组里：

/lp user Steve parent set default /lp user Alex parent set admin

这套流程走下来，权限系统就基本成型了。后续再根据实际需求微调就行。

4.4 内网穿透与远程访问的替代方案

如果你没有公网 IP，或者不想折腾路由器，那可以用组网工具来实现远程访问。Tailscale 是我用得比较顺手的一个，安装简单，配置也直观。

在 Mac Mini 上安装 Tailscale：

brew install tailscale

然后启动并登录：

sudo tailscaled install-system-daemon tailscale up

它会给你一个链接，在浏览器里打开，登录账号，这台机器就加入你的虚拟网络了。然后让你的朋友也安装 Tailscale，加入同一个网络。之后他们就可以用 Mac Mini 的 Tailscale IP 来连接服务器了。

这种方式的延迟会比直连公网 IP 高一点，但胜在稳定，不需要公网 IP，也不受运营商限制。对于小团体来说，完全够用。

5. 性能压测与常见故障排查

5.1 用 Spark 定位卡顿根源

服务器跑起来之后，最怕的就是莫名其妙卡顿。这时候就需要一个性能分析工具，Spark 是目前最好用的一个。它是一个插件，装上去之后，可以用指令生成性能报告。

比如你想看看最近几分钟的 TPS 波动，可以用：

/spark tps

它会显示最近 1 分钟、5 分钟、15 分钟的平均 TPS。如果 TPS 低于 20，那就说明有性能问题。接着可以用：

/spark profiler start

让它跑个几十秒，然后：

/spark profiler stop

它会生成一个链接，在浏览器里打开，就能看到详细的火焰图。哪个方法占用的 CPU 时间最多，一目了然。我遇到过好几次卡顿，都是因为某个插件在疯狂遍历实体，用 Spark 一查就找到了。

5.2 内存泄漏与 GC 频繁的典型症状

内存泄漏是模组服常见的问题。症状是服务器运行一段时间后，内存占用越来越高，GC 越来越频繁，最后要么卡死，要么直接崩溃。

判断是不是内存泄漏，可以看 GC 日志。在启动参数里加上：

-Xlog:gc*:file=gc.log:time,uptime:filecount=5,filesize=10M

这样 GC 日志会写到gc.log文件里。如果看到 Full GC 越来越频繁，而且每次回收之后内存下降得越来越少，那基本就是泄漏了。

解决的办法通常是逐个排查模组或者插件。先把所有非核心的模组禁用，跑一段时间看是否还有泄漏。如果没有，再逐个加回来，直到找到罪魁祸首。这个过程比较耗时，但没办法，模组冲突就是这样。

5.3 玩家进不来？先查这五个地方

玩家连不上服务器，是最常见的问题。我整理了一个排查顺序，按这个来基本能解决九成以上的连接问题。

如果这五项都没问题，那可能是服务端的server.properties里server-ip绑定了错误的地址。默认是留空，表示监听所有网卡。如果你之前改过，记得改回来。

5.4 存档备份与回档的保命操作

最后说一个最重要的事情：备份。MC 服务器最怕的就是存档损坏，一旦坏了，几百个小时的心血就没了。

我用的方案是定时任务加脚本。写一个简单的备份脚本：

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

然后用crontab设置每天凌晨 4 点执行一次：

0 4 * * * /bin/bash ~/backup.sh

这样每天都会自动备份，而且只保留最近 7 天的，不会把硬盘塞满。如果哪天存档出了问题，解压最近的备份覆盖回去就行。

提示：备份的时候最好先让服务器保存并关闭，或者在备份前执行save-all指令，确保数据都写入了磁盘。直接备份正在运行的世界文件夹，可能会得到不一致的数据。

6. 长期运行的维护心得

6.1 定时重启到底有没有必要

关于定时重启，社区里一直有争议。有人觉得没必要，有人觉得能预防内存泄漏。我的看法是，如果你的服务器跑的是原版或者轻量插件服，那没必要定时重启，跑几周不重启也没问题。但如果是模组服，尤其是那种大型整合包，那建议每天或者每两天重启一次。

原因很简单，模组服的代码质量参差不齐，内存泄漏几乎是必然的。定时重启能强制释放内存，让服务器保持在一个相对干净的状态。我一般设置在凌晨 5 点，这时候基本没人玩，重启的影响最小。

重启的方式也有讲究。不要直接 kill 进程，那样可能会丢数据。正确的做法是先执行stop指令，等服务器完全关闭之后，再重新启动。可以写一个脚本来自动化这个过程：

#!/bin/bash screen -S mc -X stuff "stop\n" sleep 30 cd ~/mc-server screen -dmS mc java -Xms8G -Xmx8G -jar server.jar nogui

这个脚本用screen来管理服务端进程，先发送 stop 指令，等 30 秒，再重新启动。配合 crontab，就能实现无人值守的定时重启。

6.2 模组更新与版本升级的稳妥节奏

模组更新是个让人又爱又恨的事情。新版本可能修复了 bug，也可能引入了新的 bug。我的策略是：不追新，只求稳。

具体来说，服务端核心和模组的版本，不要一出来就更新。等个一两周，看看社区反馈，确认没有大面积的问题再动。更新之前，一定要备份存档和配置文件。更新之后，先自己进去跑一圈，确认没问题再通知其他人。

如果是大版本升级，比如从 1.20 升到 1.21，那更要谨慎。很多模组可能还没适配新版本，强行升级会导致服务器起不来。正确的做法是，先在一个单独的测试环境里跑一遍，确认所有模组都能正常工作，再迁移正式服。

6.3 功耗、噪音与散热的长测记录

最后分享一下我这台 Mac Mini 长期运行的实测数据。

功耗方面，待机大概 5 到 8 瓦，满载跑 MC 服务器大概 25 到 35 瓦。按 30 瓦算，一天 0.72 度电，一个月大概 22 度。按居民电价算，一个月电费也就十块钱出头。相比云服务器，这个成本几乎可以忽略不计。

噪音方面，Mac Mini 的风扇在低负载下基本不转，满载时会有轻微的风声，但放在桌面上几乎听不到。我把它放在书桌角落，距离人大概一米，晚上安静的时候才能隐约听到一点风扇声。

散热方面，连续跑了一周之后，机身顶部摸起来温温的，大概四十度左右。用软件看 CPU 温度，稳定在 65 到 75 度之间。这个温度对于长时间运行来说是完全正常的，不用担心。

唯一需要注意的是灰尘。Mac Mini 的进风口在底部，时间长了容易积灰。建议每隔几个月，用压缩空气吹一下底部，保持通风顺畅。

这套方案我跑了大半年，除了偶尔因为模组冲突重启一下，整体非常稳定。几个朋友玩得也挺开心，延迟低，不卡顿，体验比之前用的云服务器好太多了。如果你手里正好有闲置的 Mac Mini，不妨试试，说不定能给你带来意想不到的惊喜。