一、为啥FixedUpdate没按你设定的20ms准时调用？ #

其实你踩中了Unity帧循环机制的一个关键点：FixedUpdate不是真的每隔固定毫秒数就被"实时触发"的，它的调度是和主线程的帧周期绑定的。咱们拆解下你遇到的问题：

1. 主线程的优先级逻辑
   Unity的主线程要干的事儿太多了：处理Update、渲染画面、UI交互、物理准备... FixedUpdate是在主线程的"固定更新阶段"执行的，但这个阶段得等前面的任务做完才轮到。比如如果你的主线程一帧花了30ms（比如场景里模型多、渲染压力大），那FixedUpdate只能等这一帧的所有工作结束后才会被调用，这时候两次FixedUpdate的真实间隔就变成了30ms，而不是你设定的20ms。

2. Maximum Allowed Timestep的影响
   你把这个值改成和Fixed Timestep一样的0.02s，相当于告诉Unity："一帧里最多只能执行1次FixedUpdate"。如果主线程帧耗时超过20ms，Unity不会在这一帧里多执行几次FixedUpdate来补时间差，而是直接推迟到下一帧，所以你看到的日志就会稳定在30ms左右——这其实是主线程的真实帧耗时，不是FixedUpdate的设定间隔。

3. 你的Stopwatch测试测的是什么？
   你在FixedUpdate里打印sw.ElapsedMilliseconds再重启计时器，这个数值反映的是上一次FixedUpdate到这次FixedUpdate的真实时间差，而不是FixedUpdate的设定间隔。当主线程卡了，这个时间差自然会超过20ms，这很正常。

二、Time.fixedDeltaTime到底是啥？ #

很多人会误解它是"FixedUpdate的调用间隔"，其实它是Unity固定更新逻辑的"时间步长单位"，和真实调用时间没有直接关系：

• 不管主线程帧率有多波动，每次进入FixedUpdate时，Time.fixedDeltaTime都是你设定的那个值（比如0.02s）。
• 物理引擎、动画逻辑里的固定步长计算，都是基于这个值来的。比如你写rigidbody.MovePosition(transform.position + velocity * Time.fixedDeltaTime)，不管帧率是30还是60，物体的移动速度都是稳定的，不会因为帧慢就走得慢。

举个直观的例子：如果主线程一帧花了50ms，Fixed Timestep是20ms，Unity会在这一帧里连续执行2次FixedUpdate（20*2=40ms，剩下10ms留到下一帧补），每次FixedUpdate里的Time.fixedDeltaTime都是0.02s——这样物理逻辑是连续的，不会因为帧率波动出现跳帧或者慢动作。

三、如果真需要精准定时怎么办？ #

FixedUpdate的设计初衷是稳定物理和固定逻辑，不是做精准实时定时。如果你的需求是每隔20ms精准触发某个逻辑，有几个可行的方案：

• 用多线程单独处理：把定时逻辑放到子线程里，用System.Threading.Timer或者Task.Delay来实现精准定时。但要注意：Unity的大部分API（比如Debug.Log、修改Transform）不能在子线程调用，你需要用线程安全的队列把数据传到主线程再执行。
• 优化主线程负载：尽量减少主线程的耗时（比如简化渲染管线、减少Update里的冗余逻辑），让主线程的帧间隔尽量接近20ms，这样FixedUpdate的调用间隔自然会更接近设定值。
• 换用Update+时间差计算：在Update里记录Time.time，每次计算当前时间和上一次触发时间的差，当差值达到20ms时执行逻辑，然后更新触发时间。这种方式虽然也受帧率影响，但比FixedUpdate更灵活，适合非物理类的定时需求。

内容的提问来源于stack exchange，提问作者pookie