绝大多数情况下该用 @staticmethod，因其不依赖类状态、不绑定类、逻辑固定且不可被子类覆盖；仅当需子类自动传入 cls 并动态实例化时才用 @classmethod。
静态工厂方法该用 @staticmethod 还是 @classmethod？
绝大多数情况下该用 @staticmethod。静态工厂方法的核心是「不依赖类状态、不实例化自身、只负责创建并返回对象」，和类本身没有绑定关系。用 @classmethod 反而容易误导——它隐含了对子类友好的意图（比如想让子类能覆盖逻辑），但静态工厂通常就是固定逻辑，不该被继承改变。
常见错误是看到“工厂”就默认用 @classmethod，结果在子类里意外触发了父类工厂方法，返回的却是父类实例，破坏类型一致性。
- 如果工厂逻辑完全不涉及
cls，也不需要支持子类定制，必须用@staticmethod - 只有当你明确需要「子类调用时自动传入子类类型」且工厂内部要用到该类型（比如动态实例化）时，才考虑
@classmethod -
@staticmethod方法在继承链中不会自动绑定，调用行为更可预测
如何避免工厂方法变成一堆 if/elif 的硬编码分支？
把类型映射抽成字典或注册表，而不是在方法里写条件判断。硬编码分支难扩展、难测试、易出错，尤其当新增类型时得改工厂源码。
推荐用注册机制：定义一个私有类变量（如 _registry），提供类方法 register() 供子类或外部模块注册构造器，工厂方法只查表调用。
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
class ShapeFactory:
_registry = {}
@staticmethod
def register(name):
def decorator(cls):
ShapeFactory._registry[name] = cls
return cls
return decorator
@staticmethod
def create(shape_type, **kwargs):
cls = ShapeFactory._registry.get(shape_type)
if not cls:
raise ValueError(f"Unknown shape: {shape_type}")
return cls(**kwargs)
- 注册装饰器让扩展变得声明式，新增类型只需加
@ShapeFactory.register("circle") - 工厂方法本身无分支，逻辑清晰，也方便单元测试（直接 mock
_registry） - 避免用字符串硬编码类型名，可配合
Enum或类型注解约束输入
为什么不能直接在 __init__ 里做多态创建？
因为 __init__ 必须返回 None，无法替代构造行为；且一旦在初始化阶段做类型分发，会混淆“对象已存在”和“对象正在创建”的边界，导致 isinstance 判断失效、__new__ 被绕过、序列化/反序列化异常等问题。
典型错误示例：def __init__(self, type_name, **kwargs): if type_name == "A": self.__dict__ = A(**kwargs).__dict__ —— 这不是创建，是字段覆盖，对象身份和类型都已丢失。
- 构造逻辑必须发生在实例化之前，即由
__new__或独立工厂函数完成 - 静态工厂方法本质是替代构造器的“可控入口”，它和
__init__职责正交 - 若强行塞进
__init__，调试时你会看到对象类型是工厂类本身，而非期望的子类
类型提示怎么写才不破坏工厂的灵活性？
用 Union 或协议（Protocol）声明返回类型，而不是具体类。静态工厂的返回值往往是多个子类之一，硬写成某个具体类会导致类型检查报错或 IDE 提示不准。
例如，若工厂返回 Circle、Square、Triangle，它们都实现 Drawable 协议，则返回类型应标注为 Drawable，而不是 Union[Circle, Square, Triangle]（后者冗长且难维护）。
from typing import Protocol
class Drawable(Protocol):
def draw(self) -> None: ...
class ShapeFactory:
@staticmethod
def create(shape_type: str) -> Drawable:
...
- 协议比抽象基类更轻量，不强制继承，适合描述“能做什么”而非“是什么”
- 如果必须暴露具体类型（如需调用子类特有方法），可用
TypeVar绑定泛型工厂，但多数业务场景协议足够 - 别忘了给参数加类型提示，比如
shape_type: Literal["circle", "square"]能让调用处获得更准的补全
