装饰器是Python中通过函数闭包和语法糖实现功能扩展的机制，核心步骤包括定义外层接收函数、内层包装逻辑并返回wrapper；使用functools.wraps可保留原函数元信息；多个装饰器按从内到外顺序执行，适用于日志、权限等分层场景。
装饰器（Decorator），在我看来，是Python语言里一种非常巧妙且强大的设计模式，它本质上就是一个函数，接收另一个函数作为参数，然后返回一个新的函数。它的核心思想在于，你可以在不修改原始函数代码的前提下，动态地给它“包裹”上额外的功能，比如日志记录、权限校验、性能监控、缓存等等。这就像给一个礼物盒外面再套一层包装纸，里面的礼物没变，但外在的呈现或附加价值却增加了。
装饰器的工作原理，其实可以拆解成几个关键点。首先，Python中的函数是“一等公民”，这意味着它们可以像普通变量一样被传递、赋值和返回。其次，闭包（Closure）的概念在这里至关重要：内部函数可以记住并访问其外部（封闭）作用域的变量，即使外部函数已经执行完毕。最后，Python的语法糖
@decorator简化了
func = decorator(func)这种写法，让代码看起来更简洁、更具可读性。当你定义一个函数并用
@decorator修饰时，Python解释器会在函数定义完成后，自动执行
decorator(func)，并将返回的新函数重新绑定到原函数名上。
手写一个Python装饰器，核心步骤有哪些？
要亲手实现一个装饰器，你需要理解它内部的构造逻辑。最基础的结构通常包含一个外层函数和一个内层函数（即
wrapper）。外层函数负责接收被装饰的函数作为参数，而内层函数则是实际执行额外逻辑和调用原始函数的地方。
我们来写一个简单的计时器装饰器，看看它是怎么运作的：
import time
def timer_decorator(func):
"""
一个简单的计时器装饰器，用于测量函数执行时间。
"""
def wrapper(*args, **kwargs):
start_time = time.time()
result = func(*args, **kwargs) # 调用原始函数
end_time = time.time()
print(f"函数 '{func.__name__}' 执行耗时: {end_time - start_time:.4f} 秒")
return result
return wrapper
# 使用装饰器
@timer_decorator
def long_running_function(n):
"""一个模拟耗时操作的函数"""
total = 0
for i in range(n):
total += i * i
time.sleep(0.1) # 模拟一些I/O等待
return total
# 调用被装饰的函数
long_running_function(1000000)
# 输出: 函数 'long_running_function' 执行耗时: 0.1xxx 秒在这个例子中，
timer_decorator就是我们的外层函数，它接收
long_running_function作为
func参数。
wrapper是内层函数，它包裹了
long_running_function的实际调用，并在前后添加了计时逻辑。
wrapper必须能够接受任意参数（
*args,
**kwargs），这样才能确保被装饰的函数无论接受什么参数，都能正常工作。最后，
timer_decorator返回了这个
wrapper函数。当
long_running_function(1000000)被调用时，实际上是
wrapper(1000000)在执行。
装饰器在处理函数元信息时会遇到什么坑？如何使用functools.wraps
解决？
当我们用装饰器包裹一个函数后，会发现一个“副作用”：被装饰后的函数，其一些元信息（如
__name__、
__doc__、
__module__等）会丢失，取而代之的是
wrapper函数的元信息。这在调试、文档生成或者某些依赖函数签名的工具中，可能会引发一些不必要的困扰。比如，如果你尝试打印
long_running_function.__name__，你会得到
wrapper而不是
long_running_function。
这是一个实际的例子：
# 沿用上面的 timer_decorator
@timer_decorator
def another_function():
"""这是另一个函数的文档字符串。"""
print("Hello from another function!")
print(f"原始函数名: {another_function.__name__}")
print(f"原始函数文档: {another_function.__doc__}")
# 输出:
# 原始函数名: wrapper
# 原始函数文档: None显然，这并不是我们想要的结果。为了解决这个问题，Python标准库提供了
functools模块，其中的
wraps装饰器就是专门用来处理这个问题的。
@functools.wraps(func)这个装饰器会将被装饰函数
func的元信息，自动复制到
wrapper函数上。
让我们修改一下
timer_decorator：
import time
import functools # 引入 functools 模块
def timer_decorator_fixed(func):
"""
修复了元信息丢失问题的计时器装饰器。
"""
@functools.wraps(func) # 使用 functools.wraps
def wrapper(*args, **kwargs):
start_time = time.time()
result = func(*args, **kwargs)
end_time = time.time()
print(f"函数 '{func.__name__}' 执行耗时: {end_time - start_time:.4f} 秒")
return result
return wrapper
@timer_decorator_fixed
def yet_another_function():
"""这是又一个函数的文档字符串。"""
print("Hello from yet another function!")
print(f"修复后的函数名: {yet_another_function.__name__}")
print(f"修复后的函数文档: {yet_another_function.__doc__}")
# 输出:
# 修复后的函数名: yet_another_function
# 修复后的函数文档: 这是又一个函数的文档字符串。通过
@functools.wraps(func)，我们确保了
yet_another_function在被装饰后，依然能正确地暴露其原始的元信息，这对于维护代码的清晰性和可调试性至关重要。
链式装饰器（Decorator Chaining）是如何工作的，以及它有什么使用场景？
装饰器的一个很酷的特性是它们可以被“链式”应用，也就是一个函数可以同时被多个装饰器修饰。这就像层层叠叠的包装，每个装饰器都在前一个装饰器返回的新函数上再加一层功能。
当你在一个函数上应用多个装饰器时，例如：
@decorator_a
@decorator_b
def my_function():
pass它的执行顺序是从“最靠近函数”的装饰器开始，向外层依次应用。等价于：
my_function = decorator_a(decorator_b(my_function))
这意味着
decorator_b会先装饰
my_function，返回一个新函数
new_my_function_b。然后，
decorator_a再装饰这个
new_my_function_b，最终返回的函数才是绑定到
my_function上的。
一个常见的应用场景是权限校验和日志记录的组合。假设你有一个API端点，既需要验证用户身份，又需要记录每次访问。
import functools
def log_access(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
print(f"访问日志: 调用函数 '{func.__name__}'")
return func(*args, **kwargs)
return wrapper
def require_admin(func):
@functools.wraps(func)
def wrapper(*args, **kwargs):
# 实际场景中会检查用户session或token
is_admin = True # 简化示例，假设总是管理员
if is_admin:
print(f"权限检查: 用户是管理员，允许访问 '{func.__name__}'")
return func(*args, **kwargs)
else:
print(f"权限检查: 用户不是管理员，拒绝访问 '{func.__name__}'")
raise PermissionError("需要管理员权限")
return wrapper
@log_access
@require_admin
def delete_critical_data(user_id):
"""删除关键数据，仅限管理员操作并记录日志"""
print(f"正在删除用户 {user_id} 的关键数据...")
return f"数据已删除 for user {user_id}"
# 尝试调用
try:
print(delete_critical_data(123))
except PermissionError as e:
print(e)
# 预期输出:
# 权限检查: 用户是管理员，允许访问 'delete_critical_data'
# 访问日志: 调用函数 'delete_critical_data'
# 正在删除用户 123 的关键数据...
# 数据已删除 for user 123在这个例子中，
delete_critical_data函数首先被
require_admin装饰，然后
log_access装饰器再包裹
require_admin返回的函数。当调用
delete_critical_data时，最外层的
log_access的
wrapper会先执行，然后它会调用
require_admin的
wrapper，
require_admin的
wrapper在权限通过后，最终才会调用原始的
delete_critical_data函数。这种分层处理逻辑的方式，让代码职责分离，模块化程度更高，也更易于维护。不过，需要注意装饰器的顺序，因为它会影响功能的执行次序。
