鸿蒙游戏为什么不能继续用传统 MVC？
大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出
我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
- 引言
- 一、MVC 是为“页面”设计的
- 二、游戏和管理系统根本不是一回事
- 三、Controller 为什么一定会变胖？
- 四、Controller 的本质问题
- 五、鸿蒙游戏真正需要的是什么？
- 六、Controller 管流程，System 管规则
- 七、状态驱动 VS 页面驱动
- 八、多端场景下 MVC 更容易崩
- 九、AI 时代进一步淘汰 Controller
- 十、一个典型重构案例
- 十一、MVC 最大的问题不是老
- 十二、一个关键认知升级
- 总结
引言
如果你做过传统客户端开发，大概率接触过 MVC：
Model View Controller很多人第一次做鸿蒙游戏时，也会下意识这样设计：
PlayerModel PlayerView PlayerController或者：
BattleModel BattleView BattleController刚开始项目很小的时候：
没问题 甚至感觉很规范但当游戏开始增加：
技能系统 任务系统 AI系统 多人同步 多端协同MVC 很快就会暴露出一个问题：
Controller 开始无限膨胀。
最后你会看到：
BattleController 3000行或者：
GameController 5000行里面塞满了：
战斗逻辑 掉落逻辑 升级逻辑 AI逻辑 任务逻辑这时候问题已经不是代码风格了，而是：
MVC 天生不适合承载复杂状态系统。
一、MVC 是为“页面”设计的
先理解一件事，MVC 出现的时代：
桌面软件 管理系统 CRUD应用它解决的问题是：
用户操作界面 触发业务逻辑 更新界面例如：
点击按钮 ↓ Controller ↓ Model ↓ View更新这种模式非常适合：
表单 后台管理 办公软件因为：
状态变化少 逻辑链路短二、游戏和管理系统根本不是一回事
游戏运行时：
用户输入 AI输入 时间事件 网络事件同时发生，例如：
玩家攻击 怪物攻击 Buff生效 技能冷却 经验增长可能发生在同一时刻，这时候如果全部进入：
Controller结果就是：
Controller成为总指挥三、Controller 为什么一定会变胖？
看一个典型例子：
classBattleController{attack(){player.attack()enemy.takeDamage()level.addExp()drop.dropItem()mission.update()}}刚开始：
几十行后来：
几百行最后：
上千行因为：
所有业务都会往 Controller 聚集。
四、Controller 的本质问题
MVC 中：
Controller = 流程中心意味着：
所有逻辑都要经过它例如：
玩家升级Controller知道。
任务完成Controller知道。
Boss死亡Controller也知道。
最后变成：
Controller知道整个世界这就是经典的：
God Controller（上帝控制器）
五、鸿蒙游戏真正需要的是什么？
鸿蒙游戏更适合的模式是：
Store System UI因为天然分离：
状态 规则 展示例如，传统 MVC：
View ↓ Controller ↓ ModelSystem 架构：
Input ↓ System ↓ Store ↓ UI看起来差别不大，但本质完全不同。
六、Controller 管流程，System 管规则
这是最核心的区别，MVC：
Controller： 负责决定做什么 负责决定怎么做 负责决定谁执行System：
BattleSystem 只管战斗 LevelSystem 只管升级 DropSystem 只管掉落每个系统：
只负责一个领域复杂度被自然拆散。
七、状态驱动 VS 页面驱动
MVC 本质：
页面驱动例如：
打开页面 ↓ Controller运行鸿蒙游戏本质：
状态驱动例如：
HP变化直接：
UI更新根本不需要：
Controller刷新页面这与 ArkUI 的设计天然一致。
八、多端场景下 MVC 更容易崩
鸿蒙最大的特点共存：
手机 平板 PC TVMVC 通常会变成：
PhoneController PadController PCController甚至：
不同View 不同Controller维护成本越来越高。
System 架构则是：
Store ↓ System ↓ 多个UI例如：
手机UI 平板UI PC UI共享：
同一套规则九、AI 时代进一步淘汰 Controller
过去驱动业务：
用户点击所以合理：
Controller但未来：
用户 AI Agent 自动任务 网络同步都在产生行为。
这时候：
Controller已经无法承担统一入口。
System 更适合：
UserInput AIInput NetworkInput统一进入：
System处理。
十、一个典型重构案例
很多项目最初是：
GameController负责：
战斗 升级 背包 任务 商城最后：
5000+ 行代码重构后：
BattleSystem LevelSystem MissionSystem InventorySystem ShopSystemController消失。
只剩：
Engine负责调度。
结果：
结构清晰 职责明确 扩展容易十一、MVC 最大的问题不是老
很多人以为：
MVC 不好，因为过时了。
其实不是。
MVC 到今天依然适合：
后台系统 管理平台 表单应用问题在于：
游戏已经不是页面系统。
游戏更像：
持续运行的状态机而不是：
页面集合十二、一个关键认知升级
初学者会觉得：
Controller控制游戏但真正的大型游戏架构会变成：
Store保存世界状态 System定义世界规则 UI展示世界结果Controller的重要性不断下降，甚至最终消失。
总结
传统 MVC：
Model View Controller核心思想：
Controller驱动业务而鸿蒙游戏更适合：
Store System UI核心思想：
System驱动状态变化如果用一句话总结：
MVC 适合“页面驱动的软件”，而鸿蒙游戏本质上是“状态驱动的世界”，因此最终一定会从 Controller 走向 System。