闭包这个词第一次听像是某种数学概念第一次用像是某种魔法用熟了之后才发现它其实很朴素——Python 里的闭包本质就是把一个函数和它出生时的环境打包带走让这个函数在外面跑的时候还能记得老家里的那些变量。很多人学 Python 到函数这一章就卡住了参数会传了返回值会接了但一看到函数里面还能定义函数返回的函数还能记住外层变量脑子就开始打结。这篇东西不打算给你上理论课而是把我自己在写爬虫、写数据处理脚本、写工具库时反复用到闭包的那些场景连同踩过的坑一起摊开来讲。如果你现在处于这几个阶段这篇内容对你会比较友好刚学完 def、return、作用域想知道闭包到底解决了什么问题写装饰器时能抄代码但说不清原理遇到过循环里创建函数结果全部输出最后一个值的诡异现象或者单纯想在面试前把闭包这块补扎实。下面我会从它是什么讲到为什么这么设计再讲到怎么写、怎么调、怎么避坑代码都是可以直接粘到解释器里跑的那种。1. 闭包到底是个什么东西从一段能跑的代码说起与其背定义不如先看现象。闭包的定义在教科书里通常写成引用了自由变量的函数且该函数可以在其定义环境之外被执行这句话每个字都认识连起来就不认识了。我们换成代码。1.1 先看现象函数里返回函数def make_counter(): count 0 def counter(): return count return counter c make_counter() print(c()) # 0 print(c()) # 0这段代码里make_counter()执行完之后按常规理解它的局部变量count应该被回收了因为函数栈已经退出了。但c还能读到count的值而且读到的就是当初那个count。这说明count并没有随着make_counter的返回而消失它被counter这个内层函数抓住了。这个被抓住的变量术语叫自由变量free variable而counter加上它抓住的count合起来就是闭包。这里有个关键认识闭包抓的不是变量的值是变量的绑定。这点极其重要后面讲循环晚绑定陷阱时你会看到它的威力。1.2 闭包成立的三要素判断一个函数是不是闭包我一般用三个条件去套嵌套内层函数定义在外层函数里引用内层函数引用了外层函数的局部变量不是全局变量也不是参数传进来的外逃外层函数把内层函数作为返回值返回或者以其他方式让内层函数活得比外层函数更久。三条同时满足闭包就成立了。少一条都不算——如果内层函数只是引用了全局变量那是普通的作用域查找如果内层函数没被返回出去它随着外层函数结束一起消亡闭包的意义也就不存在。你可以用一个很偷懒的办法验证def outer(): x 1 def inner(): return x print(inner.__closure__) return inner outer() # (cell at 0x...: int object at 0x...,)__closure__属性不为None而且里面是个元组装着 cell 对象那这就是闭包。这个属性后面我会专门拿出来当调试工具用它比 print 大法精准得多。1.3 从内存视角看cell 对象到底装了什么很多人以为闭包是 Python 特有的语法糖其实它是运行时的一种数据结构安排。CPython 里当一个变量被内层函数引用并且需要跨栈帧存活时这个变量不会放在普通的局部变量数组里而是被塞进一个叫cell的对象。外层函数的栈帧里保存的是指向 cell 的引用内层函数的__closure__里保存的也是同一批 cell 的引用。这意味着两件事。第一外层和内层看到的是同一个 cell任何一方改动在允许改动的前提下另一方都能看到。第二cell 的生命周期由引用计数决定只要还有函数对象持有它它就不会被释放。所以闭包能记住环境不是靠复制而是靠共享同一个容器。理解到这一层很多现象就顺了为什么闭包里的变量修改后内层能看到为什么闭包会阻止垃圾回收为什么__closure__[0].cell_contents能读出当前值。我一开始也觉得这些是边角知识直到有次在服务里排查一个内存缓慢上涨的问题最后定位到一个被闭包长期持有的字典才意识到这套机制不是考试内容是生产内容。2. 为什么需要闭包状态保持与方案选型知道了闭包长什么样接下来要回答一个更实际的问题明明有类、有全局变量、有默认参数为什么还要用闭包2.1 闭包和类两种状态保持方案对照闭包和类解决的是同一类问题——让函数带上状态。计数器是最典型的例子用类写是这样class Counter: def __init__(self): self.count 0 def __call__(self): self.count 1 return self.count用闭包写是这样def make_counter(): count 0 def counter(): nonlocal count count 1 return count return counter两种写法都能得到每次调用自增一的效果。那怎么选我自己的判断标准整理成了一张表维度闭包类代码量少几行搞定需要定义类、方法状态数量一两个变量合适状态多时更清晰可读性逻辑简单时紧凑命名和方法语义更明确扩展性加功能要改函数结构继承、混入都方便调试变量藏在 cell 里稍难观察属性一目了然可打印__dict__性能调用开销略小属性查找有额外开销结论很直白状态少、逻辑短、只在一个地方用闭包更利落状态多、需要被多处复用、需要序列化或反射老老实实写类。我见过有人为了炫技把五六个状态全塞进闭包最后连自己都记不清哪个 cell 对应哪个业务含义那就是本末倒置。2.2 闭包在真实项目里的落点闭包不是屠龙技它在日常代码里的出镜率比你想的高得多只是常常藏在语法糖后面装饰器装饰器的本质就是接收函数、返回函数的闭包。timer之所以能记住你传的超时时间就是因为它把参数存在了闭包变量里。回调注册给某个事件注册处理函数时经常需要把当前上下文的一个 ID 带进去用闭包包一层比写全局变量干净得多。配置工厂一套请求逻辑只是 base_url 和 token 不同用闭包生成多个专用函数比每次调用都传一遍参数舒服。惰性求值把计算推迟到真正需要的时候闭包可以先把参数冻住等调用时再算。我用爬虫的时候特别爱用配置工厂这种写法一个函数按站点生成对应的抓取函数每个抓取函数自带 headers、超时、重试次数调用方完全不用关心这些细节。这种定制版函数的思维是闭包最舒服的使用姿势。2.3 什么时候不该用闭包有三类情况我会主动避开闭包。第一类是需要被序列化的函数比如要扔进多进程池执行。闭包函数没法被 pickle多进程环境下直接报错这时候得换成模块级函数加参数传递。第二类是带大量状态且需要日志排查的对象。闭包变量在调试器里看不太直观类实例的__dict__打印出来清清楚楚出问题时省时间。第三类是跨线程共享的状态。闭包里的变量访问不是原子的count 1在多线程下会丢更新这点跟类实例属性一样。如果你只是想共享状态不如用类加上锁语义更明确。我自己吃过一次亏——用一个闭包做请求计数压测时数字总是比实际少一点查了半天才发现是并发自增的问题。3. 三个必须吃透的核心机制闭包的坑不多但每个都很经典。这一节把三个最容易翻车的地方讲透绑定时机、nonlocal、循环陷阱。3.1 LEGB 规则与自由变量的绑定时间Python 查找变量按 LEGB 顺序Local、Enclosing、Global、Built-in。闭包变量属于 E 这一层也就是 Enclosing。注意这个查找发生在函数执行时不是定义时。这个区别就是晚绑定的根源。def outer(): x 1 def inner(): return x x 2 return inner print(outer()()) # 2inner定义的时候x还是 1但调用时读到的却是 2。因为inner读的是那个 cell 的当前内容而 cell 在外层函数返回前被改成了 2。这里也顺便说清一个容易混淆的点闭包抓的是变量名对应的 cell不是快照。同样的规则在循环里会变得非常刺眼这是下面 3.3 的主题。3.2 nonlocal让闭包变量可写只读的闭包没什么争议一旦要在内层函数里修改外层变量问题就来了def make_counter(): count 0 def counter(): count 1 # UnboundLocalError return count return countercount 1等价于count count 1赋值动作让 Python 把count判定为counter的局部变量可它又没有在counter里初始化于是报UnboundLocalError。解决办法是显式声明def make_counter(): count 0 def counter(): nonlocal count count 1 return count return counternonlocal的意思是我要改的是外层函数作用域里的那个变量别在本地新建。它和global是一对global指向模块级nonlocal指向最近的一层外层函数作用域。注意nonlocal声明时那个变量必须已经在外层存在否则会报 SyntaxError。它只能向上找函数作用域找不到会直接报错不会穿透到全局。3.3 循环晚绑定陷阱与两种修法这是闭包面试最爱考的一题也是实战最容易踩的雷funcs [] for i in range(3): funcs.append(lambda: i) print([f() for f in funcs]) # [2, 2, 2]预期是 0、1、2实际全是 2。原因回到 3.1lambda 捕获的是变量i的 cell而循环结束后i停在最后一个值 2所有 lambda 读到的都是这个 cell 的当前内容。修法一是用默认参数在定义时求值funcs [] for i in range(3): funcs.append(lambda ii: i) print([f() for f in funcs]) # [0, 1, 2]默认参数在函数定义时就被求值等于给每个函数做了一份快照。这是最简洁的修法我平时写得最多。修法二是用工厂函数再造一层闭包def make_func(i): return lambda: i funcs [make_func(i) for i in range(3)] print([f() for f in funcs]) # [0, 1, 2]每调用一次make_func就产生一个新的 cell三个 lambda 各自持有不同的 cell互不干扰。这种写法在需要传的参数不止一个、或者初次求值代价较大时更合适因为它会把求值推迟到调用时如果函数体里不是立即使用的话。两种修法没有绝对优劣。默认参数版更短缺点是如果参数是可变对象会被所有调用共享同一个对象工厂版更正统缺点是多一层缩进。我的习惯是参数是数字、字符串这类不可变值时用默认参数参数是列表、字典时用工厂函数避免共享可变对象带来的隐藏 bug。顺便提一句JavaScript 里也有几乎一样的晚绑定问题只是老版本用var声明时更严重后来用let的块级作用域缓解了。跨语言看这类陷阱的根源都一样捕获的是绑定不是值。4. 动手实操几个能直接抄进项目的闭包原理讲完了接下来是能落地的东西。下面每个例子我都尽量写得完整加上必要的注释和使用说明你可以直接复制到编辑器里跑。4.1 计数器与带初值的累加器def make_accumulator(start0): total start def add(n): nonlocal total total n return total return add acc make_accumulator(10) print(acc(5)) # 15 print(acc(5)) # 20 print(acc(-3)) # 17这段代码在做什么统计都方便比如累计耗时、累计流量。要留意的点是total只属于这一个acc再调一次make_accumulator就是全新的一份状态彼此不串。这种每个实例独立的特性正是闭包相对于全局变量的最大优势。4.2 配置工厂生成定制版请求函数def make_fetcher(base_url, timeout5, retries3): def fetch(path, **params): url base_url.rstrip(/) / path.lstrip(/) for attempt in range(retries): try: print(f[{attempt1}/{retries}] GET {url} timeout{timeout}) return {url: url, params: params} except Exception: if attempt retries - 1: raise return fetch user_fetch make_fetcher(https://api.example.com, timeout3) print(user_fetch(users, page1)) print(user_fetch(orders, page2))这个模式我在实际项目里用得最多。站点配置、超时、重试策略全都封在闭包里调用方看到的只是一个干干净净的user_fetch(path, **params)。要新增一个站点加一行make_fetcher(...)就行完全不用改调用代码。实操心得base_url这类字符串属于不可变对象放心共享。如果你在闭包里存的是字典、列表记得在函数体里不要直接原地修改外层那个对象否则所有调用方共享同一份数据很容易出玄学问题。4.3 闭包版缓存把计算留到最后一刻def cached(func): cache {} def wrapper(*args): if args not in cache: cache[args] func(*args) return cache[args] wrapper.cache cache return wrapper cached def slow_square(n): print(computing, n) return n * n print(slow_square(4)) # computing 4 / 16 print(slow_square(4)) # 16不再计算 print(slow_square.cache) # {(4,): 16}这里cache字典被闭包长期持有构成了记忆化效果。注意到我把cache也挂到了wrapper.cache上这是一个非常实用的技巧闭包变量默认是黑盒挂出来之后既方便调试也方便外部主动清理比如在数据更新后slow_square.cache.clear()。这个例子的隐患是args必须是可哈希的传列表会直接报TypeError: unhashable type。真要缓存带列表的调用得先把参数转成元组或者做一次规范化处理。另外无限制增长的缓存等于内存泄漏生产环境里我会加一个长度上限超过就整体清空或者丢掉最早的一批绝不放任它涨。4.4 用闭包手写装饰器标准库的functools.wraps别省它能把原函数的名字、文档字符串复制过来不然后面排查日志时全是wrapper根本看不出是哪个函数。import functools import time def timer(prefix): def decorator(func): functools.wraps(func) def wrapper(*args, **kwargs): t0 time.perf_counter() result func(*args, **kwargs) print(f{prefix} {func.__name__} cost {time.perf_counter()-t0:.4f}s) return result return wrapper return decorator timer([PROFILE]) def work(n): return sum(range(n)) work(1000000)这里的嵌套结构值得拆开看timer(prefix)返回decoratordecorator(func)返回wrapper。三层的意义在于最外层负责接收装饰器参数中间层接收被装饰函数最内层才是真正的执行体。理解了闭包装饰器就不再是背下来的模板而是我确实需要把 prefix 和 func 都存起来的自然结果。4.5 闭包做一个简单的调用频率限制import time def make_limiter(min_interval): last 0.0 def allow(): nonlocal last now time.monotonic() if now - last min_interval: last now return True return False return allow limiter make_limiter(0.5) print(limiter()) # 大概率 True print(limiter()) # 当前应该 False time.sleep(0.6) print(limiter()) # True这个写法适合做单机的轻量节流比如控制日志打印频率、控制某个任务的重试节奏。注意它不是线程安全的last的读和写之间有间隙多线程下可能同时放行。要上多线程得在外面套一把threading.Lock或者干脆换成类加锁的写法。5. 常见问题与排查技巧实录讲完怎么写再讲讲出错时怎么查。这一节的每一条都是我或身边人真实撞过的。5.1 报错与症状速查表症状常见原因处理办法UnboundLocalError内层想改外层变量但没声明加nonlocalSyntaxError: no binding for nonlocal外层根本没有这个变量检查变量名拼写与外层定义循环创建的函数全返回最后一个值晚绑定默认参数或工厂函数固定值TypeError: unhashable type缓存字典的 key 是列表等可变对象转成元组再进缓存内存持续上涨闭包长期持有大对象或无限缓存加容量上限或用完后清空多进程里报序列化失败闭包函数无法被 pickle改成模块级函数参数显式传递装饰后函数名全变成 wrapper没用functools.wraps加上装饰器保留元信息这张表建议收藏出事的时候按症状反查比从原理重新推一遍快得多。5.2 调试三件套__closure__、cell_contents、co_freevars闭包变量不好直接 print但有三样东西可以帮你把它挖出来def outer(): a 1 b text def inner(): return a, b return inner f outer() print(f.__code__.co_freevars) # (a, b) for name, cell in zip(f.__code__.co_freevars, f.__closure__): print(name, , cell.cell_contents) # a 1 # b textco_freevars告诉你这个函数引用了哪些自由变量__closure__里的 cell 与它一一对应cell_contents是当前值。我在排查这个闭包到底记住了什么的时候基本靠这段模板几秒钟定位比加一堆 print 干净。一个经验是如果你把某个闭包变量加进了日志记得只记关键字段别把整个大字典打到日志里——日志系统本身会持有字符串引用间接延长对象生命周期。5.3 内存与回收闭包为什么会占着不放闭包持有的对象不会被回收直到闭包本身被回收。麻烦之处在于闭包经常被挂到别的地方去——注册到回调列表、塞进全局字典、放进缓存。一旦这么干那些本来该释放的大对象就一直活着。排查思路是这样先确认对象是否还被引用用sys.getrefcount看引用计数用gc.get_referrers看谁在引用它。真遇到闭包相关的循环引用比如闭包把自身注册到某个容器容器又被闭包引用CPython 的分代回收能处理大部分但如果你想更早释放可以把容器里注册的引用主动注销掉或者改用弱引用容器weakref.WeakSet。我在一个长时间运行的服务里踩过一次用闭包按用户生成了一批处理函数并存进字典用户下线后字典没清理每个处理函数又各自持有一份会话数据。跑了几天内存就上去了。后来改成定期清理字典并在清理时显式把不再需要的闭包置空问题解决。这段经历让我形成了一个习惯——只要用闭包保存状态就要想清楚这个状态由谁、在什么时候释放。5.4 可读性与性能的取舍经验性能上闭包的调用开销和普通函数差别不大别指望用闭包做大优化。真正的收益在可读性和调用方体验上把一堆重复的参数封装掉让业务代码更干净。反过来如果闭包让这个数据到底谁在改变得难以追踪那就是负收益。我的取舍原则是三条一闭包变量不超过三个多了就换类二闭包只在定义它的模块内使用不跨模块传递跨模块传闭包会让依赖关系变模糊三任何持久的闭包状态都要有明确的清理入口。做到这三条闭包基本只会帮你不会坑你。顺便回答一个经常被问到的问题闭包和functools.partial有什么差别partial只做参数固化语义更单一适合就是想把某几个参数固定住的场景闭包能带内部状态、能写逻辑表达力更强。如果只是固定参数我会优先用partial因为它一眼就能看懂也不会引入额外的状态。最后分享一个我自己总结的小技巧当你写出的闭包越来越复杂特别是需要在里面做分支、维护多个变量、还要给外部暴露状态的时候那就是它在提醒你该升级成类了。闭包和类不是对立的是同一个问题的轻量解和重量解知道什么时候切换比记住闭包的定义重要得多。