装饰器是python中用于包装或修改函数、方法或类行为的高阶函数，无需修改原代码即可添加日志、计时、权限校验等横切关注点。其核心语法为@decorator_name，本质是将函数作为参数传入装饰器并返回新函数。使用functools.wraps可保留原函数元信息，避免调试困难。带参数的装饰器需多一层嵌套结构，如@log_level(level=”DEBUG”)。装饰器解决了代码重复和关注点分离问题，广泛应用于Web路由（@app.route）、权限控制（@login_required）、限流、缓存（@lru_cache）和重试机制等场景，提升代码模块化与可维护性。最佳实践包括单一职责、通用性设计、异常处理和避免滥用。
Python中的装饰器，说白了，就是一种特殊类型的函数，它的核心作用是用来包装或修改另一个函数、方法或类的行为，而不需要直接改动被包装对象的源代码。你可以把它想象成给一个函数穿上了一件外套，这件外套可以在函数执行前后添加额外的功能，比如日志记录、性能计时、权限检查等等。它让我们的代码变得更“干净”，更模块化，尤其是在处理那些跨越多个功能模块的“横切关注点”时，简直是神器。
要理解装饰器怎么用，我们得从最基础的语法和它背后的原理说起。
最常见的装饰器用法，就是直接在函数定义上方加上
@decorator_name
。这其实是Python提供的一个语法糖，它的本质是：
def original_function(): pass # 等价于 original_function = decorator_name(original_function)
所以，装饰器本身就是一个接受函数作为参数，并返回一个新函数（通常是内部定义的
wrapper
函数）的高阶函数。
立即学习“Python免费学习笔记（深入）”；
我们来看一个最简单的例子，用来记录函数执行的日志：
import functools def log_calls(func): # functools.wraps 是个好东西，它能把原函数的元信息（比如名字、文档字符串）复制到wrapper函数上 @functools.wraps(func) def wrapper(*args, **kwargs): print(f"INFO: Calling function '{func.__name__}' with args: {args}, kwargs: {kwargs}") result = func(*args, **kwargs) print(f"INFO: Function '{func.__name__}' finished, returned: {result}") return result return wrapper @log_calls def add(a, b): """计算两个数的和。""" print(f"Inside add: {a} + {b}") return a + b @log_calls def subtract(x, y): """计算两个数的差。""" print(f"Inside subtract: {x} - {y}") return x - y # 使用被装饰的函数 sum_result = add(10, 5) print(f"Sum result: {sum_result}n") diff_result = subtract(y=3, x=7) print(f"Diff result: {diff_result}") print(f"Name of decorated add function: {add.__name__}") # 输出 'add' 而不是 'wrapper'，多亏了 @functools.wraps print(f"Docstring of decorated add function: {add.__doc__}")
在这个例子里，
log_calls
就是我们的装饰器。它接收
add
或
subtract
函数作为参数，然后定义了一个内部函数
wrapper
。
wrapper
在调用原始函数前后打印日志，最后返回原始函数的结果。
log_calls
最终返回的就是这个
wrapper
函数。
如果你需要装饰器本身也接收参数，比如你想控制日志的级别，那就需要再多一层嵌套：
import functools def log_level(level="INFO"): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): print(f"[{level}] Calling '{func.__name__}'...") result = func(*args, **kwargs) print(f"[{level}] Finished '{func.__name__}'.") return result return wrapper return decorator @log_level(level="DEBUG") def process_data(data): """处理一些数据。""" print(f"Processing: {data}") return f"Processed: {data}" @log_level() # 不传参数，使用默认的INFO级别 def fetch_config(key): """获取配置项。""" print(f"Fetching config for {key}") return {"key": key, "value": "some_value"} process_data([1, 2, 3]) fetch_config("database_url")
这里
log_level
首先是一个工厂函数，它接收装饰器所需的参数（比如
level
），然后返回真正的装饰器函数
decorator
。这个
decorator
函数才是我们熟悉的那个接受函数作为参数并返回
wrapper
的结构。
为什么Python需要装饰器，它解决了什么痛点？
我个人觉得，装饰器最核心的价值，在于它提供了一种优雅的方式来处理“横切关注点”（Cross-Cutting Concerns）。什么是横切关注点？简单来说，就是那些散布在程序中多个模块，但又不属于任何一个模块核心业务逻辑的功能。最典型的就是日志、性能监控、事务管理、权限校验、缓存等。
想象一下，如果你有几十个甚至上百个函数都需要添加日志记录。如果没有装饰器，你可能得在每个函数的开头和结尾手动插入日志代码。这不仅会让代码变得臃肿、难以阅读，而且一旦日志逻辑需要修改（比如从打印到文件改成打印到数据库），你得修改所有这些地方。这简直是维护者的噩梦，也极大地增加了出错的风险。
装饰器就像一个“即插即用”的插件系统。它把这些横切关注点从核心业务逻辑中剥离出来，让你的业务函数只专注于它应该做的事情。比如一个计算函数就只管计算，至于计算前后的日志、计时，那是装饰器的事情。这种分离关注点的设计，让代码更具可读性、可维护性和可扩展性。我记得刚开始接触Python时，看到
@
符号觉得很神奇，深入了解后才发现，这背后藏着一种非常强大的设计哲学。它把一些原本可能需要AOP（面向切面编程）框架才能实现的功能，用Python自身简洁的语法就搞定了，这不得不说是一种语言层面的智慧。
编写自定义装饰器时，有哪些常见的陷阱和最佳实践？
在自己动手写装饰器的时候，我踩过不少坑，也总结了一些经验。
一个最常见的陷阱就是忘记使用
functools.wraps
。如果你不加它，被装饰的函数会“丢失”它原本的元信息，比如它的名字（
__name__
）、文档字符串（
__doc__
）、参数签名等。在调试、生成文档或者依赖这些元信息的场景下，这会带来很大的麻烦。比如上面的
add.__name__
如果不加
@functools.wraps
，会输出
wrapper
而不是
add
。这听起来可能不严重，但在复杂的系统里，这会让调试变得像大海捞针。所以，把
@functools.wraps(func)
放在你的
wrapper
函数定义前，几乎应该成为一种习惯。
另一个我常犯的错误，是在
wrapper
函数里没有正确处理参数。如果你只是简单地写
def wrapper(arg1, arg2):
，那么你的装饰器就只能用于那些恰好有两个位置参数的函数。正确的做法是使用
*args
和
**kwargs
来捕获所有位置参数和关键字参数，这样你的装饰器才能通用地应用于各种参数签名的函数。
至于最佳实践，我觉得有几点特别重要：
- 单一职责原则： 一个装饰器最好只做一件事情。比如一个装饰器只负责日志，另一个只负责计时。这样它们更易于理解、测试和组合。
- 保持通用性： 尽量让你的装饰器能够应用于多种场景。这意味着你需要考虑参数化，就像我们上面
log_level
的例子那样。
- 异常处理： 如果你的装饰器在执行前后添加了逻辑，考虑这些逻辑本身是否会抛出异常，以及如何处理被包装函数可能抛出的异常。有时，你可能需要在
wrapper
内部添加
try...except
块。
- 清晰的文档： 为你的装饰器写好文档字符串，说明它的作用、参数和使用方式。这对于团队协作和未来的维护至关重要。
- 避免过度使用： 装饰器虽然强大，但也不是万能药。在某些简单场景下，直接调用辅助函数可能比引入装饰器更清晰。
装饰器在实际项目中都有哪些高级应用场景？
装饰器这玩意儿，一旦你掌握了它，会发现它在实际项目中简直无处不在，而且能解决很多“头疼”的问题。
最直观的，就是各种Web框架里的应用。比如flask或Django，
@app.route('/path')
就是最经典的路由装饰器，它把URL路径和处理函数关联起来。还有像
@login_required
（检查用户是否登录）、
@permission_required('admin')
（检查用户权限）这些，它们在执行视图函数前，就完成了身份验证和权限校验，如果条件不满足，直接返回错误或重定向，根本不让业务逻辑有机会执行。这极大地简化了Web应用的开发。
再比如API限流。如果你有一个对外开放的API，为了防止恶意请求或者系统过载，你可能需要限制某个用户或某个IP在一定时间内的请求次数。这时，你可以写一个
@rate_limit(calls_per_minute=10)
这样的装饰器。它会在每次api调用前检查请求计数器，如果超限就直接拒绝。
缓存（Memoization）也是一个非常棒的应用场景。Python标准库里的
functools.lru_cache
就是一个很好的例子。当你有一个计算成本很高，但输入参数不变时输出结果也固定的函数，你就可以用
@functools.lru_cache()
来装饰它。这样，函数第一次执行时会计算结果并缓存起来，后续再用相同的参数调用时，直接从缓存中取结果，大大提升了性能。我用它优化过一些递归函数，效果立竿见影。
还有**重试
评论（已关闭）
评论已关闭