在游戏开发中，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
游戏中库或平台对接可能用到，但非高频
🧠 总结分类图谱：🚀 高频使用（非常重要）：单例
策略
观察者
命令
状态
工厂（抽象工厂）
🔧 中频使用（有一定用途）：建造者
职责链
原型
享元
装饰器
代理
🧊 低频使用（特定需求下）：访问者
解释器
中介者
迭代器
模板方法
适配器
桥接