如题，在群里面已经讨论几次了。猫大和母哥的看法都是不要用状态机，并建议我多看看demo。
但是我现在还没有get到点，先把这个话题放到论坛。看看大家的意见。轻喷。
举个例子【在创角界面点击返回按钮】。
那么可能是返回选角界面（从选角界面点击创角），可能是返回登录界面（从新号登录进来直接创角）。
返回选角界面需要关闭创角界面，释放创角场景的美术资源。加载选角场景的美术资源，打开选角界面。
返回登录界面，需要关闭创角界面，释放创角场景的美术资源。打开选角界面。
如果按照现的方式，在OnClick或者事件响应中，需要处理以上逻辑，还需要在component记录是从哪儿来创角界面的。代码庞大，阅读性较差。
如果是状态机管理。只需要做一次状态切换。（并且一般状态机机制本身会记录从哪个状态切换而来）
创角状态的OnExit会负责释放创角美术资源，关闭创角界面
选角状态的OnEnter会负责加载选角美术资源，打开选角界面
登录状态的 OnEnter会负责打开登录界面
代码清晰，拆分得很细，而且复用性高。
例如，假设我是从GamePlay中返回登录，那么打开登录界面的这个操作亦是由登录状态的 OnEnter来处理。我不需要写第二次，只需要做状态切换即可。
然后，母哥和其他同学提到了用Scene即可。
那么问题来了：
如果想实现类似OOP框架中状态机对游戏主流程的管控， 在ET中是不是就是用CurrentScenesComponent来模拟状态机的状态？
目前看demo中的CurrentScenesComponent仅仅只是服务于游戏内地图。如果将其扩展到例如：
启动
热更新
登录
选角
创角
选角
加载
游戏中
….
这么多的Scene类型，分别管理自己业务的component，是否符合ET的设计思想？
然而我依然得到了否定的回答。 可能我还需要继续看demo来悟道吧。 问题先抛在这里。哪天我悟了，再来自问自答。