回答。

在Python中，装饰器历史上是使代码更紧凑、更易读的一种方式，通过对函数和方法的重复行为进行封装。在@decorator语法出现之前，装饰器是显式应用的，这使得代码的理解变得复杂。如今，装饰器在组织逻辑、重复检查、日志记录、缓存等方面发挥着关键作用。

使用装饰器时的问题在于正确处理函数、实例方法和静态/类方法之间的差异。经常会出现与方法信息丢失、self的延迟/提前绑定，以及函数签名有关的错误。

解决方案是在编写通用装饰器时使用模块functools.wraps来保留元数据，并且要密切关注被装饰对象的类型（例如，正确考虑实例方法将self作为第一个参数）。

代码示例：

import functools

def my_decorator(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        print(f"Before function: {func.__name__}")
        result = func(*args, **kwargs)
        print(f"After function: {func.__name__}")
        return result
    return wrapper

class Example:
    @my_decorator
    def method(self, x):
        print(f"Method called with {x}")

ex = Example()
ex.method(5)

关键特性：

• 方法级别的装饰器接收一个期望第一个参数为self的函数。
• 为了保留原始元数据，建议使用functools.wraps。
• 装饰器可以参数化以增加灵活性。

误导性问题。

如果在类方法上使用了为函数编写的装饰器，是否必须使用functools.wraps，self会怎样？

不，装饰器本身可以工作，但如果没有wraps，函数名、IDE支持和文档都会丢失。Self仍然将是第一个参数，但元数据的丢失会使调试和反射变得困难。

def bad_decorator(f):
    def wrapper(*args, **kwargs):
        print("decorated")
        return f(*args, **kwargs)
    return wrapper

class Test:
    @bad_decorator
    def foo(self):
        pass
print(Test().foo.__name__)  # wrapper

同一个装饰器能否同时应用于实例方法和静态方法？

可以，但需要记住：静态方法不将self作为第一个参数。如果装饰器期望处理self，那么使用@staticmethod/@classmethod会导致错误。

装饰器如何影响方法的签名和自动补全？

最简单的说：如果没有functools.wraps，签名和文档字符串会丢失，IDE和许多自动提示工具将无法正确工作。

常见错误和反模式

• 不使用functools.wraps — 丢失函数名、文档字符串，使调试更困难。
• 装饰器为函数编写，没有考虑self的存在 — 在方法上工作不正常。
• 重新使用相同的装饰器而不考虑上下文（静态/类方法/普通方法）。

现实生活中的例子

消极案例：在类的所有方法上使用没有functools.wraps的装饰器。
优点：快速原型，能够工作。
缺点：无法通过堆栈搜索错误，IDE不提供签名。

积极案例：装饰器使用functools.wraps，代码进行了文档化。
优点：可读性、可维护性、IDE友好。
缺点：对语法和注意力的最小添加。