装饰器与生成器：Python高级武器

可视化演示

通过文氏图展示条件概率P(A|B)=P(A∩B)/P(B)的计算过程，调节滑块改变事件概率，实时观察条件概率的变化。

装饰器入门：给函数配个帮厨

老王的招牌菜“红烧肉”远近闻名。老板想记录每道菜的出菜时间，老王不想改菜谱——改坏了算谁的？帮厨小赵主动请缨：“菜谱不用动，我站在灶台边计时就行。出锅前我记一笔，菜还是您那盘菜。”装饰器就是这位小赵：不动原函数一行代码，在它的前后插入额外动作。

小赵能做到这一切，前提是 Python 里“函数也是对象”——函数可以像变量一样被传递、被赋值、被返回。既然老王（原函数）能被当作参数递给小赵，小赵就能包一层再还回来。在 Python 里，装饰器就是一个“接收函数、返回新函数”的普通函数。

最朴素的装饰器长这样：def timer(func): 定义一个包装函数 wrapper(*args, kwargs)，在调用 func 前后做点手脚，最后返回 wrapper。而 @timer 写在函数定义上方，等价于一行赋值：func = timer(func)。@ 只是语法糖，把“帮我给函数加包装”这件事写得更直观。

有了帮厨队伍，老板的厨房开始规范起来：有的负责记录时间，有的负责检查摆盘。重要的是，哪道菜要配哪位帮厨，写在菜谱上方一行 @ 就够，菜谱本身一个字都不用改。装饰器之所以是“高级武器”，就是因为它把“横切关注点”（日志、计时、鉴权）从业务代码里剥离出来，让每道菜谱保持纯粹。

闭包原理：帮厨的备忘小抄

小赵记性好，但好记性不如烂笔头。主厨交代他“出锅前撒一把葱花”，他就把这条规矩写在随身小抄上。有一天小赵跳槽到隔壁餐厅，只要小抄还在，他给新主厨打下手时，依然会记得撒葱花。语法上，小抄上记的“葱花规矩”，并不属于新主厨的厨房——它属于小赵自己。

装饰器的内层函数（小赵）引用了外层函数（主厨）的局部变量（葱花规矩）。按理说，外层函数执行完就结束了，局部变量应该被回收。但 Python 发现内层函数还“惦记”着这个变量，就会把它打包进一个叫闭包的特殊对象里，跟着内层函数走。

技术细节有三点：第一，被“惦记”的变量叫自由变量；第二，它们存在内层函数的 __closure__ 元组里，每个单元对应一个变量；第三，如果内层函数要修改自由变量，必须显式声明 nonlocal，否则 Python 会认为它是一个新的局部变量。来看看一个标准闭包示例 make_adder(n)：它接收一个数 n，返回一个新函数，新函数把任何输入都加上 n。

回到厨房：闭包就是那张小抄。装饰器能“记住”参数、记住配置，靠的全是这张小抄。很多框架里“携带配置的包装函数”，本质上都是闭包在发力——比如 flask 的路由注册、click 的命令行选项，都是先把参数包进闭包，再返回一个懂规矩的函数。

带参装饰器：能接单的帮厨工厂

老板又提新需求：“小赵，以后不光计时，还要在记录里写上菜名标签，方便对账。”小赵心想：光靠一张通用小抄不够了，得按老板的要求定制。于是出现了一种新角色：帮厨工厂。工厂根据订单参数——比如“标签前缀”——造出一个符合要求的帮厨。

对应到 Python，就是带参装饰器。它比普通装饰器多一层：最外层函数接收参数（如 repeat(3) 里的 3），返回一个真正的装饰器，这个装饰器再接收函数，返回包装函数。三层嵌套像套娃，但每一层职责清晰：最外层“接参数”，中间层“接函数”，最内层“接调用”。

经典例子 @repeat(3)：repeat(3) 先执行，拿到参数 3，返回装饰器 decorator；decorator 作用于原函数，返回 wrapper；以后每次调用，原函数被执行 3 遍。整个过程可以拆解为“先定制、再包装”两步——和普通装饰器唯一的区别是，多了一道“先用参数定制”的工序。

帮厨工厂让老板的厨房彻底规范化：想给接口加上“限流 + 日志 + 超时”，写三个带参装饰器叠上去就行，每个帮厨由对应工厂定制、互不干扰。日常开发中，functools.lru_cache(maxsize=128)、flask 的 app.route('/path') 都是带参装饰器的典型代表——你传的是参数，拿到的是定制好的包装。

内置装饰器：厨房的三个固定工位

老王的厨房规模大了，设了三个固定工位。第一个是“独立帮工”：他只管按单做事，不需要知道主厨是谁，有点像外聘的计件师傅。第二个是“值班领班”：他代表整个厨房接活，知道厨房有哪些人、有什么资源。第三个是“扫码取餐口”：顾客扫个码，餐食就从窗口递出来，完全不用和后厨打交道。

这三个工位对应 Python 类的三个内置装饰器：@staticmethod（独立帮工：不接收 self 也不接收 cls，就是放在类里的普通函数）、@classmethod（值班领班：自动接收类 cls，能访问类属性、支持继承）、@property（扫码取餐口：把方法伪装成属性，obj.price 直接取值，背后其实在跑函数）。

关键区别在签名。实例方法写 def f(self, x)；@staticmethod 转换后写成 def f(x)——self 消失了；@classmethod 则写成 def f(cls, x)——self 换成了 cls。@property 则把读操作变成 obj.attr，还可以搭配 setter 控制赋值。这些内置装饰器让类设计优雅许多：只读属性、工厂方法、工具函数都能各归其位。

三个工位让厨房既灵活又有秩序：外聘帮工只做事不问出身，值班领班代表集体做决策，扫码窗口把内部复杂度藏起来。内置装饰器不多，但用好它们，类的可读性立刻上一个台阶——这也是你读 Django、SQLAlchemy 源码时最常见的三种“类魔法”。

生成器基础：按单炒菜的大厨

自助餐模式让老王头疼：每天提前备 1000 份菜，冰箱塞爆，晚上剩下几百份倒掉。他决定改做“按单炒菜”：客人点一道，他炒一道；不点不炒，冰箱里永远只有一份食材。这就是生成器——按需生产，绝不囤货。

语法上，只要函数体里出现 yield 关键字，这个函数就“变身”了。注意：调用它不会执行函数体，而是返回一个生成器对象。next(gen) 或 for 循环才会真正驱动函数体运行，一路执行到 yield，暂停，把一个值“递”出来。这里有个极易踩的坑：写 gen = countdown(5) 时，厨房并没有开火，只是挂了单。

生成器的价值在内存。列表 list(range(108)) 会一次性吃掉几百 MB 内存；而生成器每次只产生一个数，内存恒定。它还能表达无限序列——比如不断吐出奇数，因为根本不需要事先存下来。代价是：它只能从前往后走一遍，不支持下标访问，也不能回头。这就像按单炒菜：菜出完就没了，想再吃要重新下单。

老王的冰箱终于空出来了。处理几 GB 日志、几百万条训练样本时，按单炒菜（生成器）让内存占用稳稳地停在“一盘菜”的量级——这是数据工程师和 AI 工程师处理海量数据的首选姿势。

生成器进阶：客人可以中途改单

老王正炒着宫保鸡丁，客人喊了一嗓子：“别放花生！”老王手一顿，把刚想倒进去的花生收回，调整完继续往下炒。这个“炒一半还能沟通”的能力，就是 send 方法——它能在生成器暂停时，从外部传一个值进去，代替 yield 表达式的结果。

gen.send(value) 把 value 送回暂停处的 yield 表达式，生成器接着往下跑，直到下一个 yield 再停下来。特别地，第一次唤醒不能用 send(非None)，得用 gen.send(None) 或 next(gen)。有了 send，生成器就不只是“单向水管”，而是“双向对讲机”——这就是协程的雏形：两个函数互相喊话、交替推进。

同一个家族还有“生成器表达式”：(x * x for x in range(n))。它和列表推导式 [x * x for x in range(n)] 长得像，但前者是惰性的生成器，后者立即建出整个列表。写代码时一个括号之差，内存天壤之别。很多 AI 框架的数据加载器（DataLoader）就是靠生成器表达式 + send 类机制，实现“边训练边喂数据”。

客人能改单，主厨能沟通，厨房从“单向出菜”进化成“前后场对话”。很多异步框架的协程、async for 异步生成器，都是在这个机制上长出来的——理解了 send，你就在心里种下了一颗协程的种子。

yield from：整块甜品交给副厨

老王接了个婚宴大单，几十桌。他忙不过来，把甜品区整个交给副厨阿强：“阿强，甜品你全权负责，客人有什么特殊要求直接跟你对接，不用经过我。”这种“整块移交 + 直接对接”的委托方式，就是 yield from。

作用：在一个生成器里写 yield from sub_gen，等于把 sub_gen 整个“外包”出去，主生成器不再逐个搬运 sub_gen 的值，而是让调用方直接和 sub_gen 打交道。写出来最省，读起来最清楚——你看代码时一眼就知道“这一整段是委托出去的”。

简单场景下，yield from s 和 for v in s: yield v 结果一样；但前者会自动透传 send()、throw()、close() 等消息，还能拿到子生成器的返回值。协程嵌套协作时，这种“协议透传”是普通 for 循环做不到的——就像老王如果一道道转达客人的要求，不仅慢，还可能传错话。

老王松了口气：每块业务交给一个副厨，主厨房只管协调。代码也一样——生成器层层委托，结构像菜单一样清晰，消息像服务员一样直达对应后厨。Python 标准库 contextlib、各种协程框架里，yield from 都是不可或缺的“委托枢纽”。

实战应用：厨房的黄金时代

厨房转型完成：每个厨师都配了帮厨（日志装饰器），招牌菜提前卤好冷藏、客人点了热一下再上（缓存装饰器），大订单按单炒菜绝不囤货（生成器流式处理）。这套组合拳让餐厅既快又省——装饰器管“加能力”，生成器管“省资源”。

最常见的实战：日志装饰器——给每个 API 端点记录调用时间、入参、出参，异常时自动告警，业务函数保持干净；缓存装饰器——functools.lru_cache 记住函数结果，相同参数直接秒回，省去重复计算；流式读文件——for line in open(...) 逐行读取，几十 GB 日志也只占一行内存，配合生成器管道可以边读边统计。

还有装饰器叠加：@a 在 @b 之上时，@b 先作用（离函数近的先包），@a 再包一层。这就像帮厨排队：最里面的帮厨最先接触原函数，最外面的帮厨最先接触调用方。叠加顺序不同，行为就不同——比如“先鉴权再计时”和“先计时再鉴权”，失败的请求计不计时，结果完全不一样。

从一张菜谱到一整套厨房体系，装饰器和生成器从来不是孤立技巧：装饰器让横切逻辑复用，生成器让数据流受控。框架作者每天都在用这套思维方式写代码——你掌握了它们，读源码时那些“魔法”就会变成“原来如此”。

AI 应用场景

Python 演示

import timefrom functools import wraps  def timer(func):    """装饰器: 给原函数附加耗时统计, 原函数本身一字不改"""    @wraps(func)    def wrapper(*args, **kwargs):        start = time.perf_counter()        result = func(*args, **kwargs)        cost = time.perf_counter() - start        print("{} 运行耗时 {:.4f} 秒".format(func.__name__, cost))        return result    return wrapper  @timerdef sum_to_n(n):    """普通函数: 一次性算出 0 到 n 的和"""    return sum(range(n + 1))  def countdown(n):    """生成器函数: 执行到 yield 暂停并吐出一个值, 下次 next 再续上"""    while n >= 0:        yield n        n -= 1  def read_lines(path):    """生成器: 逐行读取大文件, 内存永远只占一行"""    with open(path, "r", encoding="utf-8") as f:        for line in f:            yield line.rstrip("\n")  if __name__ == "__main__":    total = sum_to_n(1000000)    print("sum_to_n(1000000) =", total)     print("countdown(5) 逐个产出:")    for x in countdown(5):        print("  得到", x)     gen = read_lines("no_such_file.txt")    print("创建 read_lines 生成器后函数体未执行, 文件尚未打开")    print("生成器类型:", type(gen).__name__)

1. def wrapper(*args, **kwargs):万能传菜口，不管原函数收什么参数都能接住并转发。
2. @wraps(func)把原函数的名字、文档字符串等元信息复制到包装函数上，调试时不会看到满屏的 "wrapper"。
3. @timer语法糖，等价于 sum_to_n = timer(sum_to_n)，把原函数名重新绑定到包装函数。
4. yield n暂停函数执行并把 n 递出去，下次 next() 从这一行继续。
5. while n >= 0:配合 yield 形成“每取一次、状态推进一次”的生成循环。
6. for line in f:文件对象本身可迭代，逐行读取正是生成器流式处理的经典写法。
7. gen = read_lines("no_such_file.txt")创建生成器不执行函数体，所以文件根本没被打开，完美展示惰性求值。
8. for x in countdown(5):for 循环本质是不断调用 next()，直到 StopIteration 为止。

常见误区

面试题