用@staticmethod还是@classmethod关键看是否需访问类本身：不依赖类或实例状态用@staticmethod；需cls参数、支持子类继承或操作类变量用@classmethod；涉及实例状态则必须用实例方法。
怎么判断该用 @staticmethod 还是 @classmethod
关键看方法是否需要访问类本身或实例状态。@staticmethod 完全不依赖类或实例，只是逻辑上属于这个类的普通函数；@classmethod 必须能拿到类对象（第一个参数通常是 cls），常用于替代构造函数或操作类变量。
常见误用：把需要读取 cls.__name__ 或调用 cls() 的方法写成 @staticmethod——它拿不到 cls，会报 NameError 或抛出意外的 TypeError。
- 用
@classmethod：工厂方法（如from_json()）、修改类变量、支持子类继承时保持类上下文 - 用
@staticmethod：纯计算（如日期格式校验、字符串清洗）、与类强相关但无状态依赖的工具函数 - 别硬塞：如果方法里出现了
self.xxx或明显要改实例属性，就只能是实例方法
self、cls 和没参数，到底谁在哪个方法里出现
Python 不靠声明，而靠装饰器和参数名约定来区分。解释器只认签名和装饰器，但违反约定会导致运行时报错或行为异常。
错误现象：@classmethod 方法漏写 cls 参数，调用时会把类对象当成第一个实参传进去，导致后续参数错位；@staticmethod 里写了 self 却没传实例，调用时不报错但值是 None 或意外对象，容易埋下隐性 bug。
立即学习“Python免费学习笔记（深入）”；
- 实例方法：必须有
self，且必须是第一个参数（名字可改，但强烈建议用self） -
@classmethod：必须有cls（名字可改，但惯例如此），且必须是第一个参数 -
@staticmethod：参数完全自由，不强制self或cls，也不自动注入任何东西
继承场景下三者的行为差异
子类调用父类方法时，self 始终指向实际实例类型，cls 指向调用时的类（可能是子类），而 @staticmethod 根本不感知类层级——它就像一个被“挂”在类命名空间里的独立函数。
典型陷阱：父类用 @classmethod 实现了 create_default()，子类继承后调用，返回的是子类实例（因为 cls 是子类）；但如果父类错误地用了 @staticmethod 并硬写 ParentClass()，那子类调用时仍返回父类实例，破坏了多态预期。
- 想让工厂方法随子类调用自动适配子类类型 → 用
@classmethod - 想确保返回固定类（比如总是
Config而非子类）→ 用@staticmethod+ 显式类名 - 实例方法天然支持多态，但要注意子类是否重写了同名方法
性能和可测试性上有什么实际影响
三者调用开销差异极小，不用为性能选型；真正影响开发体验的是可测试性和 mock 成本。
@staticmethod 最容易单元测试——它就是个函数，输入输出清晰，不依赖类状态；@classmethod 需要 mock 类本身（比如用 unittest.mock.patch patch 类名）；实例方法最重，往往得构造实例或 mock 整个对象。
- 如果逻辑可完全脱离类存在，优先抽成模块级函数，比
@staticmethod更清晰 - 避免在
@classmethod里做重 IO 或长耗时操作，否则子类继承后可能意外放大副作用 - 写单元测试前先问一句：这个方法的输入，是否只来自参数？如果不是（比如读了
cls._cache），那就不是纯函数，mock 就绕不开
最容易被忽略的一点：装饰器顺序。如果同时用 @classmethod 和 @lru_cache，必须 @lru_cache 在外层，否则缓存的是 cls 对象而非实际参数——因为 @classmethod 先包装，把方法转成了接收 cls 的 callable，@lru_cache 缓存的就是这个 callable 的调用结果，而不是你期望的业务参数组合。
