在非 Paper 服务器上禁用 sync-chunk-writes
推荐值
sync-chunk-writes = false
将区块保存移出主线程，以避免长时间的 I/O 停顿并减少原版、Fabric 和 Spigot 服务器上的卡顿。
🚀 高影响力的 Minecraft 服务器优化概览
在准备新服务器或从卡顿和 TPS 下降中拯救现有世界时，请将本指南作为实用的检查清单。
专注于 TPS 和 MSPT
使用针对现代 1.21.x 服务器工作负载设计的配置预设，围绕目标 20 TPS 和低于 50 ms 的 MSPT 进行优化。
- 拥有活跃玩家群体的生存和 SMP 服务器
- 小游戏大厅和社区服务器
- 基于 Fabric 或 Forge 构建的适度模组设置
对实时服务器安全
所有建议都优先考虑稳定性，然后是性能。您可以逐步应用它们，而无需擦除世界或重置玩家进度。
- 没有破坏核心游戏循环的极端更改
- 与流行的生存服务器插件兼容
- 当设置影响农场或自动化时有明确说明
为现代托管构建
围绕常见的托管场景设计，从自托管专用实例到云 VPS 和 CPU 时间有限的游戏面板提供商。
- 单核性能和 SSD 优先的思维方式
- 全球低延迟玩家体验
- 随着玩家数量增长的扩展策略
⚡ 快速修复清单
在进行深度分析之前应用这些高影响力的更改，以快速消除最常见的 Minecraft 服务器瓶颈。
使用现代 Paper 或 Purpur 作为您的服务器核心
推荐值
Paper / Purpur = 最新稳定版
为您提供现代异步区块加载、更好的生物上限以及 Bukkit 或 Spigot 上不存在的数十个性能补丁。
设置安全的模拟和视距
推荐值
simulation-distance / view-distance = 4 / 7
保持较低的 tick 成本，同时仍允许玩家看得很远，以适应生存、SMP 和小游戏服务器。
应用平衡的生物生成限制
推荐值
spawn-limits = monsters: 20, animals: 5, water: 2, ambient: 1
防止不受控制的生物数量，同时保持生存游戏和农场对玩家来说感觉自然。
启用每玩家生物生成
推荐值
per-player-mob-spawns = true
防止单个玩家或农场消耗整个生物上限，以便每个在线玩家都能获得公平的生物生成。
提示：点击任何推荐值将其复制到剪贴板，然后再编辑配置文件。
🧩 推荐配置基准
这些基准源自既定的社区优化指南和针对 1.21.x 服务器的现代 Minecraft Wiki 文档。
🌐 网络和延迟
稳定玩家连接，减少超时，并保持数据包效率，以适应繁忙的生存和 SMP 服务器。
| 文件 | 选项 | 推荐值 | 类型 | 备注 |
|---|---|---|---|---|
| server.properties | network-compression-threshold | 256 | CPU ↔ 带宽权衡 | 使用 256 作为起点。如果您的 CPU 过载，请增加该值；如果玩家带宽受限，请降低该值。仅在极低延迟的内部网络或代理设置上设置为 -1。 |
| purpur.yml | use-alternate-keepalive | true | 连接稳定性 | 通过发送更频繁的 keepalive 数据包，减少不稳定网络上玩家的随机超时。使用 TCPShield 时避免启用此功能，因为已知该功能会发生冲突。 |
🗺️ 区块、视距和世界加载
控制服务器在每个玩家周围加载和 tick 多少区块，以消除世界流式传输带来的卡顿。
| 文件 | 选项 | 推荐值 | 类型 | 备注 |
|---|---|---|---|---|
| server.properties | simulation-distance | 4 | 游戏 tick 半径 | 定义服务器在玩家周围主动 tick 方块和实体的距离。较低的值会大大降低 CPU 使用率，同时仍保持附近的农场和红石工作。 |
| server.properties | view-distance | 7 | 视觉半径 | 控制发送给客户端的区块数量。保持此值高于 simulation-distance，以便玩家可以看到更多内容，而无需服务器 tick 他们看到的所有内容。 |
| paper-world configuration | delay-chunk-unloads-by | 10s | 区块重用窗口 | 将最近访问的区块保持加载一小段时间，以避免玩家在同一区域来回移动时不断的加载/卸载循环。 |
| paper-world configuration | prevent-moving-into-unloaded-chunks | true | 反同步加载安全 | 防止玩家走进完全未加载的区块，否则会在主线程上触发昂贵的同步区块加载。 |
| paper-world configuration | entity-per-chunk-save-limit | 弹射物上限约 8–16 个 | 保存时间保护 | 防止大量箭、三叉戟或其他弹射物保存到单个区块并在加载时使服务器崩溃的极端情况。 |
🧟 生物上限、AI 和游戏体验
调整生物数量和 AI 范围，以便战斗和农场感觉良好，同时服务器在负载下保持响应。
| 文件 | 选项 | 推荐值 | 类型 | 备注 |
|---|---|---|---|---|
| bukkit.yml | spawn-limits | monsters: 20, animals: 5, water-animals: 2, ambient: 1 | 全局生物上限 | 将这些值乘以玩家数量即可得到允许的生物总数。较低的值会降低 CPU 压力，但也会减少生存世界中的环境生物。 |
| bukkit.yml | ticks-per.* | monster-spawns: 10, others: 400 | 生成频率 | 增加非必要生物生成尝试之间的间隔。怪物生成的频率可以略微降低而不影响农场，而环境和水生生物可以慢得多。 |
| spigot.yml | mob-spawn-range | 3 | 生成半径 | 减少用于生物生成的区块半径。保持此值等于或低于您的 simulation-distance，以便生物不会生成在它们会立即消失的地方。 |
| spigot.yml | entity-activation-range | animals: 16, monsters: 24, villagers: 16, misc: 8 | AI tick 距离 | 较低的值意味着远离玩家的生物实际上被冻结，从而节省 CPU。不要设置得太低，否则农场和村民机制可能会崩溃。 |
| spigot.yml | entity-tracking-range | players: 48, mobs: 48, misc: 32 | 可见距离 | 定义实体对玩家可见的距离。这通常应保持在激活范围之上，以便生物不会突然出现在近距离。 |
| spigot.yml | tick-inactive-villagers | false | 范围外村民 AI | 防止远离任何玩家的村民 tick，这可以显著降低大型交易厅的 CPU 使用率。 |
| spigot.yml | nerf-spawner-mobs | true | 农场安全 | 禁用来自刷怪笼的生物的 AI，以便大型刷怪塔设置不会使生物 AI 系统过载。 |
| paper-world configuration | despawn-ranges | 软: 30, 硬: 72 (大多数类别) | 生物清理距离 | 当生物远离任何玩家时，更积极地清理它们。硬范围应保持在 simulation-distance 乘以 16 个方块之上略微一点。 |
| paper-world configuration | per-player-mob-spawns | true | 公平生物分配 | 在玩家之间分配生物上限而不是全局分配，从而在繁忙的 SMP 服务器上为拥有农场的玩家提供更一致的游戏体验。 |
🛡️ 常见陷阱和最佳实践
在为长期社区和创作者项目构建无卡顿 Minecraft 服务器时，请避免这些常见错误。
跳过备份
将备份视为强制性的，而不是可选的。保留您的世界和插件数据的自动化异地副本，以便单次崩溃、文件系统问题或管理员错误永远不会抹去几个月的进度。
运行过时的软件
旧的服务器核心和插件缺少关键的性能补丁和安全修复。升级到受支持的版本，并尽可能避免依赖已废弃的插件。
在生产环境中停留在 Bukkit 或 Spigot
Bukkit 和 Spigot 实际上处于维护模式，缺乏现代优化。迁移到 Paper 或 Purpur 以受益于更好的区块加载、生物处理和性能改进。
在繁忙的服务器上使用低端共享主机
廉价的共享主机通常会超售 CPU 资源。您的服务器与同一台机器上的许多其他服务器竞争，因此性能会波动，并且在负载下几乎肯定会出现卡顿。
发送大量命令函数的繁重数据包
每 tick 运行命令的数据包随着玩家数量的增加而扩展性很差。首选插件或修改战利品表、生物群系或世界生成的更轻量级数据包，而不是运行不断的命令循环。
忽视硬件选择
Minecraft 服务器更关心强大的单核 CPU 性能和 SSD 存储，而不是原始 RAM 容量。在购买超出您实际需要的内存之前，请优先考虑高时钟速度的 CPU 和 SSD。
📈 如何使用此服务器优化指南
1
分析当前服务器状态
在有真实玩家在线的情况下运行您的服务器，并记录 TPS、MSPT 和卡顿投诉。确定您的瓶颈是 CPU、磁盘 I/O, 还是网络相关。
2
应用快速修复和基准
实施快速修复清单以及网络、区块和生物的基准设置。重启服务器并验证其是否干净启动且没有新错误。
3
使用真实玩家工作负载进行测试
邀请玩家回来，监控日志，并观察 TPS 在高峰活动期间的表现。根据您社区的实际游戏风格调整视距、生物上限和消失范围。
4
迭代并规划硬件升级
如果调优后性能仍然很差，请分析插件并考虑迁移到具有 SSD 存储的更强大的单核硬件，而不是简单地购买更多 RAM。