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() 看源码，比死记更可靠。
真实项目里，装饰器出问题往往不是不会写，而是忽略了上下文细节：
@functools.wraps(func)，会导致 help()、__name__、__doc__ 全变成包装函数的，单元测试和 API 文档会出错def method(self, ...) 加装饰器，可能收不到 self；要用 functools.partial 或写支持绑定方法的装饰器async def 函数用同步装饰器，会破坏协程对象；必须用 async def 写装饰器，或用 aiostream 等专用库假设 Web 路由需检查用户角色：
from functools import wrapsdef require_role(allowed_roles): def decorator(func): @wraps(func) def wrapper(*args, **kwargs):
假设 request 对象可从上下文获取
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
这个例子展示了参数化、元信息保留、运行时判断三个核心点。上线前记得补上异常处理和日志记录，而不是只抛错。
装饰器不是越复杂越高级，而是越贴合业务场景越有价值。写完一个，问问自己：它是否真的减少了重复？是否让主逻辑更干净？是否方便测试和替换？答案是肯定的，才算落地。