视距与模拟距离：最影响性能的两个开关

朋友说“你家服怎么这么卡”，你打开概览，TPS 掉到 14。你还没加插件、没装模组、世界也才刚开，唯一做过的事就是前几天把视距从 8 改成了 16，因为“看远一点舒服”。

在手机服上，这两个数字的性价比高得离谱：调到合适，省下的 CPU、内存和流量比大多数“优化插件”都多；调过头，你会先看到内存吃满、然后 TPS 一路往下掉。

整个调整只有两个数字要改，但它们一个管“你能看到什么”，一个管“服务器在算什么”。这一页把它们拆开讲：各管什么、手机服填多少、改完在哪里验证。

本页要点

视距 view-distance 管“看到多远”，模拟距离 simulation-distance 管“算多远”。
手机服的常用组合：视距 6～8、模拟距离 4～6。
视距加一格，服务端要负责的区块数按平方涨，内存、带宽、CPU 一起涨。
改完不重启等于没改：改完要停止再启动才生效。
想让跑图不卡，靠预生成，不是靠把视距压到 3。

视距管“看多远”，模拟距离管“算多远”#

视距（view-distance）决定服务端把多远的区块（chunk，世界被切成 16×16 格的方块柱，是加载和保存的基本单位）交给客户端。玩家能看多远、地形什么时候“长”出来，基本由它决定。

模拟距离（simulation-distance）决定服务端在多大半径内真正“跑”这个世界：实体移动、红石、水流、作物生长、刷怪、熔炉燃烧。超出这个半径的区块是静止的，即使客户端看得到。

打个比方：视距是舞台的幕布有多大，模拟距离是幕布里面有多少演员在动。幕布越大地基越贵，演员越多越耗电。

	视距 `view-distance`	模拟距离 `simulation-distance`
决定	客户端能看到多远的区块	服务端模拟多远的区块
主要消耗	内存、网络带宽、区块加载与卸载	CPU（每刻的计算量）
调大会怎样	玩家视野开阔，但内存和流量上涨	远处农场、红石、刷怪照常工作，但每刻更重
调小会怎样	远处地形看不到，走到边缘才“长”出来	远处区块静止：作物不长、红石停、刷怪塔停摆
想省什么就调它	省内存、省流量	省 CPU

在 Minexa 里改这两个数#

两个数都在 server.properties 里。Java 系（Paper、Purpur、Fabric、Forge 等）都有这两项；PowerNukkitX 用 pnx.yml，配置页里只有视距（默认 8），没有单独的模拟距离项。

改法有两条路，效果一样：

走配置页：服务器管理 →「服务器配置」→「基础配置」，找到「视距」和「模拟距离」，填数字，点底部「保存」。
走文件：文件 → 进入服务端目录 → 编辑 server.properties，写入下面两行。
重启服务端：先点「停止」，等进程真的退出，再点「启动」。应用没有独立的重启按钮。

server.propertiesserver.properties

# 只改这两行，其它行不要动
view-distance=8
simulation-distance=6

两个范围写在配置页的说明里：3～32。但数字输入框只过滤非数字字符，不做范围校验，你填 0 或 64 不会当场被拦下，出问题只会体现在启动日志和服务端行为里。别试。

改完必须重启才生效。运行中保存时，应用会提示“部分属性需重启服务器才生效”；PowerNukkitX 更严格，服务端运行时直接拒绝写入配置。判断有没有生效，最直接的办法是重启后进游戏，看远处地形的加载边界有没有变化。

在 Minexa 里改配置是“保真保存”

配置页保存时以磁盘文件为基准逐条更新，注释、空行、你没碰过的键都会原样保留，不会把整个文件重写成默认值。所以走配置页改这两个数，比自己手改文件更安全一点。逐项说明见 server.properties 基础项详解。

推荐值：手机服 6～8 和 4～6#

下面是经验值，不是硬性限制。前提是原版或 Paper 系 + 少量插件，基岩核心按人数减一档看。

手机内存	建议人数	`view-distance`	`simulation-distance`
3 GB	1～2 人	6	4～5
4 GB	2～3 人	6～8	6
6 GB	3～5 人	8	6～8
8 GB	5～10 人	8～10	8
12 GB 以上	10 人以上	10	8～10

一条常用的经验规则：模拟距离别大于视距。玩家看不到的地方你还在算，纯属浪费；而模拟距离比视距小是完全可以的，代价是远处区块“看得到但不动”。

只想省 CPU，就先降模拟距离；想省内存和流量，就先降视距。两个都要降时，一次降一格，别一步从 12 跳到 6 —— 那样你不知道是哪一格救回来的，也没法判断能不能再降。

为什么降一格这么有效#

区块数量是按平方涨的，不是按倍数。视距为 d 时，服务端要负责的范围大约是 (2d+1)² 个区块：

视距	范围内区块数（约）
4	81
6	169
8	289
10	441
12	625
16	1089
32	4225

从 8 提到 10，区块数多了约 53%；从 8 提到 16，是 3.8 倍；填 32 就是 14 倍多。这个数字一变，下面四样同时变：

内存：每个加载中的区块都要在内存里留一份地形、光照和实体数据，区块越多，堆压力越大，GC 也越频繁。
CPU：模拟距离内的区块每刻都要走一遍 tick，方块更新、实体寻路、作物生长都算在里面。
区块生成：新扩出来的那圈区块磁盘上没有，玩家走过去就得现场生成，单刻耗时会突然尖起来。
带宽：视距变大，发给每个客户端的区块数据包也变多，同 Wi-Fi 下还能撑，公网隧道下会先卡在网络上。

所以“视距从 8 改成 10，感觉也没什么变化”很正常：视觉收益很小，成本却实打实地上去了。这也是为什么优化清单里它排在前面 —— 改一个数字，立刻见效，还能随时改回来。

降过头的代价#

别为了 TPS 把视距压到 3、4，玩家体验会崩：

看不到远处的东西：山、建筑、队友都看不见，走到哪儿地形才“长”到哪儿。
远处一切静止：模拟距离外的作物不长、水流不走、红石不动，刷怪塔和自动农场直接停摆。
怪物只在近处刷：模拟距离太小，玩家会觉得“野外一只怪都没有”，但一进洞穴就被围。
跑图更容易迷路，多人一起玩时体验尤其差。

一般玩家的接受底线是视距 6、模拟距离 4～6。低于这个数，不如直接减一个人，因为省下来的性能还没流失的玩家值钱。

别照抄网上教程里的 16 和 32

那些数字是给 16 GB 内存的 PC 服写的。手机填 16，区块数直接翻到 1089，内存和 CPU 都顶不住；填 32 更加没有意义 —— 手机屏幕就那么大，客户端根本画不出那么多。

如果你已经改成了 16 以上，先改回 8，重启，再看概览的内存条和 TPS。参考 TPS 与 MSPT 判断改完到底有没有变好。

玩家自己调低渲染距离有用吗#

游戏设置里的“渲染距离”是客户端的，只管他自己手机上画多少个区块。

他调低，他自己手机更省电、更流畅，流量也少一点。
但服务端该 tick 的区块，是按服务端的 simulation-distance 在跑的，不会因为他调小而少算。
所以“让所有人都把渲染距离调到 4”不能解决服务端卡，只能解决他们自己卡。

一句话记住：玩家调低渲染距离只救他自己的手机。要省服务端的资源，只能改服务端自己的两个数。

改完以后看什么#

改完不要就此结束，按这个顺序验证：

看概览的 TPS：玩一局（至少十几分钟，包含跑图），TPS 是否稳定在 18 以上。数字读法见 TPS 与 MSPT。
看内存条：长期贴着上限，说明视距还是偏大，或者该调内存了，见内存分配。
问玩家感受：远处地形“长”出来的速度、怪物和农场是否正常。模拟距离降太多，最先抱怨的往往是农场主。
配合预生成：视距降下来以后，玩家跑图时依然会触发区块生成。预生成能把这部分卡顿提前做掉：先用 Chunky 一类的工具把常用区域生成好，跑图时服务端只读磁盘、不现算。工具要自己装，代价是时间和存储，做法见综合优化。

如果降了视距 TPS 还是低，说明瓶颈不在区块，而在实体、插件或发热降频 —— 那就该换方向查了，见内存不足与 CPU 占用。

上机自查

server.properties 里 view-distance 和 simulation-distance 是你填的数字。
改完之后确实停止过、再启动过，不是只点了保存。
进游戏跑到出生点边缘，能看到地形加载边界比之前近了。
玩一局跑图，概览 TPS 稳定在 18 以上或比改之前明显回升。
模拟距离没有小于 4，农场的作物和红石还在正常跑。

下一步#

数字看不懂：先读 TPS 与 MSPT
内存怎么配合着给：内存分配
一张按收益排序的清单：综合优化