Python单例模式的几种实现方式

前言

最近在整理项目代码，又一次审视了单例模式的各种实现。说来有趣，对单例模式的理解，似乎走过了一个完整的循环：从最初懵懂地套用，到后来热衷于追求各种“巧妙”甚至“炫技”的写法，最后兜兜转转，还是觉得最朴素的方案最可靠。

今天，我们就来系统梳理一下Python中实现单例的几种主流方式，并分享一个在编程圈子里逐渐形成的共识：很多时候，朴素的就是最好的。

一、单例模式简介

单例模式（Singleton Pattern），这个设计模式的核心目标很明确：确保一个类只有一个实例，并且提供一个全局的访问点。听起来简单，但用起来却有不少门道。

适用场景

二、四种实现方式

那么，在Python的世界里，有哪些方法可以实现单例呢？下面这四种，算是比较有代表性的。

方式一：类装饰器

def singleton(cls):
    """单例装饰器：闭包保存唯一实例"""
    _instance = None

    def wrapper(*args, **kwargs):
        nonlocal _instance
        if _instance is None:
            _instance = cls(*args, **kwargs)
        return _instance

    return wrapper


@singleton
class DBConnect:
    def __init__(self, host):
        self.host = host
        print("数据库连接初始化")


# 使用
obj1 = DBConnect("127.0.0.1")
obj2 = DBConnect("192.168.1.1")  # 不会重新初始化

print(obj1 is obj2)  # True
print(obj1.host)     # 127.0.0.1

特点：装饰器的语法非常优雅，使用时一目了然，算是Pythonic的实现之一。

方式二：__new__方法

class MySingleton:
    """单例类：通过 __new__ 控制实例创建"""
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance


# 使用
obj1 = MySingleton()
obj2 = MySingleton()
print(obj1 is obj2)  # True

特点：这是最直接、教科书式的方式。但有个小问题，_instance作为类变量暴露在外。话说回来，之前在一篇关于Playwright封装的文章里就用了这种方式，现在回头看觉得不太妥——那个类本身并不必须是个单例。更好的做法是，把单例化的选择权交给使用者，让他们根据需要显式处理。

方式三：函数

from typing import Type, TypeVar

T = TypeVar('T')

def singleton(cls: Type[T], *args, **kwargs) -> T:
    """单例工厂函数"""
    if not hasattr(cls, '_instance'):
        cls._instance = cls(*args, **kwargs)
    return cls._instance


# 使用
class TargetClass:
    def __init__(self, config):
        self.config = config

obj = singleton(TargetClass, config="value")

特点：需要显式调用singleton()函数。优点是语义非常明确，使用者清楚地知道自己在获取一个单例；缺点嘛，就是每次都要多写几个字符，不够直观。

方式四：functools.lru_cache

from functools import lru_cache

@lru_cache(maxsize=1)
def get_instance():
    return MyClass(arg1="value")


# 使用
obj1 = get_instance()
obj2 = get_instance()
print(obj1 is obj2)  # True

特点：直接利用Python标准库，无需额外造轮子。虽然从语义上说它更像一个缓存，但实现单例的效果是杠杠的，而且还能享受缓存机制带来的其他好处。

三、优缺点对比

光看代码可能还不够直观，我们把几种方式放到一起对比一下，优劣就清晰了。

四、我的建议

看了这么多实现，到底该怎么选呢？这里有一个核心建议。

优先使用显式单例

相比费尽心思把一个类本身变成单例，显式地获取单例往往是更清晰的写法。来看两个例子：

# ✅ 推荐：显式获取单例
_db = None
def get_db():
    global _db
    if _db is None:
        _db = Database()
    return _db

# 或者更简洁地用 lru_cache
@lru_cache
def get_db():
    return Database()

# ❌ 不推荐：把类变成单例，除非很确定此类必须是单例类，不会造成使用者误解
@singleton
class Database:
    ...

为什么？

1. 透明性：使用者能一眼看出这个对象是全局共享的，没有隐藏的魔法。
2. 可控性：创建时机、创建方式完全由你掌控，灵活性更高。
3. 易测试：在单元测试中，Mock或者替换一个函数返回的实例，比替换一个单例类本身要容易得多。
4. 少歧义：避免了使用者误以为每次调用构造函数都会得到一个新实例的尴尬。

五、多年编程感悟

朴素的就是最好的。所有当时自鸣得意的所谓编程技巧，最后都会被证明要用更多的代价来理解和维护它。

这句话可能道出了很多资深开发者的心声。追求“巧妙”有时反而会引入不必要的复杂度。

几个教训

回归朴素

代码的演进，常常是一个从复杂回归简单的过程。

# 曾经的我：一定要用上单例模式这个“高级”特性！
@singleton
class ConfigManager:
    ...

# 现在的我：简单、直接，往往就是最好的
@lru_cache
def get_db():
    return Database()

简单、直白、不需要额外的解释。这样的代码，才是真正的好代码。

六、总结

最后，我们来回顾一下今天的要点。

要点回顾

1. 装饰器方式：如果你确定某个类必须且永远是单例，那么类装饰器是实现方式中最推荐的一种。
2. 显式获取单例：在大多数情况下，通过一个函数显式地获取单例实例，比把类本身设计成单例更清晰、更灵活。
3. lru_cache：对于简单的单例需求，functools.lru_cache 是最轻量、最Pythonic的缓存式解决方案。
4. 朴素思维：这是最关键的一点。能够用简单方式解决的问题，就不要过度设计。代码的可读性和可维护性，永远应该排在“炫技”的前面。