Python闭包装饰器这道坎几乎每个 Python 学习者都会撞上一次。我带过不少初学者几乎无一例外都会问同一个问题装饰器为什么要套两层、三层函数就不能简单点吗其实只要把闭包这个底层概念打通装饰器那几层嵌套不但不绕反而会显得水到渠成。这篇内容就围绕闭包和装饰器展开先拆解闭包在 Python 里到底是怎么“记住”外层变量的再把装饰器还原成闭包的一个典型应用最后给出一套可以直接复制的实战代码和排查清单。适合已经掌握函数定义和基本调用、但总觉得装饰器写法绕的同学读完你能理解背后的原理也能随手写出无参、带参、类装饰器应对日志、耗时统计、缓存、重试这些日常需求。1. 闭包与装饰器为什么这两个概念必须一起学1.1 闭包是装饰器的底层机制闭包这个词听起来学术味很重其实就一句话当一个函数定义在另一个函数内部并且引用了外部函数的局部变量时即使外层函数已经执行完毕返回了内层函数依然能访问那个变量。def outer(x): def inner(): return x * 10 return inner fn outer(5) print(fn()) # 50按普通直觉outer(5)执行完局部变量x应该被销毁了但fn()依然能拿到x的值并算出 50。原因就是 Python 把x和inner绑定在一个“带环境”的函数对象里返回了。这个带环境的函数就是闭包。装饰器呢装饰器是xxx放在函数定义上方等价于fn xxx(fn)。xxx接收一个函数返回一个新函数新函数在合适时机调用原函数并在前后插入额外逻辑。这个包装过程用到的是完全相同的机制外层decorator把func作为参数捕获进内层wrapper的闭包环境里。所以一句话结论闭包是 Python 语言层面的函数机制装饰器是建立在闭包之上的语法用法。搞懂了前者后者的嵌套就不再神秘。1.2 装饰器解决的“横切”问题如果不用装饰器想在多个函数里统一加日志或计时只能逐个手写重复代码def f1(): print(开始执行 f1) # 业务代码 print(结束执行 f1) def f2(): print(开始执行 f2) # 业务代码 print(结束执行 f2)业务逻辑和辅助逻辑混在一起改一行日志格式就得动所有函数。装饰器把这类“横切关注点”统一抽到外层原函数只保留核心业务。这个概念在主流框架里遍地开花Web 框架的登录校验、ORM 的事务管理、测试框架的超时控制本质都是同一套思路。打个生活比方你去快递站取件取件本身是一个动作但每个站点都有“验码—取件—签收”的统一流程。你不会在每个包裹里都打印一遍流程而是在站点这个“装饰器”里统一处理。装饰器就是代码里的快递站。2. 闭包的底层机制函数怎么“记住”变量2.1 作用域规则LEGB 帮你判断变量从哪来Python 查找变量遵循 LEGB 顺序Local局部→ Enclosing外层嵌套函数的局部→ Global模块全局→ Built-in内置。x 100 # Global def outer(): x 50 # Enclosing闭包捕获的就是这一层 def inner(): print(x) # inner 里没有 x向上找到 Enclosing return inner fn outer() fn() # 50inner里没有定义x于是向上找outer里也没定义的话就用全局x。注意这种情况下还算不算闭包就值得商榷了——严格说闭包必须引用了 Enclosing 层的局部变量。这也是很多人容易混淆的点函数嵌套不等于闭包捕获外部局部变量才是关键。2.2__closure__闭包的记忆载体闭包“记住”的东西到底存在哪里答案是函数对象的__closure__属性def outer(x): def inner(): return x return inner fn outer(42) print(fn.__closure__) # (cell at 0x000001...: int object at 0x...,) print(fn.__closure__[0].cell_contents) # 42CPython 在编译到内部函数时发现它引用了外层局部变量就会自动把变量放进一个 cell 容器里再挂到内层函数的__closure__元组上。outer(42)执行完后变量x并没有随函数栈销毁而是被这个 cell 稳稳托住。这也是我说“闭包带记忆”的实体依据。如果你怀疑一个函数到底捕获了什么直接打印fn.__closure__一看cell_contents就能立刻确认。没有捕获任何外层变量时__closure__是 None而不是空元组。这个细节能帮你少做很多无谓猜测。2.3 闭包的三个形成条件要形成闭包三个条件缺一不可函数嵌套内层函数定义在外层函数内部内层函数引用了外层函数的局部变量或参数外层函数把内层函数作为返回值返回或者以某种方式把它暴露出来注意第三点如果内层函数只是定义、从未被返回或引用外层函数一旦执行完内层函数对象就随之销毁外部根本没有机会调用它也就谈不上“闭包”。def outer(): def inner(): return hi return inner fn outer() print(fn.__closure__) # None这里虽然嵌套且返回了内层函数但inner没有引用任何外层局部变量所以它只是一次普通的函数返回不是闭包。判断一个函数是否形成了闭包最直接的方法就是检查__closure__是否非空。3. 装饰器实现原理从手动包装到 语法糖3.1 第一个装饰器手动调用版本先别急着用手动包装一次理解会更透def my_decorator(func): def wrapper(): print(调用前) result func() # func 被 wrapper 闭包捕获 print(调用后) return result return wrapper def greet(): return Hello greet my_decorator(greet) print(greet())这里的wrapper就是闭包捕获了func这个外层参数。greet被重新赋值后调用greet()实际执行的是wrapper再由wrapper调用原来的函数。输出顺序是调用前 → Hello → 调用后。3.2 语法糖与模块加载时机只是语法糖函数定义完成后会立刻执行一次等价赋值my_decorator def greet(): return Hello # 等价于 greet my_decorator(greet)很多人以为在函数首次调用时才生效事实不是。模块被 import 时装饰器就会执行。如果你的装饰器内部有连接池初始化、配置文件读取等重逻辑它们会在导入阶段运行而不是第一次调用时。这一点在大型项目里会影响启动流程我曾经见过有人在装饰器里做重量级模型加载结果一个模块 import 要等十几秒排查半天才发现是装饰器在导包阶段就跑了。值得区分的是my_decorator(greet)这个表达式在定义时立即执行wrapper 内部的print(调用前)要等greet()被调用才执行。把打印位置放到不同层级就能观察出定义期和调用期的差异。3.3 必须写*args, **kwargs的原因装饰器本质是替换原函数一个通用装饰器不应该假设原函数的签名。用*args, **kwargs接收任意位置参数和关键字参数原样透传给func才能适配任意函数。import functools def logged(func): functools.wraps(func) def wrapper(*args, **kwargs): print(fcall {func.__name__}) return func(*args, **kwargs) return wrapper logged def add(a, b): return a b logged def greet(name, greetingHello): return f{greeting}, {name}如果 wrapper 写成def wrapper(a, b):第一个函数还能跑第二个带关键字参数的函数调用会直接报TypeError: wrapper() got an unexpected keyword argument greeting。所以任何通用装饰器第一行就写def wrapper(*args, **kwargs)已经是行业默契。4. 装饰器的常用形态无参、带参、类装饰器4.1 无参装饰器模板无参装饰器是两层的标准形态import functools def timer(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() try: return func(*args, **kwargs) finally: print(f{func.__name__} 耗时 {time.perf_counter() - start:.4f} 秒) return wrapper最外层接收函数内层接收调用参数返回内层函数对象。记忆口诀一层接函数一层接调用参数。4.2 带参装饰器模板与三层嵌套带参装饰器长这样典型如retry(3)def retry(max_attempts3, delay1.0): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, max_attempts 1): try: return func(*args, **kwargs) except Exception: if attempt max_attempts: raise time.sleep(delay) return wrapper return decorator retry(max_attempts3, delay0.5) def fetch_data(): ...为什么必须三层因为执行链是retry(max_attempts3, delay0.5)先被求值返回decoratorPython 把fetch_data作为decorator(func)的实参传入返回wrapper之后每次调用fetch_data()执行的是wrapper(*args, **kwargs)三层分别对应装饰器参数 → 被装饰函数 → 函数调用参数。记不住时从调用次序反推顺理成章。无参和带参装饰器不要混写。retry(3)这种写法里整数3会被当成被装饰函数对象传入decorator(func)等你调用时就会报int object is not callable。这一条是最容易踩的入门坑。4.3 类装饰器与两种实例化方式的区别用类实现装饰器核心是让实例可调用即实现__call__class Timer: def __init__(self, func): self.func func functools.update_wrapper(self, func) def __call__(self, *args, **kwargs): start time.perf_counter() try: return self.func(*args, **kwargs) finally: print(f{self.func.__name__} 耗时 {time.perf_counter() - start:.4f} 秒) Timer def run(): time.sleep(0.5)这里的Timer等价于run Timer(run)__init__接收的是函数。如果写成Timer()事情就变了Timer()先实例化__init__不再接收函数而是接收你传的参数随后 Python 会调用实例的__call__(run)由__call__接收被装饰函数并返回 wrapper。所以类装饰器根据是否带括号分成两种子类型__init__里到底是self.func func还是self.args args一眼就能分辨。我的个人体会是如果装饰器需要维护复杂状态、上下文或者自定义__repr__类写法更清晰如果只是简单的职责封装函数式写法更轻便。4.4 装饰器叠加顺序先装饰谁、后调用谁多个装饰器叠加执行顺序经常把人绕晕。看这个例子auth logging def view(): ...等价于view auth(logging(view))所以装饰顺序是从下往上logging先包装原函数auth再包装logging的结果。调用顺序是从上往下view()先过auth的 wrapper再过logging的 wrapper最后进原函数。用表格表示阶段执行内容说明定义时第一步logging包装viewview logging(view)定义时第二步auth包装上一步结果view auth(logging(view))调用时外层先进auth的 wrapper由auth的 wrapper 调用内部的函数调用时内层再进logging的 wrapper由logging的 wrapper 调用原始view这个顺序直接影响实际行为。计时器和缓存叠加就是最典型的一个例子后面实战案例里会实际验证。5. 实战案例一个带缓存、计时与重试的数据处理装饰器5.1 场景与需求假设有一个函数fetch_stock_price(symbol)需要从一个模拟的数据服务读取行情单次调用耗时约 1.2 秒偶尔还会超时。现在要实现三个需求打印每次调用的耗时相同symbol在 60 秒内的请求直接使用缓存不重复请求请求出现异常时自动重试 3 次还有一个隐性要求保持原函数的签名和 docstring方便 IDE 提示和后续文档生成。5.2 分步实现与组装先写三个独立的装饰器import functools import time def timed(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() try: return func(*args, **kwargs) finally: cost time.perf_counter() - start print(f[耗时] {func.__name__}{args!r}{kwargs!r} 用时 {cost:.4f} 秒) return wrapper def ttl_cache(seconds60): def decorator(func): cache {} functools.wraps(func) def wrapper(*args, **kwargs): key (args, tuple(sorted(kwargs.items()))) now time.monotonic() if key in cache and now - cache[key][0] seconds: return cache[key][1] result func(*args, **kwargs) cache[key] (now, result) return result return wrapper return decorator def retry(max_attempts3, delay0.2): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, max_attempts 1): try: return func(*args, **kwargs) except Exception: if attempt max_attempts: raise time.sleep(delay) return wrapper return decorator组装时注意顺序retry(max_attempts3, delay0.5) timed ttl_cache(seconds60) def fetch_stock_price(symbol: str) - float: 模拟读取行情数据 time.sleep(1.2) return round(100 len(symbol), 2)从被装饰函数往上走最贴近它的是ttl_cache所以先去缓存层再包timed记录每次调用的总耗时最后包retry确保底层出错时重试。这个顺序不是随便写的是有讲究的缓存只缓存原函数的结果不希望把timed的耗时打印也存进缓存也不希望缓存命中的请求还要经过重试逻辑白白增加延迟。调用验证print(fetch_stock_price(MSFT)) # 第一次约1.2秒后返回 print(fetch_stock_price(MSFT)) # 第二次缓存命中打印耗时约0秒第二次虽然很快但timed在外层所以依然会记录并打印这次调用的耗时。如果你的需求是“缓存命中时完全不要计时”那就把timed放到最里层结果会不一样。这种取舍只能靠实际场景决定。5.3 验证叠加顺序与执行效果把顺序反过来做一次对比效果立竿见影组合从下到上最终函数缓存命中时的行为ttl_cache→timedtimed(ttl_cache(fn))两次都进 timed第二次耗时≈0timed→ttl_cachettl_cache(timed(fn))第二次直接返回缓存timed 完全跳过第二种写法里ttl_cache缓存的是timed返回的结果因此缓存命中时耗时统计代码不会执行。你选哪种取决于业务上到底想统计什么。再补一个生产环境要注意的点key (args, tuple(sorted(kwargs.items())))要求参数必须可哈希。如果参数里有列表、字典这类可变对象这个 key 会直接报TypeError: unhashable type。真正的生产代码里有人用repr生成 key甚至用pickle.dumps各有利弊但核心思路是一致的把调用参数转化为可哈希的稳定标识。6. 闭包与装饰器的高频陷阱隐患排查6.1 循环变量迟绑定问题这是闭包最经典的坑几乎每个人的闭包初体验都折在这funcs [] for i in range(3): funcs.append(lambda: i) for f in funcs: print(f()) # 实际输出 2 2 2而不是 0 1 2原因lambda: i是闭包捕获的是外层变量i。每次循环迭代i是同一个变量对象被反复赋值。调用f()时闭包读取的是“当前环境下i的值”而循环早已结束i停在2。闭包记住的是变量绑定不是创建时的值快照。修复方式有三种默认参数快照lambda ii: i默认值在定义时求值相当于把当前值钉死工厂函数def make(i): return lambda: i用参数隔离变量functools.partial(lambda i: i, i)偏函数在构造时固定参数装饰器里同样会遇到这个问题在循环中批量注册处理器或生成带闭包的函数时如果绑定了循环变量最终所有闭包可能都指向最后一次迭代的值。排查方法还是那招——打印__closure__里的cell_contents看它到底绑定了什么。6.2 nonlocal 缺失导致 UnboundLocalError闭包里如果只想读外层变量问题不大一旦想修改外层变量不加声明就会报错def counter(): count 0 def inc(): count 1 return count return inc c counter() c() # UnboundLocalError: local variable count referenced before assignment原因很反直觉count 1让 Python 把count判定为inc内部的局部变量于是闭包捕获机制失效。要修改外层变量必须在内部函数第一行声明def counter(): count 0 def inc(): nonlocal count count 1 return count return inc这个机制和global是同一族全局变量用global声明外层闭包变量用nonlocal声明二者不要混。理解了这一点闭包的“只读默认、显式修改”规则就很清晰了。6.3 函数元信息被吞掉没有functools.wraps(func)的装饰器会把被装饰函数的__name__、__doc__、__module__等元信息全部换成 wrapper 的。这在很多框架里会引起问题框架用函数名注册路由测试框架用函数名显示用例名称文档生成工具按签名提取函数说明。print(fetch_stock_price.__name__) # wrapper 或 fetch_stock_price print(fetch_stock_price.__wrapped__) # 只有用了 wraps 才有所以写任何通用装饰器都默认加上functools.wraps(func)这不算附加优化而是基本要求。6.4 带括号与不带括号的类装饰器混淆对照两种类装饰器class NoArgs: def __init__(self, func): self.func func def __call__(self, *args, **kwargs): return self.func(*args, **kwargs) NoArgs def hello(): ... class WithArgs: def __init__(self, prefix): self.prefix prefix def __call__(self, func): functools.wraps(func) def wrapper(*args, **kwargs): print(self.prefix) return func(*args, **kwargs) return wrapper WithArgs(开始) def hello(): ...区别一句话说清NoArgs时__init__收到的是函数WithArgs(开始)时先实例化拿到对象再由对象的__call__接收被装饰函数。如果写了WithArgs忘加括号prefix会收到一个函数对象运行后打印出来的就是函数的内存地址。这类问题调试时先打印__init__收到的参数类型立刻真相大白。7. 进阶用法与我的经验心得7.1 参数校验与 TTL 缓存扩展装饰器不只是用来记日志和测耗时的。参数校验是同样高频的场景def ensure_type(typename): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for value in args: if not isinstance(value, typename): raise TypeError(f参数 {value!r} 不是 {typename.__name__}) return func(*args, **kwargs) return wrapper return decorator上一节里的ttl_cache也可以继续扩展成带“最大容量”的 LRU 缓存或者给不同 key 设置不同过期时间。这些模式都是闭包的灵活运用本质都是把“调用函数前后要做的事情”封装成可复用的单元。7.2 保留签名与调试技巧functools.wraps会把__module__、__name__、__qualname__、__doc__、__annotations__都复制到 wrapper并且设置__wrapped__指向原函数。inspect.signature默认会跟随__wrapped__所以 IDE 的自动补全和函数提示依然能显示原始签名。这对基础框架类代码尤其重要——别人拿到你包装后的函数还能看到原来的文档和参数结构。调试闭包时最实用的三个属性fn.__closure__ # 查看捕获的 cell 列表 fn.__closure__[0].cell_contents # 查看第一个自由变量的当前值 fn.__wrapped__ # 从包装后的函数还原原始函数我拿到一段陌生代码时会先给函数做这三个属性的“体检”往往一眼看出问题是绑定错误还是包装层数不对。尤其是多层装饰器叠加以后__wrapped__能帮你快速扒开所有层直达最底层的原始函数。7.3 我的几条实战建议闭包和装饰器不是靠背模板能掌握的真正的练习路径是这样的先手写一个无参装饰器故意去掉*args, **kwargs再写一个接收关键字参数的被装饰函数亲眼见一次报错印象远比背诵深。把无参、带参、类装饰器分别改写成“手动赋值”的等价写法确认到底是什么。在循环里用 lambda 构造几个函数打印__closure__观察绑定把迟绑定问题彻底看透。在真实项目里用retry和timed这类小装饰器替代重复的 try/except 和散落的耗时打印代码会清爽很多。任何时候都别忘functools.wraps(func)这是行业约定不是可选项。坦白讲闭包给我最大的感触是Python 里的函数不只是执行代码它还自带一副“眼镜”能看到自己诞生时所在的环境。装饰器则是把这种能力包装成顺手的小工具让关注点分离得干干净净。初学者容易被嵌套搞晕一旦亲手调过几次__closure__就再也不会把 wrapper 和 func 弄混了。 
长河君 · 2026/10/22 6:28:08 · 阅读 1.2k Python闭包与装饰器：从嵌套函数到@语法糖的完整解析
Python闭包装饰器这道坎几乎每个 Python 学习者都会撞上一次。我带过不少初学者几乎无一例外都会问同一个问题装饰器为什么要套两层、三层函数就不能简单点吗其实只要把闭包这个底层概念打通装饰器那几层嵌套不但不绕反而会显得水到渠成。这篇内容就围绕闭包和装饰器展开先拆解闭包在 Python 里到底是怎么“记住”外层变量的再把装饰器还原成闭包的一个典型应用最后给出一套可以直接复制的实战代码和排查清单。适合已经掌握函数定义和基本调用、但总觉得装饰器写法绕的同学读完你能理解背后的原理也能随手写出无参、带参、类装饰器应对日志、耗时统计、缓存、重试这些日常需求。1. 闭包与装饰器为什么这两个概念必须一起学1.1 闭包是装饰器的底层机制闭包这个词听起来学术味很重其实就一句话当一个函数定义在另一个函数内部并且引用了外部函数的局部变量时即使外层函数已经执行完毕返回了内层函数依然能访问那个变量。def outer(x): def inner(): return x * 10 return inner fn outer(5) print(fn()) # 50按普通直觉outer(5)执行完局部变量x应该被销毁了但fn()依然能拿到x的值并算出 50。原因就是 Python 把x和inner绑定在一个“带环境”的函数对象里返回了。这个带环境的函数就是闭包。装饰器呢装饰器是xxx放在函数定义上方等价于fn xxx(fn)。xxx接收一个函数返回一个新函数新函数在合适时机调用原函数并在前后插入额外逻辑。这个包装过程用到的是完全相同的机制外层decorator把func作为参数捕获进内层wrapper的闭包环境里。所以一句话结论闭包是 Python 语言层面的函数机制装饰器是建立在闭包之上的语法用法。搞懂了前者后者的嵌套就不再神秘。1.2 装饰器解决的“横切”问题如果不用装饰器想在多个函数里统一加日志或计时只能逐个手写重复代码def f1(): print(开始执行 f1) # 业务代码 print(结束执行 f1) def f2(): print(开始执行 f2) # 业务代码 print(结束执行 f2)业务逻辑和辅助逻辑混在一起改一行日志格式就得动所有函数。装饰器把这类“横切关注点”统一抽到外层原函数只保留核心业务。这个概念在主流框架里遍地开花Web 框架的登录校验、ORM 的事务管理、测试框架的超时控制本质都是同一套思路。打个生活比方你去快递站取件取件本身是一个动作但每个站点都有“验码—取件—签收”的统一流程。你不会在每个包裹里都打印一遍流程而是在站点这个“装饰器”里统一处理。装饰器就是代码里的快递站。2. 闭包的底层机制函数怎么“记住”变量2.1 作用域规则LEGB 帮你判断变量从哪来Python 查找变量遵循 LEGB 顺序Local局部→ Enclosing外层嵌套函数的局部→ Global模块全局→ Built-in内置。x 100 # Global def outer(): x 50 # Enclosing闭包捕获的就是这一层 def inner(): print(x) # inner 里没有 x向上找到 Enclosing return inner fn outer() fn() # 50inner里没有定义x于是向上找outer里也没定义的话就用全局x。注意这种情况下还算不算闭包就值得商榷了——严格说闭包必须引用了 Enclosing 层的局部变量。这也是很多人容易混淆的点函数嵌套不等于闭包捕获外部局部变量才是关键。2.2__closure__闭包的记忆载体闭包“记住”的东西到底存在哪里答案是函数对象的__closure__属性def outer(x): def inner(): return x return inner fn outer(42) print(fn.__closure__) # (cell at 0x000001...: int object at 0x...,) print(fn.__closure__[0].cell_contents) # 42CPython 在编译到内部函数时发现它引用了外层局部变量就会自动把变量放进一个 cell 容器里再挂到内层函数的__closure__元组上。outer(42)执行完后变量x并没有随函数栈销毁而是被这个 cell 稳稳托住。这也是我说“闭包带记忆”的实体依据。如果你怀疑一个函数到底捕获了什么直接打印fn.__closure__一看cell_contents就能立刻确认。没有捕获任何外层变量时__closure__是 None而不是空元组。这个细节能帮你少做很多无谓猜测。2.3 闭包的三个形成条件要形成闭包三个条件缺一不可函数嵌套内层函数定义在外层函数内部内层函数引用了外层函数的局部变量或参数外层函数把内层函数作为返回值返回或者以某种方式把它暴露出来注意第三点如果内层函数只是定义、从未被返回或引用外层函数一旦执行完内层函数对象就随之销毁外部根本没有机会调用它也就谈不上“闭包”。def outer(): def inner(): return hi return inner fn outer() print(fn.__closure__) # None这里虽然嵌套且返回了内层函数但inner没有引用任何外层局部变量所以它只是一次普通的函数返回不是闭包。判断一个函数是否形成了闭包最直接的方法就是检查__closure__是否非空。3. 装饰器实现原理从手动包装到 语法糖3.1 第一个装饰器手动调用版本先别急着用手动包装一次理解会更透def my_decorator(func): def wrapper(): print(调用前) result func() # func 被 wrapper 闭包捕获 print(调用后) return result return wrapper def greet(): return Hello greet my_decorator(greet) print(greet())这里的wrapper就是闭包捕获了func这个外层参数。greet被重新赋值后调用greet()实际执行的是wrapper再由wrapper调用原来的函数。输出顺序是调用前 → Hello → 调用后。3.2 语法糖与模块加载时机只是语法糖函数定义完成后会立刻执行一次等价赋值my_decorator def greet(): return Hello # 等价于 greet my_decorator(greet)很多人以为在函数首次调用时才生效事实不是。模块被 import 时装饰器就会执行。如果你的装饰器内部有连接池初始化、配置文件读取等重逻辑它们会在导入阶段运行而不是第一次调用时。这一点在大型项目里会影响启动流程我曾经见过有人在装饰器里做重量级模型加载结果一个模块 import 要等十几秒排查半天才发现是装饰器在导包阶段就跑了。值得区分的是my_decorator(greet)这个表达式在定义时立即执行wrapper 内部的print(调用前)要等greet()被调用才执行。把打印位置放到不同层级就能观察出定义期和调用期的差异。3.3 必须写*args, **kwargs的原因装饰器本质是替换原函数一个通用装饰器不应该假设原函数的签名。用*args, **kwargs接收任意位置参数和关键字参数原样透传给func才能适配任意函数。import functools def logged(func): functools.wraps(func) def wrapper(*args, **kwargs): print(fcall {func.__name__}) return func(*args, **kwargs) return wrapper logged def add(a, b): return a b logged def greet(name, greetingHello): return f{greeting}, {name}如果 wrapper 写成def wrapper(a, b):第一个函数还能跑第二个带关键字参数的函数调用会直接报TypeError: wrapper() got an unexpected keyword argument greeting。所以任何通用装饰器第一行就写def wrapper(*args, **kwargs)已经是行业默契。4. 装饰器的常用形态无参、带参、类装饰器4.1 无参装饰器模板无参装饰器是两层的标准形态import functools def timer(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() try: return func(*args, **kwargs) finally: print(f{func.__name__} 耗时 {time.perf_counter() - start:.4f} 秒) return wrapper最外层接收函数内层接收调用参数返回内层函数对象。记忆口诀一层接函数一层接调用参数。4.2 带参装饰器模板与三层嵌套带参装饰器长这样典型如retry(3)def retry(max_attempts3, delay1.0): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, max_attempts 1): try: return func(*args, **kwargs) except Exception: if attempt max_attempts: raise time.sleep(delay) return wrapper return decorator retry(max_attempts3, delay0.5) def fetch_data(): ...为什么必须三层因为执行链是retry(max_attempts3, delay0.5)先被求值返回decoratorPython 把fetch_data作为decorator(func)的实参传入返回wrapper之后每次调用fetch_data()执行的是wrapper(*args, **kwargs)三层分别对应装饰器参数 → 被装饰函数 → 函数调用参数。记不住时从调用次序反推顺理成章。无参和带参装饰器不要混写。retry(3)这种写法里整数3会被当成被装饰函数对象传入decorator(func)等你调用时就会报int object is not callable。这一条是最容易踩的入门坑。4.3 类装饰器与两种实例化方式的区别用类实现装饰器核心是让实例可调用即实现__call__class Timer: def __init__(self, func): self.func func functools.update_wrapper(self, func) def __call__(self, *args, **kwargs): start time.perf_counter() try: return self.func(*args, **kwargs) finally: print(f{self.func.__name__} 耗时 {time.perf_counter() - start:.4f} 秒) Timer def run(): time.sleep(0.5)这里的Timer等价于run Timer(run)__init__接收的是函数。如果写成Timer()事情就变了Timer()先实例化__init__不再接收函数而是接收你传的参数随后 Python 会调用实例的__call__(run)由__call__接收被装饰函数并返回 wrapper。所以类装饰器根据是否带括号分成两种子类型__init__里到底是self.func func还是self.args args一眼就能分辨。我的个人体会是如果装饰器需要维护复杂状态、上下文或者自定义__repr__类写法更清晰如果只是简单的职责封装函数式写法更轻便。4.4 装饰器叠加顺序先装饰谁、后调用谁多个装饰器叠加执行顺序经常把人绕晕。看这个例子auth logging def view(): ...等价于view auth(logging(view))所以装饰顺序是从下往上logging先包装原函数auth再包装logging的结果。调用顺序是从上往下view()先过auth的 wrapper再过logging的 wrapper最后进原函数。用表格表示阶段执行内容说明定义时第一步logging包装viewview logging(view)定义时第二步auth包装上一步结果view auth(logging(view))调用时外层先进auth的 wrapper由auth的 wrapper 调用内部的函数调用时内层再进logging的 wrapper由logging的 wrapper 调用原始view这个顺序直接影响实际行为。计时器和缓存叠加就是最典型的一个例子后面实战案例里会实际验证。5. 实战案例一个带缓存、计时与重试的数据处理装饰器5.1 场景与需求假设有一个函数fetch_stock_price(symbol)需要从一个模拟的数据服务读取行情单次调用耗时约 1.2 秒偶尔还会超时。现在要实现三个需求打印每次调用的耗时相同symbol在 60 秒内的请求直接使用缓存不重复请求请求出现异常时自动重试 3 次还有一个隐性要求保持原函数的签名和 docstring方便 IDE 提示和后续文档生成。5.2 分步实现与组装先写三个独立的装饰器import functools import time def timed(func): functools.wraps(func) def wrapper(*args, **kwargs): start time.perf_counter() try: return func(*args, **kwargs) finally: cost time.perf_counter() - start print(f[耗时] {func.__name__}{args!r}{kwargs!r} 用时 {cost:.4f} 秒) return wrapper def ttl_cache(seconds60): def decorator(func): cache {} functools.wraps(func) def wrapper(*args, **kwargs): key (args, tuple(sorted(kwargs.items()))) now time.monotonic() if key in cache and now - cache[key][0] seconds: return cache[key][1] result func(*args, **kwargs) cache[key] (now, result) return result return wrapper return decorator def retry(max_attempts3, delay0.2): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(1, max_attempts 1): try: return func(*args, **kwargs) except Exception: if attempt max_attempts: raise time.sleep(delay) return wrapper return decorator组装时注意顺序retry(max_attempts3, delay0.5) timed ttl_cache(seconds60) def fetch_stock_price(symbol: str) - float: 模拟读取行情数据 time.sleep(1.2) return round(100 len(symbol), 2)从被装饰函数往上走最贴近它的是ttl_cache所以先去缓存层再包timed记录每次调用的总耗时最后包retry确保底层出错时重试。这个顺序不是随便写的是有讲究的缓存只缓存原函数的结果不希望把timed的耗时打印也存进缓存也不希望缓存命中的请求还要经过重试逻辑白白增加延迟。调用验证print(fetch_stock_price(MSFT)) # 第一次约1.2秒后返回 print(fetch_stock_price(MSFT)) # 第二次缓存命中打印耗时约0秒第二次虽然很快但timed在外层所以依然会记录并打印这次调用的耗时。如果你的需求是“缓存命中时完全不要计时”那就把timed放到最里层结果会不一样。这种取舍只能靠实际场景决定。5.3 验证叠加顺序与执行效果把顺序反过来做一次对比效果立竿见影组合从下到上最终函数缓存命中时的行为ttl_cache→timedtimed(ttl_cache(fn))两次都进 timed第二次耗时≈0timed→ttl_cachettl_cache(timed(fn))第二次直接返回缓存timed 完全跳过第二种写法里ttl_cache缓存的是timed返回的结果因此缓存命中时耗时统计代码不会执行。你选哪种取决于业务上到底想统计什么。再补一个生产环境要注意的点key (args, tuple(sorted(kwargs.items())))要求参数必须可哈希。如果参数里有列表、字典这类可变对象这个 key 会直接报TypeError: unhashable type。真正的生产代码里有人用repr生成 key甚至用pickle.dumps各有利弊但核心思路是一致的把调用参数转化为可哈希的稳定标识。6. 闭包与装饰器的高频陷阱隐患排查6.1 循环变量迟绑定问题这是闭包最经典的坑几乎每个人的闭包初体验都折在这funcs [] for i in range(3): funcs.append(lambda: i) for f in funcs: print(f()) # 实际输出 2 2 2而不是 0 1 2原因lambda: i是闭包捕获的是外层变量i。每次循环迭代i是同一个变量对象被反复赋值。调用f()时闭包读取的是“当前环境下i的值”而循环早已结束i停在2。闭包记住的是变量绑定不是创建时的值快照。修复方式有三种默认参数快照lambda ii: i默认值在定义时求值相当于把当前值钉死工厂函数def make(i): return lambda: i用参数隔离变量functools.partial(lambda i: i, i)偏函数在构造时固定参数装饰器里同样会遇到这个问题在循环中批量注册处理器或生成带闭包的函数时如果绑定了循环变量最终所有闭包可能都指向最后一次迭代的值。排查方法还是那招——打印__closure__里的cell_contents看它到底绑定了什么。6.2 nonlocal 缺失导致 UnboundLocalError闭包里如果只想读外层变量问题不大一旦想修改外层变量不加声明就会报错def counter(): count 0 def inc(): count 1 return count return inc c counter() c() # UnboundLocalError: local variable count referenced before assignment原因很反直觉count 1让 Python 把count判定为inc内部的局部变量于是闭包捕获机制失效。要修改外层变量必须在内部函数第一行声明def counter(): count 0 def inc(): nonlocal count count 1 return count return inc这个机制和global是同一族全局变量用global声明外层闭包变量用nonlocal声明二者不要混。理解了这一点闭包的“只读默认、显式修改”规则就很清晰了。6.3 函数元信息被吞掉没有functools.wraps(func)的装饰器会把被装饰函数的__name__、__doc__、__module__等元信息全部换成 wrapper 的。这在很多框架里会引起问题框架用函数名注册路由测试框架用函数名显示用例名称文档生成工具按签名提取函数说明。print(fetch_stock_price.__name__) # wrapper 或 fetch_stock_price print(fetch_stock_price.__wrapped__) # 只有用了 wraps 才有所以写任何通用装饰器都默认加上functools.wraps(func)这不算附加优化而是基本要求。6.4 带括号与不带括号的类装饰器混淆对照两种类装饰器class NoArgs: def __init__(self, func): self.func func def __call__(self, *args, **kwargs): return self.func(*args, **kwargs) NoArgs def hello(): ... class WithArgs: def __init__(self, prefix): self.prefix prefix def __call__(self, func): functools.wraps(func) def wrapper(*args, **kwargs): print(self.prefix) return func(*args, **kwargs) return wrapper WithArgs(开始) def hello(): ...区别一句话说清NoArgs时__init__收到的是函数WithArgs(开始)时先实例化拿到对象再由对象的__call__接收被装饰函数。如果写了WithArgs忘加括号prefix会收到一个函数对象运行后打印出来的就是函数的内存地址。这类问题调试时先打印__init__收到的参数类型立刻真相大白。7. 进阶用法与我的经验心得7.1 参数校验与 TTL 缓存扩展装饰器不只是用来记日志和测耗时的。参数校验是同样高频的场景def ensure_type(typename): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): for value in args: if not isinstance(value, typename): raise TypeError(f参数 {value!r} 不是 {typename.__name__}) return func(*args, **kwargs) return wrapper return decorator上一节里的ttl_cache也可以继续扩展成带“最大容量”的 LRU 缓存或者给不同 key 设置不同过期时间。这些模式都是闭包的灵活运用本质都是把“调用函数前后要做的事情”封装成可复用的单元。7.2 保留签名与调试技巧functools.wraps会把__module__、__name__、__qualname__、__doc__、__annotations__都复制到 wrapper并且设置__wrapped__指向原函数。inspect.signature默认会跟随__wrapped__所以 IDE 的自动补全和函数提示依然能显示原始签名。这对基础框架类代码尤其重要——别人拿到你包装后的函数还能看到原来的文档和参数结构。调试闭包时最实用的三个属性fn.__closure__ # 查看捕获的 cell 列表 fn.__closure__[0].cell_contents # 查看第一个自由变量的当前值 fn.__wrapped__ # 从包装后的函数还原原始函数我拿到一段陌生代码时会先给函数做这三个属性的“体检”往往一眼看出问题是绑定错误还是包装层数不对。尤其是多层装饰器叠加以后__wrapped__能帮你快速扒开所有层直达最底层的原始函数。7.3 我的几条实战建议闭包和装饰器不是靠背模板能掌握的真正的练习路径是这样的先手写一个无参装饰器故意去掉*args, **kwargs再写一个接收关键字参数的被装饰函数亲眼见一次报错印象远比背诵深。把无参、带参、类装饰器分别改写成“手动赋值”的等价写法确认到底是什么。在循环里用 lambda 构造几个函数打印__closure__观察绑定把迟绑定问题彻底看透。在真实项目里用retry和timed这类小装饰器替代重复的 try/except 和散落的耗时打印代码会清爽很多。任何时候都别忘functools.wraps(func)这是行业约定不是可选项。坦白讲闭包给我最大的感触是Python 里的函数不只是执行代码它还自带一副“眼镜”能看到自己诞生时所在的环境。装饰器则是把这种能力包装成顺手的小工具让关注点分离得干干净净。初学者容易被嵌套搞晕一旦亲手调过几次__closure__就再也不会把 wrapper 和 func 弄混了。