只说明结论，不讲为什么，自己探索，框架没有好坏，只有需求是否满足，免得遇到容不下讲问题的讨论。
像是我遇到个et框架的“行为机”(就是GOAP)的问题讨论，结果讲个问题太蠢还被当中的小鬼嫌弃，显得我用fsm很蠢。
废话不多说：
首先，要使用分层fsm来避免状态之间的转换出现混乱。
其次，fsm的设计要符合进入，更新，退出这三个基本生命周期，具体参考Unity，这里面还可以再细分一下。
比如更新可以细分成处理物理属性的更新，还有专门处理逻辑切换的更新。
进入和退出要考虑动画的一个退出时间，也就是游戏出现的硬直，即切换动画必须时间，可以成为构造函数的参数，也可以是一个人生命周期的函数，看自己需要。
然后，就是通过c＃的事件，委托方法避免引用问题，解耦
最后，建议结合Unity的visual scripting的状态机，这样的好处是保证同步更新fsm设计图和编程的一个实际实现。