Python 类方法与静态方法的本质区别

类方法第一个参数必须是cls，python强制传入当前类；静态方法无隐式参数，仅属类命名空间；三者调用方式与可测试性、继承行为、语义边界均不同。

类方法第一个参数必须是 cls，不是约定而是强制要求

Python 解释器在调用 @classmethod 修饰的方法时，会自动把当前类（而不是实例）作为第一个参数传入。这个参数名可以叫 cls、klass 甚至 whatever，但位置和语义是硬性的——你不能漏掉它，也不能把它当成普通参数随便放后面。

常见错误现象：TypeError: my_classmethod() missing 1 required positional argument: 'cls'，通常是因为忘了写这个参数，或者误写成 self。

• 继承场景下，cls 指向的是实际调用该方法的类，不是定义它的父类——这是实现工厂方法的关键
• 如果在类方法里写 self.xxx，会直接报 NameError，因为根本没有 self
• 类方法内部不能访问实例属性（如 self.name），但能访问类属性（如 cls.version）

@staticmethod 真的就是普通函数，只是“挂”在类上

静态方法不接收隐式参数，既不是 self 也不是 cls。它和模块顶层函数行为完全一致，唯一的区别是命名空间归属：它属于类，但和类的状态、实例都无关。

使用场景：当你有一段逻辑和类相关（比如数据预处理规则、单位换算），但不需要访问类或实例的任何成员时，就该用 @staticmethod。

立即学习“Python免费学习笔记（深入）”；

• 如果静态方法里意外用了 self 或 cls，运行时报 NameError，不会被装饰器“兜底”
• 静态方法无法通过 super() 被子类重载调用，因为它不参与 MRO 查找
• 过度使用静态方法可能暴露设计问题：如果一堆静态方法都在操作同一组数据，大概率该抽成独立工具模块，而不是塞进类里

实例方法、类方法、静态方法的调用方式差异直接影响可测试性

三者调用入口不同，导致单元测试写法和 mock 策略完全不同。

• 实例方法必须通过实例调用：obj.method()；mock 时通常 patch 实例属性或用 unittest.mock.Mock(spec=...)
• 类方法可通过类或实例调用：MyClass.cls_method() 或 obj.cls_method()；mock 时要 patch 类本身，比如 patch('mymodule.MyClass.cls_method')
• 静态方法调用最自由：MyClass.static_method()、obj.static_method()、甚至直接 MyClass.static_method = Lambda: ... 替换；但它也最容易被误当成纯函数而忽略其所属上下文

一个典型坑：写测试时用 MyClass().static_method() 调用，结果上线后有人改成 MyClass.static_method()，看似没变，但如果静态方法内部偷偷依赖了某个全局状态（比如缓存字典），就可能因调用路径不同引发竞态。

别用类方法模拟静态方法，也别用静态方法假装能访问类状态

有些人在类方法里只读一个常量，就以为“反正没改东西，写成静态方法也一样”，这是危险的直觉。

• 类方法支持继承重写：ChildClass.cls_method() 会调用子类版本；静态方法不会，它永远绑定原始定义处
• 类属性可能被子类覆盖（如 Child.version = '2.0'），此时类方法中 cls.version 自动生效，静态方法里硬编码 MyClass.version 就失效了
• 反过来，如果真需要“完全隔离”的逻辑，却用了类方法，就多了一层不必要的耦合——哪怕现在没用 cls，未来重构时别人可能误以为它和类有关联

真正难判断的点往往不在语法层面，而在语义边界：这个方法到底“属于谁”？是某类的构造策略（用类方法），还是跨类通用的计算逻辑（用静态方法或独立函数）？一旦模糊，后续继承、patch、迁移都会开始咬人。