工厂模式是JavaScript中封装对象创建逻辑的设计模式，强调按需生产和统一出口，适用于创建逻辑复杂、需统一初始化或结构可变的场景，但存在类型信息丢失、原型链断裂及过度抽象风险。
工厂模式在JavaScript中是一种创建对象的常用方式，它通过函数封装对象的构造逻辑，对外隐藏具体实现细节。相比直接使用字面量或构造函数，它更强调“按需生产”和“统一出口”，但并非银弹，需结合场景权衡。
优点：解耦、复用与灵活配置
工厂函数将对象创建过程集中管理，调用方无需关心内部用了Object.create、class实例还是Object.assign组合数据。例如一个UI组件工厂可根据传入type参数返回Button、Input或Modal实例，所有初始化逻辑（如默认props、事件绑定、样式注入）都封装在工厂内，上层代码只关注“要什么”，不关心“怎么造”。多个模块共用同一工厂时，修改创建规则只需动一处；新增类型也只需扩展工厂内部分支，符合开闭原则。对于配置驱动的对象（如不同环境下的API客户端），工厂还能接收配置对象，动态决定是否启用缓存、重试或Mock响应。
缺点：丢失类型信息与原型链断裂风险
纯函数式工厂（如return { ... }）生成的是普通对象，没有明确的constructor，instanceof检测失效，也无法自然继承共享方法——所有方法都复制到每个实例上，浪费内存。若用new操作符配合构造函数再包装一层工厂，虽能保留原型链，但又引入了this绑定和new调用的隐式约定，易出错。TypeScript中，工厂返回类型常需手动标注为联合类型（如Button | Input | Modal），类型推导弱于class声明，智能提示和重构支持打折扣。另外，过度抽象可能让简单对象变得“重型”，比如只为加个默认id就写个工厂，反而增加理解成本。
适用边界：何时该用，何时绕道
适合以下情况：
• 创建逻辑复杂，涉及多步骤判断（如根据用户权限返回不同数据模型）
• 需要统一初始化副作用（如自动注册到全局管理器、触发埋点）
• 对象结构高度可变，且类型不确定（如解析后端动态schema生成表单字段）
• 团队协作中需强制约束创建入口，避免随意new或字面量滥用
应避免的场景：
• 对象结构固定、无差异化逻辑（直接用字面量或class更清晰）
• 强依赖 instanceof 或原型方法复用（优先考虑class + 继承或mixin）
• 项目已全面采用TypeScript且重视编译期类型安全（工厂需额外维护类型定义，不如泛型class直观）
不复杂但容易忽略：工厂本身不是目的，关键是厘清“变化点”——是对象类型变？配置变？行为变？还是生命周期变？抓住这个核心，才能让工厂真正服务于可维护性，而不是变成另一层黑盒。
立即学习“Java免费学习笔记（深入）”；
