工厂函数返回实例前不强制类型校验，但生产环境通常添加；校验应随类型注册而非硬编码在工厂中；简单工厂适合类型少、扩展少场景，抽象工厂适用于需强约束一族对象的场景；工厂应无状态，优先用@staticmethod实现。

工厂函数返回实例前要不要做类型校验

不强制，但多数生产环境会加。因为工厂的核心职责是解耦对象创建逻辑，不是兜底类型安全——如果下游代码依赖特定接口，应在调用处做 isinstance 或协议检查，而非让工厂替你拦住非法参数。

常见错误是工厂里写一堆 if type(arg) is X，结果新类型加进来就得改工厂；更灵活的做法是注册时绑定校验函数：

class Factory:     _creators = {}     _validators = {} 
@classmethod def register(cls, name, creator, validator=None):     cls._creators[name] = creator     if validator:         cls._validators[name] = validator  @classmethod def create(cls, name, **kwargs):     if name not in cls._creators:         raise ValueError(f"Unknown product: {name}")     if name in cls._validators and not cls._validators[name](kwargs):         raise ValueError(f"Invalid config for {name}")     return cls._creators[name](**kwargs)


校验逻辑随类型注册走，新增产品不用动工厂主干
validator 可以是 Lambda，也可以是独立函数，便于单元测试
错误信息里带具体 name，比泛泛的 TypeError 更易定位

抽象工厂 vs 简单工厂，什么场景该选哪个
简单工厂（一个函数或类负责创建多种同类对象）适合配置驱动、类型不多且不常扩展的场景，比如日志处理器：get_logger_handler("file")、get_logger_handler("http")。
立即学习“Python免费学习笔记（深入）”；
抽象工厂（定义创建一族相关对象的接口，由子类实现）只在你明确需要「绑定约束」时才值得上——例如数据库模块既要支持 mysql 又要支持 postgresql，且每个库都必须配套自己的 Connection、Cursor、Transaction，这时用抽象工厂能防止混用：
class DBFactory(ABC):     @abstractmethod     def create_connection(self): ...     @abstractmethod     def create_cursor(self): ... 
class MySQLFactory(DBFactory): def create_connection(self): return MySQLConnection() def create_cursor(self): return MySQLCursor()  # 和上面强关联
调用方拿到 factory 后，所有产出天然兼容


抽象工厂增加了一层间接，调试时多跳一次，别为“看起来更规范”而用
如果只是换序列化格式（jsON/MsgPack/YAML），用简单工厂 + 策略模式更轻量
python 没有接口强制，靠文档和类型提示（Protocol）维持族内一致性

工厂类该不该带状态（比如缓存已创建的实例）
带状态是反模式，除非你明确在做对象池或单例变体。标准工厂应是无状态的：输入相同参数，每次返回新实例。否则会引发隐式共享、线程不安全、测试难 mock 等问题。
如果真需要复用（如连接池、配置解析器），应该拆成两个角色：

工厂：纯创建，create_pool(size=10) 
管理器：持有并复用，PoolManager.get_or_create("default") 

强行把两者塞进一个类，很快会出现「这个方法该清缓存吗」「并发调用会不会覆盖缓存」这类纠结。
用 @staticmethod 还是 @classmethod 实现工厂方法
优先 @staticmethod。工厂方法本质是命名空间下的函数，不依赖类本身的状态或继承链。用 @classmethod 的唯一合理理由是：你需要子类能重载它并访问 cls（比如自动根据子类名推导配置路径）。
但要注意：Python 的 cls 是运行时确定的，如果父类工厂被子类继承后没重写方法，cls 仍是子类——这容易导致意外行为：
class BaseFactory:     @classmethod     def create(cls, **kw):         print(f"Creating for {cls.__name__}")  # 这里 cls 是调用者，不是定义者         return cls._impl(**kw) 
class UserFactory(BaseFactory): pass
UserFactory.create()  # 输出 "Creating for UserFactory"，不是 "BaseFactory"

静态方法语义清晰，不引入继承歧义
需要动态行为时，显式传入类或使用注册表，比依赖 cls 更可控
ide 和类型检查器（如 mypy）对 @staticmethod 的推断也更稳定

工厂最难的从来不是怎么写，而是什么时候该删掉它——当注册项超过 5 个、配置开始嵌套、同事开始问“这个 new_xxx 函数到底在哪定义的”，就该回头看看：是不是把简单问题过度架构了。