装饰器是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
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
函数。这种分层处理逻辑的方式，让代码职责分离，模块化程度更高，也更易于维护。不过，需要注意装饰器的顺序，因为它会影响功能的执行次序。
评论（已关闭）
评论已关闭