在游戏开发中，23种设计模式并不是每一种都会经常用到。实际使用频率取决于项目规模、开发阶段、团队习惯、引擎特性（如Unity、Unreal）、以及目标平台。我们可以从以下几个维度来分析：游戏开发阶段（初期架构、中期功能实现、后期优化与维护），并结合每个阶段的重点来评估哪些模式常用，哪些相对较少使用。
🌱 一、游戏初期架构设计阶段（基础架构、解耦、灵活性）
常用设计模式：
模式 | 原因与作用 |
|---|
单例模式 Singleton | 管理全局唯一对象，如游戏管理器、音频管理器、配置管理器 |
工厂模式 Factory / 抽象工厂模式 Abstract Factory | 用于生成游戏对象、UI元素、技能、武器等，支持扩展 |
策略模式 Strategy | 封装 AI、移动方式、攻击方式等可替换行为 |
观察者模式 Observer | 实现事件系统、状态通知（比如玩家死亡通知 UI、AI 等） |
命令模式 Command | 封装输入操作（撤销/重做系统、快捷键命令、技能释放） |
组件模式（组合模式 Composite） | 实现层级结构，如UI界面、装备系统（部件组合） |
次常用模式：
模式 | 使用场景 |
|---|
建造者模式 Builder | 创建复杂对象（如角色、怪物、关卡），但可能被ScriptableObject替代 |
状态模式 State | 管理角色状态（移动、跳跃、攻击、死亡），适用于FSM实现 |
职责链模式 Chain of Responsibility | 游戏中的碰撞处理、输入传递链条 |
⚙️ 二、功能开发与实现阶段（AI系统、UI系统、战斗系统、资源管理）
常用设计模式：
模式 | 原因与作用 |
|---|
状态模式 State | AI状态机、角色状态切换，维护行为逻辑清晰 |
观察者模式 Observer | UI响应游戏状态更新、任务系统监听事件 |
命令模式 Command | 封装操作、撤销、宏命令、技能队列 |
策略模式 Strategy | AI行为、技能计算、UI布局策略 |
享元模式 Flyweight | 优化资源使用（粒子、子弹对象共享内存） |
原型模式 Prototype | 用于对象克隆，节省实例化开销（如ScriptableObject.clone） |
次常用模式：
模式 | 使用场景 |
|---|
备忘录模式 Memento | 用于保存游戏状态（如存档系统） |
装饰器模式 Decorator | 动态增加游戏对象行为（如角色Buff系统） |
桥接模式 Bridge | 解耦抽象与实现（如分离UI逻辑与显示） |
🧰 三、后期优化与维护阶段（性能优化、系统扩展、热更新）
常用设计模式：
模式 | 原因与作用 |
|---|
享元模式 Flyweight | 大量重复对象共享数据（如地图Tile、子弹） |
代理模式 Proxy | 远程调用、资源延迟加载、网络通信（如热更新资源代理） |
责任链模式 Chain of Responsibility | 模块扩展易于维护（如输入系统） |
观察者模式 Observer | 拓展响应机制，不破坏原有逻辑 |
🚫 较少使用的设计模式（在游戏中不常见）
这些模式虽然在企业应用中有价值，但在游戏项目中使用频率较低：
模式 | 理由 |
|---|
解释器模式 Interpreter | 用于解析语言或规则，适合自定义脚本系统，游戏中较少出现 |
中介者模式 Mediator | 复杂UI组件交互可能使用，但难以维护和调试，不推荐频繁使用 |
访问者模式 Visitor | 多用于结构稳定、操作频繁的系统（如编译器），游戏中不常用 |
模板方法模式 Template Method | 被策略模式替代更灵活 |
迭代器模式 Iterator | 编程语言已提供原生迭代器，不常显式实现 |
适配器模式 Adapter | 游戏中库或平台对接可能用到，但非高频 |
🧠 总结分类图谱：
🚀 高频使用（非常重要）：
🔧 中频使用（有一定用途）：
🧊 低频使用（特定需求下）：
.png){kind=small}
