※ 引述《NDark (溺于黑暗)》之铭言：
十年前我写了关于 Event 事件系统的文章．
十年过去其实我经历过很多专案，发现了越来越多的反例（Anti-Pattern，
使用了事件系统专案的开发者却无法驾驭，发现了问题无法除错解决的情况）．
简单来讲，事件系统的目的是把混沌整理为有序．
但在某些情形下也有机会产生更多的陷阱．
专案使用了事件系统，
但没有配套系统（或是团队文化）的事件系统仍然会受到执行顺序的困扰．
（这边讲的配套系统是负责显示记录的系统，
能够即时或事后检查游戏过程中发生了什么事．
团队文化指得是团队中是否有遇到问题能够细心检查的成员及工作环境）
在系统及设计还未进入稳定态的（新案）
或是在旧案装上新系统（尤其是演出，如跑马灯，弹出接口）特别容易发生这个问题．
以Unity来说．这个问题就是因为各脚本执行是有顺序的（即便没有设定脚本的执行顺序)
．Update() 都是一个一个脚本依序执行．
那么同一个画格送进事件系统也就有了顺序．那么陷阱就来自于
１．有时候我们希望A的执行顺序要高于B．而有时候又希望B的顺序高于A．
２．事件的结果发动有时候需要时间（尤其是动画／Coroutine），事件发动下去又继续
会有顺序的问题．
举例来说：
A脚本中总共写了A1 A2两个事件．
B脚本中总共写了B1 B2两个事件．
在某个运作中A1 B1会同一个画格发动．
另一个运作中A2 B2会同一个画格发动．（假设A的执行顺序快过B）
规格刚开始实作时A1->B1 的顺序是对的，
但过了一阵子实作另一个系统时却又希望 B2 -> A2 这样的顺序．这时候就会出现冲突．
没有一个配套系统很难发现问题在哪里．
第二最简单的修理方式就是把B调整为比A快．
这样就会反过来让A1->B1（或更多的类似流程）这条坏掉．
次简单的方式就是让A2去等B2．这可以临时解决问题．
但是要祈祷未来不要再对这个规格做修改．
这个问题的复杂度会随着
事件数（事件类别的种类及包含产生的结果）ｘ系统数
（通常是专案内被命名为Manager的类别）
而以乘法线性而更复杂．也就是越复杂的专案，这个连锁效应就越大．
不会感觉到这个问题，最有可能的情形是：
专案已经稳定了，系统不变只是扩充游戏内容的专案．（通常是续作）；
或是专案就不够大或久到会有这个问题．
blog连结:
https://ndark.wordpress.com/2021/06/25/%e4%ba%8b%e4%bb%b6%e7%b3%bb%e7%b5%b1%e7%9a%84anti-pattern/

一个脚本只有一个事件会有什么问题吗？

不太懂楼上的问题. 意思是把所有事件都分脚本写?全分开就属于不管理的方式.不管理.就是是事件运作满天飞. 一样会有顺序的问题.A脚本等B脚本 B脚本等C脚本 然后C脚本发现又要等A脚本.就死结了.事件系统的初衷就是 至少有一个统一入口.然后后续怎么运作.就要看事件管理系统怎么设计.譬如说当什么接口显示的时候,什么事件不要触发,延迟触发.因为是单一系统.所以才有办法接报表(Log)系统.分脚本的方式Log系统会更难写.

啊没看清楚，我原本以为AB只有event, 其实是有包逻辑