Python单例模式实现方式对比

本文深入剖析了Python中实现单例模式的四种主流方式——重写`__new__`、装饰器、元类及错误高发的`__init__`内判断，并明确指出：**唯有在对象内存分配阶段（即`__new__`）进行控制，才是最底层、最可靠、真正符合单例语义的实现**；其他方法或因作用域局限、继承失效、缓存冲突而不可靠，或因无法阻止实例创建而徒有其表——文章用实战陷阱、线程安全提醒和框架兼容性警告直击开发者痛点，帮你避开看似简洁却隐患重重的“伪单例”陷阱。

Python 中 __new__ 实现单例最常用也最可靠

直接重写类的 __new__ 是 Python 里控制实例创建最底层、最稳妥的方式。它在对象内存分配阶段介入，天然避开 __init__ 多次调用的问题。

常见错误是只改 __init__ ——比如在 __init__ 里加标志位判断，但每次 MyClass() 仍会新建对象并执行 __init__，只是跳过逻辑而已，完全不是单例。

实操建议：

• 用类变量（如 _instance）缓存首次创建的实例
• 在 __new__ 开头检查该变量，存在则直接返回，不调用 super().__new__
• 注意：如果类继承自不可变类型（如 str, tuple），__new__ 必须返回正确类型，否则会报 TypeError: object.__new__(X) is not safe
• 线程安全需额外加 threading.Lock，否则高并发下可能创建多个实例

装饰器实现单例简洁但有作用域陷阱

用函数装饰器包装类（如 @singleton）写起来短，但本质是把类变成“返回同一实例的工厂函数”，不是真正的类单例——它不改变类本身行为，只影响被装饰后的调用方式。

典型问题：

• 子类继承被装饰的类时，Child() 会得到新实例，和父类实例无关（因为装饰器只作用于原类名）
• 装饰器内部缓存通常用字典按类对象做 key，但如果模块被重载（如开发时热更新）、或存在多个相同名称但不同内存地址的类（如动态生成类），缓存会失效或冲突
• 无法支持带参数的类初始化（如 MyClass(arg=1)），除非装饰器额外处理 __call__ 的参数归一化

元类实现单例灵活但容易过度设计

通过自定义元类（继承 type）在类创建时注入单例逻辑，适合需要统一管控多个类行为的场景（比如框架中要求所有 XXXService 类都必须单例）。

但它比 __new__ 更抽象，调试困难，且容易和其它元类（如 ORM 的 DeclarativeMeta）冲突。

关键点：

• 重写元类的 __call__ 方法，在其中拦截实例化过程
• 缓存必须放在元类实例（即类对象）上，而不是元类类变量，否则所有使用该元类的类共享一个实例
• 若类定义了 __new__，元类的 __call__ 仍会调用它，需确保两者逻辑不打架
• Pydantic v2+ 的 BaseModel 默认禁用自定义元类，用元类实现单例会导致 TypeError: metaclass conflict

__init__ 里做单例判断基本没用

这是新手最容易误用的方式：在 __init__ 开头加 if hasattr(self, '_inited') 并设标记。它不能阻止新对象被创建，只是让多次初始化“看起来没效果”。

后果很实际：

• 每次 MyClass() 都分配新内存，对象 ID 不同，is 判断全失败
• 如果有资源独占逻辑（如打开文件、连接数据库），多个实例会同时抢资源，引发异常或数据错乱
• 垃圾回收压力增大，尤其在循环频繁创建的场景下（如 Web 请求中误用）
• 单元测试中 mock 难度陡增，因为每个 new 出来的对象都是独立个体

真正需要单例的地方，控制点必须在实例诞生之前——也就是 __new__ 或更早（如元类）。其他任何地方补救，都是在修漏水的桶。

本篇关于《Python单例模式实现方式对比》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！