为何不使用Python抽象类的类属性实现单例以替代全局变量？

我之前在模块里定义了一个pandas DataFrame全局变量，模块内多个函数都会访问并修改它，但这种设计在可测试性等方面存在明显问题。于是我想改用单例模式替代这个模块级变量，Python里有不少单例实现方式，比如用元类限制实例数量。但我有个疑问：为什么很少有人用无法实例化的抽象类的类属性来实现单例？我已经测试过在抽象类里定义计数器并在外部递增的场景，完全可行，而且这种方式还能避免普通类属性通过实例访问后变成实例属性的问题，但这种方案却鲜有人用，想知道原因。

测试代码示例 #

from abc import ABC, abstractmethod

class Test(ABC):
    counter = 0

    @abstractmethod
    def some_method():
      pass

Test.counter += 1

为什么这种方案鲜少被使用？ #

• 语义违背设计初衷：抽象类（ABC）的核心作用是定义抽象接口，强制子类实现指定方法，它的设计目标是做行为规范，而非存储共享状态。用它来存放单例的全局数据，完全偏离了其语义，其他开发者看到ABC类第一反应是找抽象方法和子类实现，不会想到这是个单例状态容器，可读性和可维护性大打折扣。

• 缺乏封装，和全局变量问题本质相同：直接操作抽象类的类属性（比如Test.counter +=1）属于裸操作，没有任何封装逻辑。如果是操作DataFrame，没办法加校验、日志、事务控制等逻辑，和原来的模块级全局变量一样，只是换了个存储位置，并没有解决耦合度高、修改不可控的核心问题。而标准单例模式通常会把状态封装在实例中，通过暴露方法来操作，能更好地控制状态变更。

• 扩展性极差：如果之后需要调整单例逻辑——比如要实现懒加载、或者某些场景需要多个实例、或者要加线程安全控制——抽象类的方案几乎无法灵活调整。而元类、装饰器、或者基于__new__的单例实现，都能轻松扩展这些功能。

• 概念混淆，代码意图模糊：单例的核心是“确保类只有一个实例，并提供全局访问点”，而抽象类的核心是“不能实例化，定义抽象接口”。把这两个概念混在一起，会让代码的意图变得模糊，新人维护时会困惑：这个ABC类到底是用来定义接口的，还是用来存全局数据的？

• 没解决全局变量的核心痛点：全局变量的问题除了可测试性，还有耦合度高、并发风险等。抽象类的类属性依然是全局可直接修改的，测试时很难mock替换，和模块级全局变量一样会导致测试困难。而标准单例可以通过依赖注入的方式传入，测试时能轻松替换成模拟实例。

内容的提问来源于stack exchange，提问作者Nick