状态机绝对执行顺序：Enter/Update/Exit 到底谁先谁后

做状态机最容易被问倒的问题，不是状态怎么设计，而是 Enter / Update / Exit 到底谁先谁后。这个顺序听起来像是入门常识，但真要在业务代码里排查，很多写了两年状态的开发者都说不准。我第一次被这个问题卡住，是在一个动作游戏的角色控制模块里：角色从站立切到跑步时，跳跃和攻击输入全部丢失，查了一晚上才发现是切换时机和我想的完全不一样——那一帧内，新状态的 Enter 和旧状态的 Update 挤在了一起，数据读写顺序全乱了。

这篇就把状态机的绝对执行顺序模型讲透，先拆三个方法各自负责什么，再一步步还原一次切换里的真正调用顺序，最后给出可复现的日志验证方法。适合正在用 Unity 写角色控制、敌人 AI、UI 流程状态机的开发者，也适合第一次接触状态机、想知道这三个方法为什么不能乱写的入门者。这里的“绝对执行顺序”不是玄学，而是：只要你的框架代码是确定的，顺序就能百分之百复现，问题只在于你有没有把它理清。

1. 状态机生命周期背后的设计逻辑

1.1 Enter 不是开关，而是进场

Enter 是一个状态的“进场动作”，它在状态开始存活之前执行一次。很多人刚写状态机时容易犯一个错误：把 Enter 当成“打开状态”的开关，在 Update 里不停判断“我是不是这个状态”，然后如果满足条件就做初始化。这样的结果就是初始化逻辑被重复执行，状态内部数据永远不稳定。

Enter 应该是这样的职责：进入状态时把前提条件准备好。比如切到攻击状态，需要把连击数清零、锁定移动速度、播放入场动画。这些动作只做一次，做完之后，后续的 Update 才能安全地依赖这些数据。用办公室的类比来说：Enter 是进会议室时签到，签一次就够了，不是每坐一分钟签一次。

1.2 Update 是状态存活时的持续表达

Update 负责状态在存活期间的“持续表达”：角色跑步时的位移、敌人巡逻时的路径检测、UI 面板停留时的输入监听，都在这里做。它和执行顺序的纠葛最少，但它不能也不应该承担初始化工作。

如果你把一个变量初始化放在 Update 里，比如“每次 Update 都重置攻击连击数”，那连击系统就永远无法累加数值。这种问题在状态机里非常常见，根因不是逻辑复杂度，而是没有把 Enter 和 Update 的职责边界切开。Update 里只写“基于当前状态的数据持续产出行为”，不写“把状态变成什么样”的初始化代码，这是一个非常实用且能长期遵守的原则。

1.3 Exit 是收尾工作，不是清理对象

Exit 在状态离开前执行，是收尾，不是销毁。它负责把状态运行期间产生的副作用还原干净：停止协程、恢复移动速度、关闭特效、取消临时监听的输入事件。

我见过不少新手写 Exit 时只打一行日志，然后什么都不断言。结果就是：跑完多个状态之后，角色速度越来越快、攻击特效残留、协程叠了几个副本在同时跑。Exit 必须能把这些“现场”恢复原状，它承担的是状态结束后不污染下一个状态的责任。但不是让你在 Exit 里做切换逻辑，那是另一层的事，后面我会专门说这个坑。

1.4 顺序为什么一定得是 Enter 到 Update 到 Exit

从语义上讲，一个完整状态的生命周期必然是先进入、再持续更新、最后退出。你不可能先让一个状态跑 Update 再让它 Enter，也不可能让一个已经 Exit 的状态继续执行 Update。这个顺序不是某个框架拍脑袋定的，而是“生命周期”这个概念的必然结果。

但这里有个关键认知：Unity 本身不认识你的 Enter / Update / Exit，这些方法是你自己写的状态机代码在调用，所以顺序不是 Unity 内置行为，而是你框架代码里的调用顺序决定的。换句话说，谁先谁后，完全取决于你写那一行 ChangeState 时把 ExitState 和 EnterState 放在什么位置。这个认知是整个“绝对执行顺序模型”的地基——先看懂你自己的代码，再去套任何现成的顺序结论。

2. 一次状态切换的完整时间线

2.1 最常见的 Update 里调 ChangeState

绝大多数项目一开始都会写成枚举加上 switch 的形态，代码大概是这个样子：

// 一套最常见的FSM管理代码 public enum StateId { Idle, Run, Jump, Attack } public class SimpleFSM : MonoBehaviour { public StateId currentState = StateId.Idle; void Start() { EnterState(currentState); } void Update() { switch (currentState) { case StateId.Idle: UpdateIdle(); break; case StateId.Run: UpdateRun(); break; case StateId.Jump: UpdateJump(); break; case StateId.Attack: UpdateAttack(); break; } } public void ChangeState(StateId next) { if (next == currentState) return; ExitState(currentState); EnterState(next); currentState = next; } void EnterState(StateId s) { Debug.Log($"Enter {s} Frame {Time.frameCount}"); } void ExitState(StateId s) { Debug.Log($"Exit {s} Frame {Time.frameCount}"); } }

假设角色当前是 Idle，Update 里检测到“按下跑步键”，然后调用 ChangeState(StateId.Run)。这一帧发生的是：

1. 本帧 Update 开始，进入 switch，执行 UpdateIdle。
2. UpdateIdle 里检测到输入，调用 ChangeState。
3. ChangeState 内部先执行 ExitState(Idle)。
4. 再执行 EnterState(Run)。
5. 把 currentState 改为 Run。
6. 返回 switch，switch 已经执行完当前分支，本帧不会再执行 UpdateRun。
7. 下一帧 Update 再进来，才执行 UpdateRun。

所以在这个写法下，同一帧内旧状态执行了 Update 和 Exit，新状态只执行了 Enter。新状态的第一次 Update 发生在下一帧。这个顺序是最常规的，绝大多数项目都应该保持它。

2.2 同一个状态会不会在同一帧内 Enter 和 Update 都执行

会，而且很容易发生。关键在于你的框架是否在 ChangeState 执行完毕之后，再去调用一次当前状态的 Update。

假设你用的是另一种写法：

// 让状态本身管理自己的更新 private StateBase _current; void Update() { TryChangeByInput(); // 可能触发切换 _current?.ExecuteUpdate(); // 切换完成后立刻执行新状态的Update }

这种情况下，如果 TryChangeByInput 里调用了 ChangeState，那么 ChangeState 内部执行完旧状态的 Exit 和新状态的 Enter 之后，_current 已经指向新状态。紧跟着的_current.ExecuteUpdate()就会立刻执行新状态的 Update。

于是这一帧的调用顺序变成了：

• 旧状态 Update（如果有）
• 旧状态 Exit
• 新状态 Enter
• 新状态 Update（同一帧）
• 下一帧又执行新状态 Update

这个顺序本身不一定是 bug，它可能影响的是数值累积逻辑：攻击连击如果每一帧都加一次，新状态同一帧进一次 Update，很可能让你连击数比预期多一跳。真正的风险在于，你的处理逻辑默认了“切换后下一帧才跑新状态”，而框架实际却是“切换后当帧就跑新状态”，两种认知一冲突，状态内部的数据就全对不上了。

2.3 时序快照对照表

为了把两种写法的差异说得更清楚，我把它们放到同一张表里对比：

这张表值得贴在项目文档里。它的价值在于：顺序本身没有绝对对错，但你项目里只能存在一种约定。如果 A 处写的是“切换后下一帧生效”，B 处框架却是“切换后立刻更新”，那么状态机在不同模块里表现就会不一致，排查时让人非常崩溃。

2.4 从 Start 阶段启动的顺序

还有一个很多人忽略的边界场景：游戏启动时，从 Start 里第一次调用 ChangeState。

这时没有前一个状态，所以 Exit 必须被跳过，直接执行新状态 Enter。随后第一帧 Update 才执行状态的 Update。如果启动阶段连续调用了两次 ChangeState，第二个进入的状态可能只执行了 Enter 而没有执行过任何一次 Update，然后就被切换出去了。这种情况我称为“状态闪了一下”，动画没有播、数据没有累积，唯一留下的痕迹是日志里多了一行 Enter 和一行 Exit。

在写框架的时候，要明确处理 Start 阶段的切换语义：如果当前状态为空，就不要调用 Exit。更稳妥的做法是只允许通过独立的 Initialize 方法设置初始状态，而 ChangeState 只负责“从旧状态切到新状态”。

3. 三种常见状态机写法，以及如何保证顺序

3.1 枚举加 switch：最直接但容易漏掉 Exit

前面示例里的枚举加 switch 是最容易上手的状态机，也是顺序最暴露在外面的写法。因为每一处 ChangeState 调用都必须手动处理 Exit 和 Enter，任何一个调用点忘记了 Exit，旧状态就不会被收尾。

这种写法的顺序问题不是框架帮你避免的，而是靠程序员自律。项目小还好，一旦状态超过十个，switch 分支会迅速膨胀，同时所有切换散落在各个方法里，你很难从全局角度判断某个状态到底有没有正确退出。我的态度是：小型 Demo 和学习项目用它可以，正式游戏角色控制这样写，后面维护成本会很高。

3.2 每个状态一个类：生命周期方法天然绑定在对象上

当状态量变大、或者状态之间需要共享复杂数据时，更合适的做法是把状态封装成类，让 Enter / Update / Exit 成为这个类自己的方法。框架只负责调用，不用每处都写一遍。

public abstract class StateBase { public virtual void Enter() {} public virtual void Update() {} public virtual void Exit() {} } public class FiniteStateMachine { private StateBase _current; public void ChangeState(StateBase next) { // 顺序铁律：先退出旧状态，再进入新状态 _current?.Exit(); next.Enter(); _current = next; } public void Update() { _current?.Update(); } }

这个写法的最大优势在于，Exit 和 Enter 被固定在 ChangeState 内部，不会因为某个调用点漏写而破坏顺序。同时每个状态的逻辑内聚在一个类里，不会出现“Idle 的切换代码跑到 Run 分支里”的混乱局面。

这种框架下，同一帧切换后的行为完全由外部 Update 决定：如果在 Update 里调 ChangeState，然后紧接着调_fsm.Update()，那和 2.2 节一样，新状态会在同一帧内 Enter 加 Update。如果只在下一帧再调用 Update，顺序就是标准的“先 Enter，下一帧 Update”。

3.3 状态栈：Enter 和 Exit 会变成 Pause 和 Resume

有些项目用到状态栈（State Stack），常见于弹窗管理、暂停菜单、复杂 UI 流程。状态栈和普通 FSM 的顺序模型不一样：当一个新状态压入栈顶时，旧状态并不是 Exit，而是 Pause；被弹回栈顶时，也不是 Enter，而是 Resume。

这样做的好处是，旧状态的数据状态可以被完整保留，不需要在 Pause 时销毁、Resume 时重新初始化。代价是状态生命周期从三个方法变成五个方法：Enter、Update、Exit、Pause、Resume，顺序模型更加复杂：新状态压栈的顺序是 旧状态 Pause → 新状态 Enter → 新状态 Update；弹出栈的顺序是新状态 Exit → 旧状态 Resume → 旧状态 Update。

如果你只是要做角色控制，不建议用状态栈，普通 FSM 更清晰。但如果做 UI 流程，状态栈确实比普通 FSM 好维护得多，因为它天然支持“叠层级”的状态管理。

3.4 选型建议：顺序可解释性优先

我自己现在的选型标准很简单：任何状态机方案，都必须能回答“一次切换过程中，三个方法各在哪一帧跑了多少次”这个问题。枚举加 switch 能回答，但回答成本高；类状态机把顺序收拢到 ChangeState 一处，回答成本低；商业状态机插件也能回答，但需要你先去翻源码确认。

所以我的建议是：中小型项目直接写类状态机，不要用枚举加 switch 硬撑；项目大到需要可视化编辑器时，再引入插件，但预备阶段仍然先用代码把顺序模型验证一遍。状态机顺序这种事，靠插件封装反而更容易变成黑盒，出了问题更难查。

4. 更新循环接入点差异：不只在 Update 里跑

4.1 MonoBehaviour.Update 驱动

最常见的驱动方式是在 MonoBehaviour 的 Update 里调用状态机的 Update。这也是前面所有示例的默认形态。它的特点是与渲染帧率同步，每渲染一帧，状态机就更新一次，角色控制、动画表现、输入响应都能保持一致。

在 Update 驱动的场景下，所有状态机顺序和 2.3 节的时序快照完全一致。问题点往往不在顺序本身，而在你处理输入时放在了哪一步：是先检测输入再更新状态，还是先更新状态再检测输入。先检测输入，这一帧的输入可以立刻影响状态行为；先更新状态，输入就要等下一帧才能生效。这种微小的时序差异，会让手感产生可感知的变化，尤其是帧率不稳定的移动端。

4.2 FixedUpdate 驱动的坑

FixedUpdate 的调用频率由物理系统固定，不受渲染帧率影响。如果你把状态机的 Update 放在 FixedUpdate 里，表面上看更稳定，但实际上会带来两个问题。

第一个问题：状态切换的响应速度变得不可控。假设玩家在 60 帧下按下攻击键，FixedUpdate 可能在 0.3 帧后才执行，输入到表现之间多了一次不确定的延迟。第二个问题：物理步长和渲染帧率不是整倍数关系时，角色会感觉轻微卡顿或抖动。用 FixedUpdate 驱动状态机，本质上是在用物理循环去驱动表现层逻辑，这两件事的节奏不同频。

正确的分工应该是：物理相关参数（移动、受力）在 FixedUpdate 里处理，状态机本身用 Update 驱动，状态机 Update 只是下发“当前状态的指令”，FixedUpdate 根据这个指令去计算物理量。这样状态切换的响应速度不会受物理步长拖累，物理表现又依然稳定。

4.3 协程驱动的时序偏移

协程也能驱动状态机，而且能精确控制它在主循环的哪个阶段执行，这会让顺序模型发生偏移。

// 用协程驱动状态机时，更新时机会随 yield 类型变化 IEnumerator MachineLoop() { while (enabled) { _current?.Update(); yield return null; // 在下一帧 Update 之后恢复 // 如果改成 yield return new WaitForEndOfFrame(); // 状态机就会在 LateUpdate 之后再更新 } }

关键区别在于：yield return null会让协程在本帧所有 MonoBehaviour.Update 之后继续执行，也就是说你状态机的 Update 会排在绝大部分脚本之后。如果你依赖另一个脚本在 Update 里先写入数据，状态机再读取，那用协程反而更合适；但如果你期望状态机和动画在同一帧同步响应，这种时序偏移就可能造成表现错位。

协程驱动本身不是问题，问题是必须明确它把状态机更新放到了主循环的哪个阶段。放错阶段，顺序模型不会崩，但会变成另一种你未必预期的顺序。

4.4 动画事件驱动：不建议用

还有一种做法是用 Animator 的动画事件去触发 Enter 和 Exit，比如 Animation Event 在动画播完时调用状态机的 ChangeState。这个方案听上去很“自然”，但实际操作中非常脆弱：动画事件是挂在具体 Clip 上的，如果动画被取消、过渡被跳过、Blend Tree 切换回调没触发，状态机就会卡在某个状态里等不到事件。

我踩过这个坑后得出的结论是：动画事件只适合做表现层的提示，比如“这一步播放音效”“这一步生成打击特效”，不适合做状态切换的核心驱动。状态机的切换应该由输入、AI、逻辑条件驱动，动画层只是“跟随”状态机的表现，两者保持单向依赖最好。

5. Animator 状态机回调顺序与代码状态机对照

5.1 Animator 自己的 Enter / Update / Exit

Unity 的 Animator 本身也有一套状态机，通过 StateMachineBehaviour 提供回调：OnStateEnter、OnStateUpdate、OnStateExit。很多开发者会混淆这套回调和代码状态机的 Enter / Update / Exit，以为它们完全等价。

实际上它们有本质区别：Animator 的状态切换由动画过渡系统控制，回调发生在 Animator 的评估过程中，而评估时机受 Animator 更新模式（Normal 是 Update 阶段、Animate Physics 是 FixedUpdate 阶段）影响。代码状态机的顺序是你自己代码调用的，Animator 状态机的顺序是引擎内部调度的，两者天然不在同一个时间线上。

5.2 交叉过渡会让顺序变成并行

代码状态机的 Enter 和 Exit 是串行的：旧状态 Exit 执行完，新状态 Enter 才开始，两个状态的生命周期在时间上不重叠。但 Animator 状态机在带 Transition Duration 的交叉过渡阶段，新旧状态是并行的：新状态的 OnStateEnter 可能已经触发，旧状态的 OnStateUpdate 还在继续执行，同时两个状态的动画混合在一起。

这个差异在处理动作游戏时非常关键。比如角色从攻击过渡到移动，如果过渡时长是 0.2 秒，那么在这 0.2 秒内，你在 Animator 里同时看到攻击状态和移动状态的回调在跑；而你的代码状态机如果已经切到了 Move 状态，它会认为攻击已经完全结束。表现层和逻辑层在这个窗口期内信息是不一致的。

解决思路是：让代码状态机只关心“逻辑上我处于哪个状态”，而动画表现完全交给 Animator 的过渡系统。不要在代码状态机里去读 Animator 的 IsInTransition 来判断逻辑，更不要期望 Animator 切换和代码状态切换在同一帧完成。

5.3 两者一起用的推荐形态

我目前比较稳的组合方式是：代码状态机作为唯一的事实来源，Animator 作为表现层。代码状态机进入 Run 状态时，设置 Animator 的 bool 或 Trigger；Animator 的交叉过渡由动画师调好的参数控制，代码状态机不去干预。代码状态机需要知道动画播放进度时，只读取当前动画的 normalizedTime，并且明确接受交叉过渡期间数据不完全准确这个事实。

这样做的好处是，逻辑层的 Enter / Update / Exit 顺序始终干净、串行、可控，而动画层的并行混合由引擎负责。两层各管各的时序，不会因为动画过渡的交叉，把逻辑状态的顺序也搅乱。

6. 踩坑实录：顺序错乱导致的三类事故

6.1 在 Enter 里访问还没初始化的变量

有一次我在一个技能状态里写：Enter 时读取武器伤害值，赋值给伤害数字。但武器对象是上一个状态 Exit 时才释放的，释放顺序其实没问题，因为 Exit 在 Enter 之前执行。问题出在另一个地方：我在 Awake 阶段初始化了状态机，导致第一个状态的 Exit 被跳过，而某个武器引用还没有来得及设置，Enter 里一读就空引用。

这个坑的本质是：顺序模型只在“框架内部调用顺序”上可靠，但“业务数据初始化顺序”并不会自动和状态生命周期对齐。你需要自己保证：Enter 执行时，它依赖的所有外部数据已经就绪，而不是把数据初始化委托给上一个状态的 Exit。

我的处置办法是：在进入任何状态之前，统一走一个 PrepareState 流程，把状态需要的数据先检查一遍，缺失就立刻补上默认值，而不是直接在 Enter 里裸访问。这样出问题时会提前暴露，并且日志能明确告诉你缺的是什么。

6.2 在 Exit 里再次调用 ChangeState

这是顺序模型里最头大的一个坑：在旧状态的 Exit 里又调用了一次 ChangeState，会导致切换链混乱。

假设你要从 Idle 切到 Run，在 ExitState(Idle) 里判断某个条件后调用了 ChangeState(Jump)。此时顺序会变成：

1. 旧状态 Exit 开始执行。
2. Exit 内部触发新的切换，当前状态还指向 Idle。
3. 再次执行 ExitState(Idle)。
4. 执行 EnterState(Jump)，并把 currentState 改为 Jump。
5. 回到第一次 ChangeState，接着执行 EnterState(Run)，把 Jump 覆盖掉。

最终结果是 Run 接管了状态，但 Jump 的 Enter 已经执行过一次，状态对象里残留了 Jump 的初始化数据。日志里会出现两个 Enter 和两个 Exit，顺序完全没法看。

遇到这个问题，我的原则很简单：Exit 里绝不写切换逻辑。切换请求只能来自状态外部的控制器，或者状态 Update 里的明确返回值。如果状态内部确实需要在退出时触发后续逻辑，显式抛一个事件，让外部监听者去决定下一步切到哪，而不是让状态自己连环切换。

6.3 代码状态机和动画状态机错拍

前面提到代码状态机和 Animator 是两套不同时序，这个坑在实际项目中非常常见。我遇到过的情况是：代码状态机已经切到 Attack，同时设置了 Animator 的 Trigger，但 Animator 因为过渡条件尚未满足，花了几个帧才真正进入攻击动画。这时代码里读animator.GetCurrentAnimatorStateInfo(0).normalizedTime，读到的还是旧动画的进度，导致节奏判定完全错误。

后来的做法是：节奏敏感类逻辑不使用 Animator 状态信息作为判断依据，而是用代码状态机自己的计时器。进入 Attack 状态时记下起始时间，播放攻击判定时用固定时间偏移触发，不依赖动画播放到第几帧。如果一定要和动画对齐，就监听动画事件，在动画事件回调里做判定，而不是在状态机的每一帧 Update 里轮询动画进度。

7. 验证顺序的日志方法与速查准则

7.1 用 Debug.Log 验证时记得带上帧号

很多人验证状态机顺序时会打日志，但日志里只有状态名，没有帧号，看了一头雾水。一定要把帧号和时间点都打进去。

public override void Enter() { Debug.Log($"[FSM] Frame {Time.frameCount} Time {Time.time:F2} Enter {GetType().Name}"); } public override void Update() { // Update 日志不要每帧都打，只在关键帧或录帧时打开 Debug.Log($"[FSM] Frame {Time.frameCount} Update {GetType().Name}"); } public override void Exit() { Debug.Log($"[FSM] Frame {Time.frameCount} Time {Time.time:F2} Exit {GetType().Name}"); }

Update 日志在生产环境建议用条件开关包起来，否则一个角色同时跑几个状态，日志每帧几十条，游戏直接卡死。我的习惯是做一个静态开关FSM_Debug.EnableLog，只在排查时打开。

7.2 用断点加 Call Stack 定位切换来源

日志能确认“顺序是什么”，但“谁触发了切换”靠日志也能找，就是慢。更快的方法是直接在 ChangeState 里下断点，运行时看 Call Stack。Call Stack 会明确显示调用链：是哪个脚本、哪一行代码在什么条件下调用了切换。这在排查 6.2 节那种连环切换问题时尤其高效。

我建议在 ChangeState 方法第一行就下断点，不要写成if (next == currentState) return之后才断，否则你没看到的调用会直接跳过。把断点放在最开头，所有请求都会被捕获。

7.3 三条速记准则

最后整理三条我一直在用的顺序准则，可以贴到项目文档里：

• 一次标准切换的顺序永远是：旧状态 Exit → 新状态 Enter → 新状态 Update。唯一的分歧只在“新状态的 Update 是本帧执行还是下一帧执行”，你必须在框架里定死一种。
• Exit 永远必须在 Enter 之前执行，除非当前状态为空（初始状态场景）。
• 不要在 Enter 和 Exit 内部做状态切换，切换请求只允许来自外部控制器或状态 Update 的返回值。

这三条准则只要守住，状态机的执行顺序就能保持绝对可预测。我自己的体会是，状态机真正难的地方从来不是某个算法多复杂，而是每一步调用都发生在哪一帧、谁先谁后。把这个细节定死，后面所有状态相关的 bug 都能从“顺序乱了”这个角度一眼定位。最后再分享一个小技巧：写状态机框架时，任何一次修改都先跑一遍带帧号的日志，确认顺序没变，再做功能迭代。顺序模型稳了，状态设计才能放开手脚。