Python中将模块作为类使用与静态类实现的优劣选型问题

两种写法的性能差可以忽略不计，根本不值得拿速度当选择理由，真正要考虑的都是实际开发、维护过程中的实际问题：

性能层面的微小差异 #

• 模块版本的调用速度会略快一丢丢：Python模块是解释器原生实现的单例，第一次导入时就会执行模块代码完成初始化，后续所有导入操作都直接复用缓存好的模块对象，不需要走额外的实例化、类属性查找流程，也没有装饰器带来的额外调用开销。但这个差异基本在纳秒级别，99%的业务场景下根本感知不到，完全没必要为了这点速度纠结选型。

绝大多数场景优先选模块实现 #

• 这是Python原生支持的惯用写法，没有冗余样板代码。Python的模块天生就是单例，根本不需要自己额外写类来模拟单例逻辑，不用写类定义、不用纠结用@staticmethod还是@classmethod，代码更短更直白，完全符合Python“简单优于复杂”的设计原则。
  顺便说一句，你给出的静态类示例本身就有两个明显的代码错误：一是@staticmethod装饰的方法不会自动传入类对象作为第一个参数，你定义的get_foo(cls)实际运行时根本拿不到cls，会报参数数量不匹配的错，要访问类属性必须换成@classmethod才行；二是你定义的类名是小写的foo，导入的时候却写from foo import Foo，大小写不匹配会直接抛导入错误。这些都是硬套类结构带来的无意义坑点。
• 测试和维护更方便。模块级的状态如果需要在单元测试中重置、打桩，直接给模块属性赋值就可以实现，Python生态里的测试工具对模块属性的mock支持比类静态属性更成熟，操作起来更简单。
• 完全契合你想减少类使用、偏向函数式风格的目标。如果你的逻辑本身不需要创建实例、不需要继承多态、不需要用到面向对象的特有特性，硬给所有逻辑套一层类的壳子属于完全多余的抽象，反而会增加后续的代码理解成本。

只有这类场景适合用类版本 #

• 如果你后续需要基于这套逻辑生成多个互相独立的实例（比如需要多个状态互不干扰的foo对象，不再是全局唯一的单例），或者需要用到继承、多态、运算符重载这类类特有的能力，这时候用类实现才是合理的选择。

补充一个很多转语言开发者容易踩的误区：不少从Java这类纯面向对象语言转过来的开发者，会习惯把所有逻辑都塞进类里，但在Python里完全不需要被这种思路束缚——能用语言原生机制解决的问题，就不要额外加不必要的抽象层。你现在尝试用模块承载状态和函数的写法，反而是更Pythonic的选择。

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