一个让人崩溃的重构
先讲个真事儿。
三年前，我写了一个 User 类，用来处理用户数据。当时为了“优雅”——不用创建实例就能从字典生成用户对象——我用 @staticmethod 写了一个 from_dict 方法：
class User:
def __init__(self, name, email):
self.name = name
self.email = email
@staticmethod
def from_dict(data):
return User(data['name'], data['email'])
代码跑得好好的，我挺得意。简洁、清晰、不用实例化就能用。
三年后，产品经理跑过来说要加一个企业用户功能。企业用户有自己的专属字段，比如公司名称。我想都没想，写了个子类：
class EnterpriseUser(User):
def __init__(self, name, email, company):
super().__init__(name, email)
self.company = company
@staticmethod
def from_dict(data):
return EnterpriseUser(data['name'], data['email'], data['company'])
然后我调用 EnterpriseUser.from_dict(some_data)——
**返回的是 User 对象，不是 EnterpriseUser**。
我懵了。检查了半天才发现，问题出在三年前那个 @staticmethod 上。父类的 from_dict 里硬编码了 User(...)，子类虽然“重写”了方法，但只要调用链里任何一处用了父类的版本，返回的永远是 User。
改了一个下午的代码，把十几处调用全捋了一遍，我才真正明白了一件事：**@staticmethod 和 @classmethod 在继承里的区别，比你想象的大得多。**
它们到底有什么区别？
先看最直观的差别：
class Demo:
@staticmethod
def static_method():
# 没有 self，也没有 cls
print("我是静态方法")
@classmethod
def class_method(cls):
# 第一个参数是 cls，代表类本身
print(f"我是类方法，属于 {cls.__name__}")
表面上看，区别就是一个有 cls 参数、一个没有。但就是这个参数的有无，决定了它们在继承时的天壤之别。
@staticmethod 本质上就是一个普通函数，只不过被放在了类的命名空间里。它不依赖类，也不依赖实例，你传什么它就处理什么。它不知道“我是谁”，也不关心“谁在调用我”。
@classmethod 的第一个参数 cls 代表调用它的那个类本身。这个参数是 Python 自动传进去的，你不需要显式提供。关键的是——谁调用它，cls 就绑定到谁。
用大白话说：
- 静态方法：我就是个路过的，放这儿只是为了方便归类
- 类方法：我是这个类的一部分，我知道自己是哪个类
继承才是分水岭
回到刚才那个例子。用 @staticmethod 定义 from_dict 时，方法内部硬编码了 User(...)。不管是谁调用的——User 调也好，EnterpriseUser 调也好——它都只认识 User。
而 @classmethod 就不一样了：
class User:
def __init__(self, name, email):
self.name = name
self.email = email
@classmethod
def from_dict(cls, data):
return cls(data['name'], data['email']) # 注意这里用的是 cls，不是 User
class EnterpriseUser(User):
def __init__(self, name, email, company):
super().__init__(name, email)
self.company = company
@classmethod
def from_dict(cls, data):
return cls(data['name'], data['email'], data['company'])
现在调用 EnterpriseUser.from_dict(data)，cls 自动绑定为 EnterpriseUser，返回的自然是 EnterpriseUser 对象。
你看，同样的代码逻辑，只是因为装饰器不同，结果完全不一样。
@staticmethod 把方法“锁死”在了定义它的类上，而 @classmethod 让方法“活”了起来——它知道自己是被哪个类调用的。
“变脸”的真相
所以标题里说的“变脸”到底是什么意思？
@classmethod 在继承链里会“变脸”——它在父类里是父类，在子类里是子类。cls 这个参数就像一面镜子，谁调用它，它就映出谁的脸。
而 @staticmethod 不会变脸——它永远定格在定义它的那个类上，子类调用它也改变不了什么。
再举一个更直观的例子：
class Config:
DEFAULT_LEVEL = "INFO"
@staticmethod
def log(message, level=None):
if level is None:
level = Config.DEFAULT_LEVEL # 硬编码父类名
print(f"[{level}] {message}")
class SubConfig(Config):
DEFAULT_LEVEL = "DEBUG"
SubConfig.log("Hello") # 输出 [INFO] Hello，不是 [DEBUG]
你定义了一个子类，覆盖了 DEFAULT_LEVEL，以为静态方法会自动使用子类的属性。但 @staticmethod 不接收类参数，方法内部只能硬编码父类名 Config，子类的覆盖完全失效。
如果换成 @classmethod：
class Config:
DEFAULT_LEVEL = "INFO"
@classmethod
def log(cls, message, level=None):
if level is None:
level = cls.DEFAULT_LEVEL # 用 cls，不用硬编码
print(f"[{level}] {message}")
class SubConfig(Config):
DEFAULT_LEVEL = "DEBUG"
SubConfig.log("Hello") # 输出 [DEBUG] Hello
cls 自动绑定为 SubConfig，所以能读到子类覆盖的属性。
什么时候用哪个？
踩过这个坑之后，我给自己定了个简单的原则：
**如果需要访问类的属性、需要创建类的实例（比如工厂方法）、或者需要在子类中被多态地重写——用 @classmethod**。
**如果方法跟类和实例完全没关系，只是一个放在类命名空间里的工具函数——用 @staticmethod**。
事实上，很多 Python 老手会告诉你：大部分情况下，@classmethod 都能替代 @staticmethod，反过来却不行。因为 @classmethod 更灵活，支持继承和多态。而 @staticmethod 唯一的优势就是——它确实不需要类信息，用起来更“轻”一点。
但“轻”是有代价的。一旦写成静态方法，你就丧失了面向对象的多态性和继承能力。类方法能让你基于运行时实际调用的类来动态决定行为，而静态方法只能在定义时绑定死。
写在最后
那次重构之后，我养成了一个习惯：每次写 @staticmethod 之前，都先问自己一句——“这个方法真的不需要知道自己是哪个类吗？”
如果答案是“不确定”，我就用 @classmethod。
三年前那个周四下午，如果我用的是 @classmethod 而不是 @staticmethod，可能十分钟就搞定了企业用户的功能，而不是改了一个下午的代码。
Python 的装饰器就是这样——看着差不多，用起来差很多。@staticmethod 和 @classmethod 的区别，本质上就是 “硬编码”和“动态绑定”的区别。前者把一切都写死，后者把选择权留给调用者。
希望你不用踩同样的坑。
