装饰器加在@staticmethod/@classmethod外侧会失效，因其作用于描述符而非函数；应置于内侧。@property同理，装饰器需支持__get__协议。实例方法装饰须用functools.wraps避免self丢失。
装饰器加在 @staticmethod 和 @classmethod 上为什么失效？
因为 @staticmethod 和 @classmethod 本身返回的是描述符对象，不是普通函数。装饰器如果直接套在它们上面，会作用于这些描述符，而不是底层可调用对象，导致被装饰的逻辑根本不会执行。
正确做法是把装饰器放在 @staticmethod/@classmethod 内侧，也就是先装饰原函数，再用静态/类方法包装：
@my_decorator @staticmethod def my_method(): ... <h1>✅ 正确：装饰器看到的是普通函数</h1><p>@staticmethod @my_decorator def my_method(): ...</p><h1>❌ 错误：装饰器看到的是 staticmethod 对象，通常不支持 <strong>call</strong>
常见错误现象：TypeError: 'staticmethod' object is not callable 或装饰器逻辑完全没触发。
@property 方法能不能用装饰器？怎么写才安全？
可以，但必须确保装饰器返回的对象也支持描述符协议（即实现 __get__），否则 @property 的取值行为会被破坏。
立即学习“Python免费学习笔记（深入）”；
最稳妥的方式是让装饰器适配描述符——或者更简单：把装饰器放在 @property 内侧：
@property
@cache_result # 假设这个装饰器支持 descriptor 协议
def expensive_value(self):
return compute()
<h1>✅ 推荐：property 包裹已装饰函数</h1><p>@cache_result
@property
def expensive_value(self):
return compute()</p><h1>❌ 风险高：若 @cache_result 不处理 <strong>get</strong>，访问 .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 验证。
