写这篇之前先说清楚一件事：TickRate 从来不是越高越好，它是一个成本换体验的生意。真正难的不是把数字调到 128，而是在 128 这个预算下，把一整帧的活儿干完还不掉链子。下面聊的东西大多来自 Source 引擎、Valorant、Overwatch 这些公开分享过架构的项目，以及自己踩过的坑。先算一笔账128Hz 意味着每帧 7.8 毫秒。听起来还行，但你把一帧要干的事列出来就慌了：收所有人的输入、跑移动、做碰撞、判命中、结算伤害、给每个玩家算他能看见谁、把状态打包发出去。这些全塞进 7.8 毫秒，而且是每秒 128 次，一次都不能超。超了会怎样？tick 开始堆积。这一帧没跑完，下一帧的输入已经在排队了，服务器时间开始落后真实时间，所有人一起卡。这跟客户端掉帧不一样，客户端掉帧是你自己难受，服务器一慢是全场遭殃。所以整个架构的核心目标就一句话：让最坏情况下的单帧耗时也稳稳待在预算里。注意是最坏情况，不是平均。平均 3 毫秒但偶尔飙到 12 毫秒的服务器，比稳定 6 毫秒的服务器体验差得多。玩家感知的是抖动，不是均值。帧循环：别让它可变服务器主循环必须是固定步长的。原因不是性能，是确定性。移动和物理一旦用了可变步长（这一帧模拟 6ms、下一帧模拟 9ms），同样的输入在不同负载下会算出不同结果。对 FPS 来说这是灾难——回放对不上、反作弊对不上、命中判定对不上。Source 引擎从一开始就是固定 tick，Valorant 也是。