从Unity 4时代我就开始在场景里拖脚本，那会儿用MonoBehaviour简直像作弊。想做个旋转的方块，挂个脚本写个Update就能跑。小游戏开发快得飞起，我当时觉得这就是游戏编程的天花板。直到项目做到几十个类、成百上千个组件连成一团浆糊，我才发现自己被这套‘组件’骗了。
MonoBehaviour表面上看着是组件，其实是个伪OOP。它的序列化方式让你不敢动私有字段，它的生命周期函数被引擎在不知道的时机调用，Update的调度顺序完全没有保证。更要命的是，组件之间可以随意互相引用，时间一长就是一堆蜘蛛网。我见过一个复杂的RPG战斗系统，里面上百个C#类互相new、互相FindObjectOfType，最后连原作者都不敢改。当时我安慰自己：这是项目组织问题，不是Unity的问题。
后来我接触了ECS，第一反应是‘这才是正道’。数据和行为分离，Job System并行遍历，缓存友好得让人想哭。但真正跨进DOTS的门槛时，我又傻眼了。Entity的查询至少要写三行样板代码，System的排序得手动控制，哪怕你只是想让几个角色动一下，也得搭一套像样的Unity.Entities环境。更别提当时的工具链还在奔溃边缘走，我记得有一次因为memset了NativeArray，整个场景的物理直接失效。搞得我一度怀疑自己是学不会新东西了。
但真正让我清醒的是一次迁移事故。我们花了半年把一套MonoBehaviour为核心的战斗系统改成纯ECS，结果性能只提升了一点点，反而因为调试困难多花了两倍工时。后来我退了一步，用Job System只优化了最热门的寻路和碰撞，剩下的继续用MonoBehaviour。于是项目流畅了，维护也轻松了。这时候我才意识到：ECS是一种性能工具，不是万能架构。Unity真正优秀的地方，是那个你随时能停下来的编辑器和那套灵活的组件思维，而不是让你跟着版本宣传跑。
所以我现在看别人一上来就鼓吹DOTS，我只想说：别神化任何范式。MonoBehaviour有它糟糕的一面，但它能让你快速把想法变成可玩的东西。ECS很好，但它的复杂度只有在真正的CPU密集瓶颈面前才值得付出。做项目不是写论文，你需要的是在合适的地方用合适的工具，而不是为了‘未来趋势’提前给自己套上枷锁。
