一句话理解：生成器模式把复杂对象的分步构建过程封装起来，让同一组步骤可以产出不同配置，并在交付对象前统一校验。
它解决什么问题
当构造函数参数很多、存在可选步骤或必须遵守构建顺序时，调用代码很容易难读且漏配。生成器用有名称的方法表达每一步，并把最终校验集中在
Build 中。经典形式包含 Product、Builder、Concrete Builder 和可选的 Director。实际 C# 项目也常使用更轻量的流式 Builder。
Unity/C# 示例
使用时，参数意图一目了然：
Director 什么时候有用
如果多处代码都需要相同构建流程，可增加 Director 或预设方法，例如
BuildTutorialHero。若只有调用方自己决定步骤，省略 Director 能减少一层抽象。Unity 实践建议
- Builder 适合生成运行时配置、程序化关卡描述和复杂请求对象。
- 静态配置如果主要由策划在 Inspector 编辑，
ScriptableObject通常比纯代码 Builder 更自然。
Build应返回完整、有效的对象；不要让半成品逃逸。
- 生成器负责构建，不应顺便承担对象池、存档或业务执行逻辑。
优缺点
优点：调用可读、可处理可选参数、集中校验、可复用构建流程。
代价：增加额外类型和样板代码；简单对象使用命名参数或对象初始化器就足够。
小结
当“对象如何一步步变得有效”本身就是复杂逻辑时，生成器最有价值。若构建过程没有复杂度，不必为了模式而模式。