Python装饰器本质是高阶函数与闭包的结合，通过替换函数调用入口来增强行为，不修改原函数代码，而是返回新包装函数供后续调用。
Python装饰器的本质，是函数式编程中“高阶函数”和“闭包”的自然结合。 它不是语法糖的炫技，而是解决重复逻辑、增强函数行为的实用工具。理解它，关键不在记写法，而在看清调用链路里对象怎么流转、什么时候执行。
装饰器到底在改什么？
装饰器修改的不是原函数的代码，而是原函数被调用时的实际入口。当你写 @log_time，实际是把 func 作为参数传给 log_time，而 log_time 返回一个新函数——后续所有对 func() 的调用，真正执行的是这个新函数。
- 原函数对象依然存在，可通过
func.__wrapped__（如果用了@functools.wraps）访问 - 装饰器函数本身只运行一次（在定义阶段），但其返回的“包装函数”会在每次调用时执行
- 没有
@语法，你也能手动实现：my_func = timer(logger(my_func))
带参数的装饰器：多一层函数嵌套
像 @retry(max_times=3) 这类带参数的装饰器，本质是“返回装饰器的函数”。它有三层结构：
- 最外层接收装饰器参数（如
max_times），返回真正的装饰器 - 中间层接收被装饰函数，返回包装函数
- 最内层是实际执行逻辑（含重试、日志、校验等）
别硬背三层命名，记住：每多一个括号，就多一层闭包封装。调试时打印各层函数的 id() 或用 inspect.getsource() 看源码，比死记更可靠。
立即学习“Python免费学习笔记（深入）”；
实战中容易踩的坑
真实项目里，装饰器出问题往往不是不会写，而是忽略了上下文细节：
-
元信息丢失：不加
@functools.wraps(func)，会导致help()、__name__、__doc__全变成包装函数的，单元测试和 API 文档会出错 -
类方法装饰失效：直接对
def method(self, ...)加装饰器，可能收不到self；要用functools.partial或写支持绑定方法的装饰器 -
异步函数混用：给
async def函数用同步装饰器，会破坏协程对象；必须用async def写装饰器，或用aiostream等专用库
从零写一个权限校验装饰器
假设 Web 路由需检查用户角色：
from functools import wraps
<p>def require_role(allowed_roles):
def decorator(func):
@wraps(func)
def wrapper(*args, **kwargs):</p><h1>假设 request 对象可从上下文获取</h1><pre class="brush:php;toolbar:false;"> user = get_current_user() # 自行实现
if user.role not in allowed_roles:
raise PermissionError(f"Role {user.role} not allowed")
return func(*args, **kwargs)
return wrapper
return decorator使用
@require_role(['admin', 'editor']) def publish_article(): pass
这个例子展示了参数化、元信息保留、运行时判断三个核心点。上线前记得补上异常处理和日志记录，而不是只抛错。
装饰器不是越复杂越高级，而是越贴合业务场景越有价值。写完一个，问问自己：它是否真的减少了重复？是否让主逻辑更干净？是否方便测试和替换？答案是肯定的，才算落地。
