必须用@classmethod当需访问类属性、调用类方法或实现工厂模式；只能用@staticmethod当函数完全独立于类状态。实例方法不适用因强制依赖实例，造成冗余和测试困难。
什么时候必须用 @classmethod
当你需要在方法里访问或修改类属性、调用其他类方法，或者想实现工厂模式（比如根据不同输入创建不同类型的实例），@classmethod 是唯一选择。
常见错误现象：用 @staticmethod 去读写 cls.PI 或调用 cls.from_json()，结果报 NameError: name 'cls' is not defined。
- 类方法第一个参数固定是
cls，它指向当前类（包括子类继承时的动态绑定） - 如果方法里用了
cls.some_class_attr或cls(...)，就不能换成@staticmethod - 子类调用父类的类方法时，
cls自动变成子类，这是多态的关键机制
什么时候只能用 @staticmethod
当函数逻辑完全独立于类的状态——不读类变量、不调类方法、也不依赖实例——那它本质上就是个普通函数，只是“放在类里图个组织清晰”，这时用 @staticmethod 最干净。
常见错误现象：把纯工具函数（如字符串清洗、单位换算）写成实例方法，导致每次调用都得先 obj = MyClass()，浪费对象创建开销。
立即学习“Python免费学习笔记（深入）”；
- 静态方法内部不能直接用
self或cls，连MyClass.attr都得显式写全名，不能省略 - 如果函数未来可能被提取到模块顶层，现在就用
@staticmethod，迁移成本最低 - 性能上，
@staticmethod比实例方法略快（少传一个隐式参数），但差异微乎其微，别为这点优化牺牲可读性
为什么不用实例方法代替它们
实例方法强制要求你传入实例，但很多场景根本不需要实例状态。硬套实例方法会带来三类问题：
- 调用方必须先构造对象，哪怕只为了调一个跟该对象无关的函数（比如
ConfigLoader().parse_yaml(...)） - 方法签名暴露了虚假依赖：
def helper(self, x, y)让人误以为它要读self.config或改self.cache - 单元测试更麻烦——得 mock 实例，而
@staticmethod和@classmethod可直接当普通函数测
容易被忽略的继承细节
类方法在继承链中行为是动态的，静态方法不是。这个差异在真实项目里常引发隐蔽 bug。
比如父类定义了 @classmethod def create(cls): return cls()，子类调用 Child.create() 会返回 Child 实例；但若写成 @staticmethod，里面写死 return Parent()，子类调用也只会返回父类实例。
-
@classmethod的cls是运行时确定的，支持“反向构造” -
@staticmethod无任何上下文，所有类名、方法名都得硬编码，一改就得全局搜 - 如果你写了一个工具类，又不确定将来是否会被继承，优先考虑
@classmethod—— 它比@staticmethod更具扩展性
