类装饰器作用于静态方法时会破坏其 callable 状态，因其执行早于静态方法绑定，且 staticmethod 对象本身不可调用；必须手动提取 func 并重建 staticmethod，或改用 @classmethod、将逻辑移出类体。
类装饰器作用于静态方法时会破坏其 callable 状态
类装饰器（如 @dataclass、自定义类装饰器）在运行时接收整个类对象作为参数，并返回一个新类（或就地修改）。但静态方法在类体中定义后，尚未被真正“解析”为可调用函数——它此时只是一个 staticmethod 实例（即装饰器对象），而该对象本身不可调用。类装饰器若未显式处理这类对象，就会跳过它们、或错误地将其当作普通属性处理，导致后续通过 MyClass.static_func() 调用时报 'staticmethod' object is not callable。
- 类装饰器执行时机早于静态方法绑定：类体执行完、
__new__和__init_subclass__触发前，静态方法仍为未解包的staticmethod包装器 - 多数通用类装饰器只遍历
__dict__中的函数对象（types.FunctionType），而staticmethod是另一种类型，直接被忽略 - 即使装饰器尝试包装它，也容易因签名不匹配（静态方法无
self/cls）导致 wrapper 缺失必要参数逻辑
用 functools.wraps 修饰静态方法再装饰会失败
有人试图先用 @functools.wraps 包装静态方法，再套类装饰器，这反而加剧问题：@staticmethod 必须是**最外层装饰器**，否则 Python 解释器无法识别其静态语义。一旦 @functools.wraps 或其他装饰器出现在 @staticmethod 外面，该方法就退化为普通函数，失去静态绑定能力，且类装饰器更难还原其原始意图。
-
@staticmethod必须紧贴函数定义上方，不能被任何其他装饰器包裹 -
functools.wraps的目标是保留元信息，但静态方法不需要self，其__func__属性才是真实函数；wraps 不解决 callable 性问题 - 类装饰器若想安全支持静态方法，必须手动提取
obj.__func__，包装后再重新构造成staticmethod
替代方案：用 @classmethod 替代 @staticmethod 更易兼容
如果静态方法实际只依赖类自身（比如读取 cls.DEFAULT_CONFIG），改用 @classmethod 是最轻量的绕过方式。类装饰器普遍能识别 classmethod 对象，并保留其 __func__ 和调用协议，不会破坏可调用性。
-
@classmethod对象本身是可调用的，类装饰器通常不做特殊过滤 - 调用时自动传入
cls，若你原本就不需要参数，加个_占位即可：def f(cls): ... - 注意：不要在
@classmethod内部误用super()调用同名静态方法——super().f()会报AttributeError，因为静态方法不参与 MRO 查找
真正安全的做法：把逻辑移出类定义体
最可靠、最易调试的方式，是根本不在类体内调用或定义需装饰的静态逻辑。把生成常量、预计算值等操作放在类定义之后，用类名显式调用：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
class MyFile:
@staticmethod
def GenerateFilter(exts):
return "|".join(f"*.{e}" for e in exts)
<h1>✅ 正确：类已构建完成，静态方法已绑定为可调用对象</h1><p>ConfigFilter: str = MyFile.GenerateFilter(["json", "xml"]) # 不用 Final 也可，看需求</p>这个位置的 MyFile.GenerateFilter 是真正的函数，类装饰器完全不影响它；所有类型注解、赋值、缓存逻辑都可自由使用。复杂点在于——很多人下意识把“属于类的逻辑”全塞进 class 块里，却忽略了 Python 类构造的时序约束：类不是声明式容器，而是一段被执行的代码块，其中的成员对象有明确的初始化顺序。
