工厂函数将对象创建逻辑集中封装，使调用方只关注“要什么”而非“怎么造”，避免硬编码散落、修改分散及空值风险，应抛异常而非返回null，推荐纯函数实现而非class封装。
为什么 new 之后还要再包一层工厂函数
直接 new 类没问题，但一旦构造逻辑变复杂（比如要根据配置选不同子类、要预设默认参数、要统一初始化流程），硬编码就容易散落在各处。工厂函数本质是把“怎么造对象”这个决策收口——不是为了炫技，而是让调用方只关心“我要什么”，不操心“怎么造”。
常见错误现象：if-else 判断塞在业务代码里，新增一种类型就得改多处；或者所有地方都写 new ConcreteA()，结果某天 ConcreteA 需要加参数，全项目搜着改。
- 使用场景：对象创建依赖外部配置（如读取 JSON 决定实例化哪个类）、需要隐藏具体实现类名、构造过程含副作用（如注册监听、加载资源）
- 参数差异：工厂函数通常接收一个标识符（如字符串
type或配置对象），而不是原始构造参数；真正传给构造器的参数应由工厂内部处理或透传 - 性能影响极小，但要注意别在工厂里做重操作（如同步读文件、网络请求），否则每次
create()都卡
Factory.create() 返回 null 还是抛异常
返回 null 是最危险的默认选择——调用方很容易忘记判空，接着就 Cannot read property 'xxx' of null。简单工厂不该替调用方做“容错”，它该明确表达“你问了个不存在的东西”。
典型错误：工厂里写 if (type === 'A') return new A(); else return null;，然后业务层直接 factory.create('B').doSomething()，运行时报错才回头找。
- 建议统一抛
Error，消息里带具体 type 和可用选项，比如throw new Error(`Unknown type: ${type}. Available: A, B, C`) - 如果确实需要“可选创建”，那就显式命名，比如
tryCreate()，并文档注明可能返回null或undefined - TypeScript 用户注意：返回类型别写成
MyClass | null，除非真有合法的 null 场景；更推荐用联合类型 + 明确枚举值约束输入
JavaScript 里要不要用 class 实现 Factory
不用。简单工厂的核心是函数，不是类。写成 class Factory { static create() { ... } } 纯属画蛇添足——没有实例状态、不需继承、不靠 this 绑定，加个 class 只会让调用多敲两个点：Factory.create() 对比 create()，还容易让人误以为能 new 出来个工厂实例。
容易踩的坑：有人把工厂做成单例类，然后在构造器里初始化一堆缓存或连接，结果发现根本没被复用，因为每次都是 new Factory().create()，缓存形同虚设。
- 直接导出纯函数，例如
export function createService(type, options) - 如果真需要封装状态（如共享缓存、配置上下文），用闭包或依赖注入，而不是靠
class包一层 - Node.js 环境下注意模块缓存：函数导出后多次
require拿到的是同一个函数引用，闭包变量天然复用
和依赖注入容器（如 InversifyJS）有什么区别
简单工厂就是手动写的、硬编码的、无反射能力的依赖注入。它不扫描类装饰器、不解析构造函数参数、不管理生命周期。当你还没到需要自动装配几十个服务的程度，或者项目是纯前端小工具，上 DI 容器反而增加心智负担和打包体积。
真实冲突点常出现在团队协作中：有人坚持“所有 new 都得走工厂”，结果连 new Date()、new Map() 都包一层 DateFactory.create()，完全背离初衷。
- 工厂只管“有业务含义的对象”，比如
PaymentProcessor、NotificationChannel；基础类型、数据结构、纯工具类别裹 - DI 容器适合大型应用，且要求严格约定（如接口抽象、装饰器标记）；简单工厂适合快速验证、脚本、CLI 工具等轻量场景
- 两者不互斥：可以用工厂作为 DI 容器的“自定义 provider”，但别把工厂当容器用
最常被忽略的一点：工厂函数本身也是依赖。它不该自己读配置、连数据库——这些应该通过参数传入，否则测试时无法 mock，上线后也难切换环境行为。
