实体与碰撞

本章命题：方块与实体的成本结构根本不同——方块是静态数据（存一次、读千次、只有变化才花计算），实体是持续计算（每刻每只都要决策、移动、碰撞查询）；因此实体的数量直接消耗 20 TPS 预算，是服务器性能的第一税种。若几万实体的服务器与几百方块的服务器性能相当，本命题就是错的。

1问题

一台服务器可以轻松背着几千万个方块运行：整个主世界的数据躺在硬盘里，内存里活跃的那部分也安静得像空气。可当几千只鸡被集中到一起时——比如某个玩家的「养鸡场」——服务器的 CPU 开始冒烟，全世界一起掉 TPS。

几千万对几千，重量级输给了轻量级。要解释这个倒挂，得回到卷三反复出现的那份预算表（第 5 章）：每刻五十毫秒里，世界要对「活着的一切」各办一轮事。方块是死数据，不用办事；实体是活物，每刻每只都要「想」（AI 决策）、「动」（物理位移）、「撞」（碰撞查询），还要把自己的状态同步给每个看得见它的客户端。本章从成本结构讲到三类对象的分野，再到 AI 的账单与农场的崩溃——「实体才是税」这个导读里抛出的论断，在此兑现。

2方块便宜，实体贵：两种成本结构

方块的成本模型在第 1 章和第 4 章已经拼齐：它是一格一格的静态数据，存在调色板里，安静、压缩、只有被改动时才触发一次更新。一块石头每天的工作量是零——存着就行。

实体的成本模型是另一个物种。一只鸡哪怕站着发呆，服务端每刻也要为它办三件事。想：跑一遍 AI 决策——现在该干什么？继续游荡还是找吃的？这个决策本身是查表比优先级，但背后还有冷却计时、目标有效性检查。动：跑一遍物理——重力拉它向下，位移要拆步长防穿墙，每一步位移都要做碰撞查询（这一步会碰到世界数据与别的实体）。说：把自己的位置、朝向、动画状态打包进发往客户端的同步包——凡是被任何玩家看见的实体，每刻都在「上镜」。

三件事乘上实体数，就是实体的刻成本。关键的不对称在这里：**方块的增长是存储问题（买硬盘能解决），实体的增长是计算问题（每刻都要还）。**存储能压缩、能卸载到硬盘、能假装不存在；计算每刻都要重新发生，压不掉、卸不掉、装看不见就要掉 TPS。这就是「税」的完整含义：实体的成本是按刻重复征收的活期债，方块的成本是一次性的固定资产。

3三类对象：实体、方块实体、展示实体

「会动的」和「带数据的」在这个引擎里其实分了三个户口。

实体是一切「在世界里有连续位置、会自己动」的东西：生物、玩家、掉落物、箭、矿车、船、盔甲架。它们活在方块网格之上，按刻结算，是税单的主体。特别值得点名的是掉落物——地上没被捡起来的每件物品都是一只实体，会飞会转会合并会消失。新手玩家不知道这条，于是一场大型活动之后，满地未拾取的战利品悄悄变成几千只实体——这是无数服务器「莫名其妙变卡」的第一大原因。

**方块实体（block entity）**是「住在方块里但带私有数据的」那类：箱子记得自己装了什么，熔炉记得烧到第几秒，告示牌记得写的字。它们不动、不占实体税，但每只都要为自己的一份数据开一个对象、参与刻级别的处理（熔炉在烧的时候要逐刻结算进度）。一屋子容器的基地、几千箱子的仓储大楼，交的是另一种税——数据对象的固定税，比实体轻，但不为零。

展示实体是 1.19.4 官方新增的第三类¹：专门给地图作者用的「只显示、不活动」的轻量对象——放一个模型、一块文字、一个物品展示在空中，它不跑 AI、不做物理，成本远低于一只真实体。它的出现是一次教科书级的架构回应：地图作者此前为了「放个装饰」大量养着盔甲架（真实体、交全税），官方看清了这笔冤枉账，为「纯展示」这个需求单开了一个低税户口。卷二第 15 章的「增加动词」原则在架构层的对应物：给需求的正确粒度开正确的成本户口。

4碰撞与特例物理

实体的「动」之所以贵，贵在碰撞。Minecraft 的碰撞模型是全书见过最朴素的：所有实体的碰撞箱都是轴对齐包围盒（AABB）——不带旋转的长方体。没有胶囊体、没有精确网格，一只马的碰撞箱就是一只横过来的盒子。

朴素归朴素，工程并不省。步进位移是防穿墙的关键技巧：一个快速移动的实体一帧可能跨出一格多，直接挪位置就会穿过薄墙——引擎把每帧的位移拆成若干小步，每小步做一次碰撞查询，出撞即停并修正位置。一次移动 = 多次查询；查询的对象既是世界方块（查格子），又是其他实体（查邻域，通常用空间分桶优化——只查同一格附近的实体，不查全世界）。

特例物理也欠着几笔有名的历史账。船与矿车是最出名的两位：它们的移动逻辑是手写的特例而非通用物理——矿车的轨道贴合、船的水面行为，各自带有一套多年打磨（也多年被吐槽）的私有规则，幽灵碰撞、急转漂移这些社区老梗都从这里来。骑乘是另一处特例：骑上马的玩家不再是独立移动的实体，而是「挂载」在马身上的附属——位置每刻从坐骑推导。这些特例说明同一件事：通用物理引擎里总有几类对象，为了手感或历史兼容被单独开灶——每口灶都是额外的维护税，而玩家和它们已经处出了感情，拆不掉。

5AI：目标、寻路、村民的日程

实体税单里涨得最快的一项是 AI。它的结构是三层漏斗。

目标选择是最上层：每只生物维护一张「想做的事」清单（游荡、追击、逃跑、吃东西、交配），按优先级与冷却轮询——当前目标无效或更高优先级的目标出现，就切换。这一层的单次成本不高，但它每刻每只都要跑。

寻路是中间层、也是大头：生物决定「走到那里」后，要在方块网格上找一条能走的路——本质是 A* 风格的网格搜索，还要考虑跳跃、避崖、开门。寻路贵到引擎必须节流：重算路径的频率被压低、路径被缓存、远距离目标干脆降级成「大概方向」。一只追你的僵尸，背后是每秒若干次的网格搜索——一群僵尸围城，就是一场寻路风暴。

日程是村民专属的顶层（1.14 村庄重写的产物）：每天按时刻表上班、闲逛、回家睡觉，工作点与床位各有所属。村民是全游戏最复杂的民用 AI——也是玩家工业化改造最深的对象（卷二第 10 章的交易大厅），一头是全游戏最贵的民用日程系统，一头是玩家把它压榨成印钞机，村民的两面在账本上恰好对齐。

AI 层还有一个常被忽视的税基：没被玩家看见的实体也在想。模拟距离内的所有生物，无论你在不在看，都照常决策——「少放点生物」因此成了服务器经济的常识，下一节看玩家怎么跟这笔税打交道。

实体税还有一个网络维度的副本。服务端算完一轮，还要把结果「说」出去：每个实体要出现在多少个客户端的屏幕上，就要向多少个客户端各发一份同步包——十个人围观一场百人对战，实体同步的开销就是「实体数 × 观众数」的乘积。这只网络税解释了两条服务器常识：其一，大型活动（婚礼、比赛、爆炸现场）比大型工厂更容易卡——工厂重的是服务端计算税，人群聚集重的是网络分发税；其二，「看不见就不发」是引擎内置的节流（视野外的实体不推送），它顺便成了反透视（外挂）的第一道墙——藏在墙后的东西，你的客户端根本没收到。一笔税，两用。

6农场与崩溃：玩家与税表的博弈

玩家与实体税的关系是一部博弈史，双方都有杰作。

玩家的杰作是农场：刷怪塔控制生成与处决的节奏，养鸡场管理繁殖与收集的批量，掉落物用漏斗与水流即时归仓——设计良好的农场本质上是一门税务优化学：把「实体存在的时间」压到最短（生成即处决、掉落即收纳），让同一份产出占用最少的「实体·刻」。懂行的玩家建农场先问「实体停留几秒」，就像工程师先问内存占用。

玩家的另一种杰作叫崩溃：批量繁殖失控的鸡场、堆积如山未拾取的掉落物、横跨数千格的矿车网络（每节矿车都是实体）——经典的三位一体，把一台服务器拖进 TPS 深渊。服务器的治理回应在第 5 章的立法框架里：实体上限、掉落物定时清理、矿区生物上限——插件立法把「实体预算」写进了服务器宪法。

官方自己也有一套内置的减税设计，散落在各处而少被当成一个整体看：掉落物之间会自动合并（地上两堆同款木头很快并成一堆，实体数立刻减半）；掉落物有五分钟的寿命（第 3 章讲过，跑尸倒计时的另一面就是税务追缴）；生物生成有上限与密度规则（一个区域塞满了就不再生）；加上展示实体新开的轻量户口——这些机制单看是玩法细节，合起来读，是一份写在引擎里的税务优惠政策：官方一直在用「合并、限期、限额、分类」四种手段给实体税减负。玩家的清理插件不过是把同一套思路做成了可配置的行政版本。

官方的回应则是架构级的，除展示实体外还有一记釜底抽薪：把静态的东西从实体户口里迁出去。能不动的尽量别动——这类「给需求的正确粒度开正确户口」的调整每做一次，税基就薄一层。回头看「实体才是税」的完整表述：税是引擎对「活性」的计价——想、动、撞、说，每一样都按刻收费；这个游戏的经济史（玩家的农场、服主的宪法、官方的迁户），全是围绕这张税表展开的。

7这一章留下什么

• 爱好者：你的养鸡场在服务器账单上是大客户——把掉落物及时收进箱子，是你为全服 TPS 做的最实际的贡献。
• 开发者：能抄走的是成本结构的二分法——静态数据按存储计价、动态实体按刻计税，设计对象时先问「它需要活性吗」，为纯展示类需求开轻量户口（展示实体是范本）。抄不走的是税表文化：玩家能把性能预算玩成一门产业（农场优化学），前提是这个社区有十五年「抠每一刻」的传统——优化意识是社区资产，不是代码资产。

注释

1. Minecraft Wiki，《Display》（1.19.4 加入的展示实体：block display、item display、text display，供地图作者以低开销展示静态内容），minecraft.wiki，检索于 2026-09-18；见 https://minecraft.wiki/w/Display ↩