一句话理解：抽象工厂提供一组创建方法，用来生成彼此匹配的产品族，而调用方无需知道具体产品类。
核心问题：保证产品族一致
假设游戏有森林和沙漠两套主题，每套都包含敌人、地表和环境音。调用方若分别选择三个具体对象，很容易混搭。抽象工厂把“一整套兼容产品”绑定在同一个工厂中。
模式角色
- Abstract Factory：声明每种产品的创建方法
- Concrete Factory：创建同一主题或阵营的产品族
- Abstract Product：每类产品的共同抽象
- Concrete Product：具体主题下的产品
Unity 示例：阵营装备工厂
Unity 默认不能直接在 Inspector 中序列化接口字段，因此这里用抽象
ScriptableObject，让配置可视化且类型安全。客户端只依赖
CampFactory：新增精灵阵营时，只需创建新的产品与
ElfCampFactory，客户端保持不变。适用场景
- 阵营装备、职业技能套装
- 不同主题的 UI 控件
- 不同平台的输入、存储与支付实现
- 生物群系的地形、植被和音效组合
权衡
抽象工厂擅长新增“产品族”，却不擅长新增“产品种类”。例如接口增加
CreateMount 后，所有具体工厂都必须实现它。只有当产品之间确实需要配套，且产品类别相对稳定时才值得使用。与工厂方法的区别
工厂方法通常聚焦一个产品的创建变化；抽象工厂协调多个相关产品。抽象工厂内部也经常使用多个工厂方法。
小结
选择抽象工厂的关键问题是：系统是否需要成套替换一组兼容对象。若答案只是“想少写几个
Instantiate”，使用普通工厂会更简单。