类方法第一个参数必须是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免费学习笔记（深入）”；
这本书给出了一份关于python这门优美语言的精要的参考。作者通过一个完整而清晰的入门指引将你带入python的乐园，随后在语法、类型和对象、运算符与表达式、控制流函数与函数编程、类及面向对象编程、模块和包、输入输出、执行环境等多方面给出了详尽的讲解。如果你想加入 python的世界，David M beazley的这本书可不要错过哦。 (封面是最新英文版的,中文版貌似只译到第二版)
- 如果静态方法里意外用了
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、迁移都会开始咬人。
