Python装饰器核心原理与实战：从包装函数到项目落地

1. 先从一段看起来很魔法的代码说起刚接触Python的人十有八九见过这样的代码timer def get_data(): ...然后心里冒出一个问号这个带的玩意儿到底是什么为什么它能把一个普通函数包一层我当初学装饰器的时候也经历过一段会用但说不清的迷糊期——知道拿login_required往视图函数上一放就能做登录校验知道staticmethod可以让方法变成静态方法但你要是让我亲手写一个带参数的装饰器我大概率会卡壳。后来写了两年多业务代码把日志、缓存、重试、权限校验这些逻辑反复用装饰器落地之后我才真正摸清它的脾气。这篇就好好聊聊Python装饰器到底怎么回事、怎么写不踩坑、以及实际项目里它到底是用来解决什么问题的。不管你是刚写完爬虫、正准备做数据分析的初学者还是已经写了一些业务代码想进阶的开发者这篇文章都会对你有用。我要先强调的是装饰器不是一个高级到只有大神才能用的东西它本质上就是一个普通函数只不过这个函数的参数和返回值都是函数。搞懂这一点后面所有花哨写法都不算事。2. 装饰器到底在做什么——先拆开揉碎看本质2.1 函数在Python里也是数据要说清楚装饰器必须先接受一个对很多初学者来说有点反直觉的事实在Python里函数是一种对象可以像整数、字符串一样被传递、被返回、被赋值给变量。def say_hello(): return hello # 把函数赋值给另一个变量 greet say_hello print(greet()) # 输出 hello # 把函数当作参数传进另一个函数 def call(func): return func() print(call(say_hello)) # 输出 hello这里你看到的两件理所当然的事——函数能赋值、函数能传参——就是装饰器的地基。用生活化的话来说函数就像一把通用的工具你可以把这把工具递给别人用别人也可以把这把工具加工一番再还给你。2.2 装饰器的原始形态就是一个包装函数既然函数能接收函数作为参数也能返回一个新的函数那我不就可以写这样一个东西def my_decorator(func): def wrapper(): print(调用前做点什么) result func() print(调用后做点什么) return result return wrapper这个my_decorator接收一个函数func然后在内部定义一个wrapper在调用func前后各塞了一段逻辑最后把这个wrapper返回出去。注意到这一步原来的func并没有被修改。Python里的函数对象一旦创建它的代码体是固定的装饰器做的事是拿一个新函数把它包起来调用的时候实际上跑的是新函数新函数内部再调旧函数。这种在一个函数外面再包一层函数的做法跟快递柜的包裹代收很像你原本的收件流程是快递员→你加了快递柜之后变成快递员→快递柜→你。快递柜可以在中间帮你完成代收、保管、记录你拿到包裹的体验其实没变但整个过程多了一层可控性。2.3语法糖到底做了什么上面那种写法在Python 2时代就有了但写起来很啰嗦def get_data(): ... get_data my_decorator(get_data)每次装饰完还要重新赋值一次非常容易漏写。Python 2.4引入了语法糖让你可以直接这样写my_decorator def get_data(): ...这两段代码在语义上完全等价。my_decorator放在函数定义上方Python解释器执行到这一行的时候会把下面定义的函数对象取出来传给my_decorator再把返回值重新赋值给函数名get_data。所以不是玄学它只是一个我懒得写get_data my_decorator(get_data)的快捷方式。语法糖的本质是简化写法不改变底层机制。注意装饰器是在函数定义的时候立刻执行的不是在函数调用的时候执行的。很多新手以为是在函数每次被调用时才包装一次其实不对。模块加载时装饰器就跑完了wrapper已经准备好了后面每次调用都是直接调wrapper。2.4 为什么需要装饰器——从实际问题出发假设你在写一个电商系统的下单接口随着需求迭代你先后需要给这个接口加这些功能记录调用日志统计耗时校验用户是否登录万一调用失败要自动重试把计算结果缓存起来如果直接在业务函数里加这些逻辑函数会迅速膨胀到几百行而且下单接口、查询接口、退款接口都要面对相同的需求你会在每个函数里复制粘贴同一段逻辑。装饰器的价值就是把横切在多个函数头上的这些通用旁路逻辑抽离出来写成独立的、可复用的组件然后像贴标签一样往函数上一放。这跟你装修房子是一样的思路水管电路日志、鉴权、缓存是横贯整个房子的公共设施不是只在卧室里才有需求。把它们集中布好每个房间想用就直接接上而不是每个房间单独埋一套。3. 核心细节与实操要点——写出不炸的装饰器3.1 无参装饰器最基础的写法先看一个最简单的无参装饰器它不接收额外参数只包装目标函数import functools import time def timer(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() result func(*args, **kwargs) cost time.perf_counter() - start print(f函数 {func.__name__} 耗时 {cost:.6f} 秒) return result return wrapper timer def compute(): time.sleep(0.1) return 42 print(compute())这里的*args, **kwargs是装饰器里的关键点。你写的普通函数可能有位置参数、关键字参数、可变参数为了让wrapper能转发任意形式的参数最稳妥的写法就是def wrapper(*args, **kwargs): ...然后在内部用func(*args, **kwargs)调用原函数。这样它就能适配任何签名。为什么需要functools.wraps后面[章节4]我会详细讲这里先记住一行字functools.wraps(func)能把原函数的名字、文档字符串、参数信息复制到wrapper上否则你的函数在别人眼里会变成一个叫wrapper的陌生人。3.2 带参装饰器多套一层工厂很多场景下装饰器本身需要参数。比如你想控制日志级别import functools import logging def log_with(level): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): logging.log(level, f调用 {func.__name__}) return func(*args, **kwargs) return wrapper return decorator log_with(logging.INFO) def business_func(): ...这个写法很多人第一次看会懵为什么外面还要包一层因为log_with(logging.INFO)的执行顺序是先调用log_with(logging.INFO)得到decorator这个函数再用它去装饰business_func。也就是说你希望日志级别这个参数在装饰之前就确定下来所以必须通过外层函数的参数传递。用一句话记住结构最外层log_with接收装饰器的参数返回内层装饰器中间层decorator接收目标函数返回wrapper最内层wrapper接收原函数调用时的参数执行真正的逻辑带参装饰器相当于一个装饰器工厂。淘宝上买的普通贴纸无参装饰器是现成的直接贴就行定制贴纸带参装饰器需要你先告诉店家印什么字等他做出来你再贴。这个先定制、再贴的过程就是多包了最外层那层壳。3.3 类装饰器用类当装饰器函数装饰器用久了你会发现有的场景需要保存状态比如统计一个函数被调用了多少次。用函数闭包写也行但用类会更直观因为类的实例天然可以挂在状态import functools class Counter: def __init__(self, func): functools.update_wrapper(self, func) self.func func self.count 0 def __call__(self, *args, **kwargs): self.count 1 print(f调用次数: {self.count}) return self.func(*args, **kwargs) Counter def ping(): return pong ping() ping() print(ping.count) # 2这里Counter等价于ping Counter(ping)。由于Counter实例实现了__call__方法它本身可调用所以ping()最终会走到实例的__call__在调用原函数之前把计数加一。类装饰器适合什么场景需要维护装饰器自身的状态计数器、缓存容器、连接池想把逻辑组织得更清晰方便扩展方法但它也有缺点类实例在内存里的开销比闭包大一点而且如果你不调用functools.update_wrapper函数的元信息同样会丢失。所以我个人建议简单的用函数装饰器复杂的才上类装饰器。3.4 内置装饰器你其实早就用过了Python自带了不少装饰器很多人在写代码时天天用却没意识到它们是装饰器property把一个方法变成属性访问比如obj.name而不是obj.name()staticmethod静态方法不需要实例也能调用classmethod类方法接收cls作为第一个参数functools.lru_cache对函数结果做缓存递归计算时效果极佳dataclass严格来说是类装饰器自动生成__init__、__repr__等方法以lru_cache为例它解决的是同一个输入反复计算的问题import functools functools.lru_cache(maxsize128) def fib(n): if n 2: return n return fib(n - 1) fib(n - 2)lru_cache内部维护了一个字典把(n)映射到计算结果。下次调用如果参数相同直接从缓存里取不再执行函数体。用递归算斐波那契数列时这个装饰器能把时间复杂度从指数级降到线性级效果立竿见影。3.5 多个装饰器叠加时的执行顺序装饰器可以叠加但顺序不能乱a b def f(): ...它等价于f a(b(f))。什么意思先执行b(f)得到b_f再执行a(b_f)得到a_b_f最终f指向a_b_f每次调用f()先进入a的逻辑再进入b的逻辑最后才执行原来的函数体这就是洋葱模型。你从最外层切进去逐层剥到最里面再逐层退出来。所以在实际业务里装饰器的顺序是有讲究的。比如一个视图函数需要同时做登录校验和权限校验如果login_required写在permission_required外面那么请求会先经过登录校验再经过权限校验。如果你顺序写反了可能出现未登录用户先被拿去验证权限这种尴尬局面。规则很简单先执行的装饰器离函数最近的那个先包装后执行的装饰器在最外层调用时最外层的逻辑先跑。4. 实操过程与核心环节实现——四个可落地的装饰器下面我用一个接近真实的业务场景把装饰器完整的落地过程走一遍。假设你正在写一个订单处理的脚本涉及从外部API拉取数据、解析、写库的完整流程我要在不污染业务函数的前提下给它加上日志、耗时统计、失败重试和结果缓存四个能力。4.1 第一步搭建基础函数先写一个模拟的业务函数假装从某个接口拉取订单数据import random def fetch_orders(): 从订单服务拉取当天的订单列表 # 模拟网络请求偶尔失败 if random.random() 0.3: raise ConnectionError(网络超时连接订单服务失败) return [{order_id: i, amount: i * 100} for i in range(3)]现在这个函数有两个问题它有30%概率抛异常直接调用的话程序就断了每次调用都重新请求一次没有缓存浪费资源4.2 第二步写日志装饰器日志装饰器的核心需求记录函数名、参数、返回值或异常但不能改变原函数的返回结果。import functools import logging import time logging.basicConfig(levellogging.INFO) def log_call(func): functools.wraps(func) def wrapper(*args, **kwargs): logging.info(f开始调用 {func.__name__}, args{args}, kwargs{kwargs}) try: result func(*args, **kwargs) logging.info(f{func.__name__} 执行成功, 结果长度: {len(result) if hasattr(result, __len__) else N/A}) return result except Exception as e: logging.error(f{func.__name__} 执行失败: {e}) raise return wrapper注意这里的try/except结构不要只在失败时打日志然后吞掉异常正确的做法是记录完日志后raise把异常继续抛出去让上层调用方决定怎么处理。日志装饰器只负责记录不负责处理。注意日志装饰器里len(result)不能直接写因为有些函数返回的是整数、布尔值不一定有长度。我用了hasattr(result, __len__)先判断一下这是一个很实际的防御性写法。4.3 第三步写耗时统计装饰器耗时统计的关键点是起点和终点的采样时机。起点应该在func调用之前终点在func返回之后。如果你把采样点放在wrapper的外面得到的时间会包含所有内部逻辑的耗时这在多个装饰器叠加时会产生偏差。def time_it(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() result func(*args, **kwargs) cost_ms (time.perf_counter() - start) * 1000 logging.info(f{func.__name__} 耗时 {cost_ms:.2f} ms) return result return wrapper这里用time.perf_counter()而不是time.time()是因为perf_counter是专门为测量短时间间隔设计的精度更高不受系统时间调整的影响。统计某段代码的耗时perf_counter是首选。耗时统计装饰器和日志装饰器叠加使用时执行顺序会影响计时的范围。比如log_call time_it def fetch_orders(): ...调用时先进入log_call的wrapper记录开始调用然后调用time_it的wrapper在这里计时然后调用原函数。计时范围只包含原函数本身不包含日志装饰器自己的打印耗时。如果你把顺序倒过来time_it log_call def fetch_orders(): ...计时的起点在log_call的入口终点在它的出口打印日志的时间也被算进去了。这个差别通常只有零点几毫秒但在精确测量的场景下会有影响需要心里有数。4.4 第四步写失败重试装饰器重试装饰器是业务里最常用的。它的核心参数是retries重试次数和delay每次重试的间隔时间。import time def retry(retries3, delay1, exceptions(Exception,)): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, retries 1): try: return func(*args, **kwargs) except exceptions as e: if attempt retries: logging.error(f{func.__name__} 重试 {retries} 次后仍失败: {e}) raise logging.warning(f{func.__name__} 第 {attempt} 次调用失败: {e}, {delay} 秒后重试) time.sleep(delay) return wrapper return decorator有几个细节是真正踩过坑才会注意到的exceptions(Exception,)这个参数很重要。如果你不指定默认捕获所有Exception包括KeyboardInterrupt和系统退出信号吗不会BaseException才包含那些Exception不包括KeyboardInterrupt。但你也要注意有些异常不值得重试比如参数错误、权限不足这些重试一百次也不会成功。所以调用方最好显式指定重试哪些异常例如retry(retries2, exceptions(ConnectionError, TimeoutError))。return func(*args, **kwargs)在try块里一旦成功就立刻返回不会继续进入下一次循环。你不需要额外写break或else。重试前的delay要不要加抖动在高并发场景下所有失败请求同时睡一样的秒数再同时重试会造成惊群效应。如果你用在爬虫或定时任务里建议delay delay * random.uniform(0.5, 1.5)加一点随机抖动。4.5 第五步写结果缓存装饰器数据重复计算是性能浪费的大头。缓存装饰器的核心是把函数参数和计算结果放进一个字典里下次同样的参数直接命中返回。def cache_result(func): cache {} functools.wraps(func) def wrapper(*args, **kwargs): # 构建缓存key注意顺序无关的kwargs要排序 key (args, tuple(sorted(kwargs.items()))) if key in cache: logging.info(f{func.__name__} 命中缓存, 返回上次结果) return cache[key] result func(*args, **kwargs) cache[key] result return result return wrapper手动写缓存装饰器要特别注意一点key必须能被哈希否则字典会报错。args和tuple(sorted(kwargs.items()))都是可哈希的元组可以放心用。但如果args里的元素是列表、字典这类可变对象就需要先转成元组或做序列化。不过说实话生产环境里一般不要自己写缓存装饰器直接用functools.lru_cache省心很多。我写这个是为了展示内部原理让你知道lru_cache不是魔法它就是一个在函数外面包了层带字典缓存的wrapper。4.6 完整组合四个装饰器一起上把前面几个装饰器组合在一起看一下完整效果log_call time_it retry(retries3, delay0.5, exceptions(ConnectionError,)) cache_result def fetch_orders(): 从订单服务拉取当天的订单列表 if random.random() 0.3: raise ConnectionError(网络超时连接订单服务失败) return [{order_id: i, amount: i * 100} for i in range(3)] for _ in range(5): try: print(fetch_orders()) print(---) except Exception: print(最终失败) break这个叠加很有意思。按洋葱模型分析log_call是最外层记录开始、成功或失败的日志time_it在第二层统计整个调用的耗时retry在第三层捕获ConnectionError并重试cache_result在最内层先查缓存如果命中了立即返回不再进入fetch_orders原函数调用流程是log_call入口 →time_it计时开始 →retry尝试调用 →cache_result查缓存 → 如果缓存没命中执行原函数如果失败抛出ConnectionErrorretry捕获并重试重新走cache_result最终成功时按原路返回time_it计算耗时并记录log_call记录成功。这里有个很隐蔽但值得注意的地方retry里重新尝试的是调用装饰后的函数还是调用原函数如果我把retry写在cache_result外面那么重试时也会先查缓存但因为第一次调用已经抛异常了缓存里不会有记录所以查了也白查逻辑上没毛病。但如果把retry写在cache_result里面每次重试的是原函数就不能在重试之间共享缓存状态了。所以装饰器的排列顺序决定了每个装饰器能看到其他装饰器的行为效果。实际建议不要在一开始就把四个装饰器全堆上去。先加retry解决函数不稳定再加cache_result减少重复计算最后按需加日志和耗时统计。每加一个就跑一遍测试用例确保没有破坏原来的行为。5. 常见问题与排查技巧实录这个章节里的内容每条都是我或身边同事实际踩过的坑按出现频率从高到低排列。5.1 函数名字变了__name__被覆盖不加functools.wraps时原函数的所有元信息都会丢失def my_wrapper(func): def inner(*args, **kwargs): return func(*args, **kwargs) return inner my_wrapper def add(): 两数相加 ... print(add.__name__) # inner而不是 add print(add.__doc__) # None后果是什么调试时日志里打印的函数名全部变成inner排查问题很痛苦某些框架比如Flask、Django依赖视图函数的__name__做路由注册名字变了会导致路由功能异常基于文档字符串的自动化测试工具识别不到函数解决方案只有一个在inner前面加functools.wraps(func)。它做的事情是调用functools.update_wrapper把func的__name__、__doc__、__module__、__qualname__等属性复制到inner上。5.2 带参装饰器写成了两层而不是三层我见过很多新手写带参装饰器时少包一层def log_with(level): def decorator(func): ... return decorator少了一层把level参数和func参数放在同一个函数里def log_with(level, func): ... return wrapper这种写法在log_with(logging.INFO)时直接报错因为log_with(logging.INFO)只传了一个参数level但func没传。用一句话记结构带参装饰器一定要有三层外层接参数、中层接函数、内层接调用参数。如果哪天你写完发现装饰器在定义阶段就报missing 1 required positional argument九成是这里出了问题。5.3 装饰器里的变量是共享的看这个缓存装饰器的经典坑# 每次装饰都会创建一个新的cache dict吗 def cache_result(func): cache {} ...答案是会的。每次应用装饰器时cache_result(func)都会执行一次函数体内的cache {}会创建独立的新字典互不共享。所以不同函数的缓存是隔离的。但如果你把缓存字典定义在模块级别那么所有被这个装饰器包装的函数会共享同一个字典这时如果两个函数刚好有相同参数会互相串结果cache {} def cache_result(func): def wrapper(*args, **kwargs): key (func.__name__, args, tuple(sorted(kwargs.items()))) ...所以共享状态的规则是定义在装饰器函数内部的变量每个被装饰函数独立定义在外部的大家共享。你在设计时需要想清楚要哪种。lru_cache之所以允许maxsize参数就是让每个函数有自己独立的缓存空间。5.4 装饰器自己吃掉了返回值或者异常这是最隐蔽的坑。看下面的错误示范def log_call(func): def wrapper(*args, **kwargs): result func(*args, **kwargs) print(调用了) # 忘记 return result return wrapper如果wrapper里面不return result那么调用add(1, 2)会返回None而不是3。这个问题不仅在装饰器里存在在任何包装函数里都存在。你包装的那层只是中间商不能把货吞了。类似的如果写def safe_call(func): def wrapper(*args, **kwargs): try: return func(*args, **kwargs) except Exception: print(出错了) # 不重新raise return wrapper异常确实被拦住了但调用方完全不知道发生了什么后续程序会带病运行排查问题时你会发现一些数据写了一半、资源没释放的诡异现象。我的经验法则是装饰器默认要返回原函数的结果装饰器默认要把捕获的异常重新抛出去除非你非常明确要在某一层做短路处理否则不要轻易吞掉异常5.5 装饰器装饰类方法时self跑哪儿去了装饰器用在类方法上时有一个特殊之处self被传入wrapper的第一个位置参数。class Service: log_call def handle(self, data): return data s Service() s.handle(x) # wrapper接到的args (s, x)如果你的装饰器里写func(*args, **kwargs)self会被正常传递给原方法没问题。但如果你的装饰器想额外处理第一个参数就要注意args[0]是self不是业务参数。有些装饰器是给函数写的直接拿args[0]当业务参数处理装饰在类方法上就全乱套了。解决方法在装饰器内部判断原函数是不是方法。一个简单但不优雅的办法是不管只把args和kwargs原样转发不要自作主张拆参数。如果确实需要读取参数做决策可以用inspect.signature来判断第一个参数名是不是self或cls。5.6staticmethod和classmethod的叠加顺序你字面意思上可以叠加class A: staticmethod my_decorator def method(): ...但叠加顺序有讲究。如果my_decorator写在staticmethod的外面那么my_decorator装饰的是一个普通的函数因为staticmethod返回的是一个描述符对象不是普通函数这会导致my_decorator拿到的func不是可调用的函数对象调用时可能会报错。正确的做法是staticmethod放在最外层让my_decorator去装饰一个普通函数再把结果转换成静态方法class A: staticmethod my_decorator def method(): ...不过说真的实际业务里更推荐在类方法上装饰时直接使用函数装饰器不要搞复杂的叠加容易给自己挖坑。等装饰器本身摸熟了再玩花样也来得及。5.7 性能损耗问题装饰器毕竟多包了一层函数调用每次调用都会多几次嵌套函数执行。不过这个损耗通常极小——一次函数调用大约几微秒级别的开销。但如果你在一个大循环里调用百万次累积损耗就明显了。我做过一次简单的压测一个空函数直接调用、加一层装饰器、加四层装饰器耗时差距大约是每百万次调用差0.3到1秒。对于业务系统来说这个差异通常可以忽略。但如果你写的是高频调用的基础库可以考虑用functools.lru_cache减少重复计算牺牲一部分内存换时间把装饰器写成类并用__slots__减少实例内存甚至在上线前把装饰器逻辑手工内联到关键路径上不推荐除非Profile数据明确指向这里6. 实用场景清单从爬虫到数据分析装饰器无处不在聊完了写法和坑我把实际开发中装饰器最常用的场景整理成了一张表方便你按图索骥。我看到热搜词里有爬虫、数据分析、量化交易之类的关键词这些领域的开发者其实每天都在和装饰器打交道只是一些框架帮你封装好了。应用场景核心需求推荐方案注意事项接口鉴权校验用户身份、权限login_required装饰器顺序要保证鉴权在外层请求重试网络不稳定时自动重试自定义retry指定可重试的异常类型加随机抖动结果缓存避免重复计算functools.lru_cache或cache_result注意缓存键的可哈希性、缓存上限日志追踪记录调用链、参数、返回值自定义log_call不要吞异常注意日志敏感信息脱敏耗时统计性能分析、慢请求定位自定义time_it用perf_counter而不是time.time输入校验检查参数合法性自定义校验装饰器利用inspect.signature做参数名映射限流/防抖控制调用频率自定义rate_limit复杂度较高先想清楚分布式还是单机发布订阅事件触发后自动执行配合注册表实现注意引用循环和内存泄漏举个例子写爬虫时最常见的需求是对每一个页面抓取请求做重试限速retry(retries3, delay2, exceptions(requests.exceptions.ConnectionError,)) rate_limit(calls_per_second2) def fetch_page(url): resp requests.get(url, timeout10) resp.raise_for_status() return resp.text这两个装饰器叠加在一起爬虫脚本的健壮性立刻提升一个档次。同样的思路适用于量化策略中回测数据的拉取、交易接口的调用它们的共同特点是外部服务不稳定但你不能因为这个不稳定就让整个程序崩溃。数据分析场景一个很实用的用法是把 DataFrame 的计算过程用缓存装饰器包起来避免每次重启 Jupyter Notebook 都要重复跑一遍重型预处理。cache_result def load_and_clean_data(): df pd.read_csv(raw.csv) df df.dropna().query(amount 0) return df加上这个装饰器后同一个会话里多次调用load_and_clean_data()第二次开始直接返回缓存结果省去每次十几秒的读表清洗时间。还有一个是很多框架帮你内置好的Flask的路由注册本身就是一个装饰器模式、Django的login_required、pytest的pytest.fixture、celery的app.task。你学会了自己写装饰器之后再去看这些框架源码会发现它们底层都是用同样的原理实现的——一个接收函数、返回新函数的函数。7. 再进一步类装饰器和上下文管理器的配合最后聊一个稍微进阶一点但也非常实用的点装饰器和上下文管理器with语句怎么配合。有时候你希望函数在执行时临时切换状态比如修改全局配置、临时加锁、临时换数据库连接。这种进入时设置、退出时恢复的场景用上下文管理器很顺手。但如果你希望这个行为能套用在多个函数上装饰器就是更好的载体。import contextlib import threading def locked(lock): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): with lock: return func(*args, **kwargs) return wrapper return decorator lock threading.Lock() locked(lock) def update_account(): ...with lock:把锁的获取和释放都管理好了装饰器只需要确保函数调用在with块内即可。这种方式比在每个函数里手写lock.acquire()和lock.release()干净得多也不容易因为异常漏掉release。同样的思路还可以用于临时修改环境变量临时切换当前工作目录数据库事务提交/回滚修改全局日志级别后恢复原级别你在装饰器里用with语句实际上就是在包装函数的wrapper里嵌套一个上下文管理器让它的__enter__和__exit__自动包住原函数的执行过程。这比手动在try/finally里写恢复逻辑要优雅得多也隐藏了异常安全细节。我个人最喜欢的用法是数据库事务装饰器def transactional(session): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): try: result func(*args, **kwargs) session.commit() return result except Exception: session.rollback() raise return wrapper return decorator这个装饰器保证函数里只要抛了任何异常事务一定回滚只要正常返回一定提交。你写业务函数的时候完全不用操心事务边界只需要在函数上贴transactional(session)这个标签提交和回滚的脏活全交给装饰器干。这就是装饰器最让我着迷的地方它把横切关注点从业务逻辑里剥离出来让代码的关注点单一化。当你跟别人协作时你可以说你只需要专注写清楚业务规则通用的约束和增强我来管这种代码组织方式的收益会随着项目规模扩大变得越来越明显。如果让我给一个学习路径的建议我会说先在简单脚本里把wrapper(*args, **kwargs)和functools.wraps用熟然后尝试写一个带参装饰器理解三层嵌套的动机再尝试写一个类装饰器感受状态维护的不同方式最后回到你正在用的框架里挑一个内置装饰器读一读源码lru_cache和Flask.route源码都值得一读你会发现之前觉得框架帮我们搞定的事不再是黑盒踩过几次坑之后我最大的体会是装饰器不是越高级越复杂越好而是越透明越好。好的装饰器不会改变原函数的行为契约只是在外面加了一层可控的外壳。写的时候多想一步如果我装饰的函数被调用一万次、被放在一个很大的代码库里、被其他同事阅读它会不会造成困惑很多设计问题就不会发生。