装饰器加在@staticmethod/@classmethod外侧会失效，因其作用于描述符而非函数；应置于内侧。@Property同理，装饰器需支持__get__协议。实例方法装饰须用functools.wraps避免self丢失。

装饰器加在 @staticmethod 和 @classmethod 上为什么失效？

因为 @staticmethod 和 @classmethod 本身返回的是描述符对象，不是普通函数。装饰器如果直接套在它们上面，会作用于这些描述符，而不是底层可调用对象，导致被装饰的逻辑根本不会执行。

正确做法是把装饰器放在 @staticmethod/@classmethod 内侧，也就是先装饰原函数，再用静态/类方法包装：

@my_decorator @staticmethod def my_method(): ... 
✅ 正确：装饰器看到的是普通函数
@staticmethod @my_decorator def my_method(): ...
❌ 错误：装饰器看到的是 staticmethod 对象，通常不支持 call

常见错误现象：TypeError: 'staticmethod' Object is not callable 或装饰器逻辑完全没触发。

@property 方法能不能用装饰器？怎么写才安全？

可以，但必须确保装饰器返回的对象也支持描述符协议（即实现 __get__），否则 @property 的取值行为会被破坏。

立即学习“Python免费学习笔记（深入）”；

最稳妥的方式是让装饰器适配描述符——或者更简单：把装饰器放在 @property 内侧：

@property @cache_result  # 假设这个装饰器支持 descriptor 协议 def expensive_value(self):     return compute() 
✅ 推荐：property 包裹已装饰函数
@cache_result @property def expensive_value(self): return compute()
❌ 风险高：若 @cache_result 不处理 get，访问 .expensive_value 会出错

关键点：装饰器是否保留原始函数的描述符行为，取决于它是否转发 __get__。多数通用装饰器（如 functools.wraps 包装的）不自动处理这点。

给实例方法加装饰器时，self 参数为什么会丢失或错位？

这是装饰器未正确处理绑定方法（bound method）的典型表现。如果你写了一个不带 functools.wraps 或未适配 __get__ 的装饰器，python 在调用时可能无法正确提取 self。

实操建议：

• 始终用 functools.wraps(func) 包装装饰器内部函数
• 避免在装饰器里直接返回裸函数；若需修改调用逻辑，确保返回对象能响应 __get__（比如用 types.MethodType 重构，但一般没必要）
• 测试时务必通过实例调用：obj.method()，而不是 MyClass.method(obj)，后者绕过了绑定机制，容易掩盖问题

一个典型错误示例：AttributeError: 'NoneType' object has no attribute 'xxx'，往往是因为装饰器返回了 None 或不支持绑定的对象。

想统一装饰整个类的方法，用 __set_name__ 还是元类？

两者都能做，但适用场景不同：__set_name__ 更轻量，适合单个描述符类（如自定义属性装饰器）；元类适合全局规则（如“所有以 api_ 开头的方法自动加鉴权”）。

性能与维护性考虑：

• 元类在类定义时就介入，不可动态关闭，调试困难；__set_name__ 是惰性的，只在属性被赋值到类上时触发
• 如果只是想“标记+后期扫描”，用类装饰器（@decorate_class）比元类更直观、易测
• 注意：元类 + 装饰器组合容易引发执行顺序问题，比如装饰器在元类 __new__ 之前还是之后运行，依赖具体实现

真正难处理的，是装饰器和多重继承、__slots__、或 typing.get_type_hints 一起用时的兼容性——这些地方没有标准约定，得一个个 case 验证。