Day 48 这个节点很有意思。能坚持到第 48 天，说明你已经把基础语法、函数、面向对象、文件操作这些硬骨头啃得差不多了，但这个阶段也最容易陷入一种“会写但不懂”的瓶颈：能跑通代码，却说不清代码在内存里到底发生了什么。我个人的看法是，Day 48 恰恰是 Python 入门与进阶的分水岭，今天要讲的迭代器、生成器、装饰器，就是你从“会用语法”转向“理解机制”的关键一步。
很多人在学到这一章的时候会觉得抽象，因为这三个东西看不见摸不着，不像print和if那样直观。但换个角度想，它们其实是 Python 设计哲学里最“省事”的部分——内存省事、代码省事、逻辑省事。这篇文章我们就从“为什么需要它们”开始，一步一步拆解原理，再上手写代码，最后聊一聊我实际跑项目时踩过的坑。
1. Day 48 该学什么：从“会写代码”到“懂机制”
1.1 为什么这个阶段要补迭代器与生成器
先抛一个场景。假设你现在要处理一个 500G 大小的日志文件，里面记录了某服务的全部请求信息，你要统计每个 IP 出现的次数。如果按照刚学 Python 时的直觉，很自然会写：
with open("access.log", "r", encoding="utf-8") as f: lines = f.readlines() for line in lines: # 处理每一行...这个代码在逻辑上没有错，但我可以明确告诉你：真这么跑，你的电脑会在读文件的瞬间内存直接爆炸。readlines()会一次性把 500G 的内容全部加载进内存，而 500G 意味着哪怕你有 64G 内存也不够用。
这时候就轮到迭代器与生成器登场了。它们的核心价值不复杂：不一次性生成所有数据，而是每次只生成一个，用完就丢。这在处理大数据、流式数据、无限序列的场景下，几乎是唯一合理的方案。
而装饰器则是另一个维度的工具。它解决的是“在不修改原函数代码的前提下，给函数增加额外功能”的问题。比如你想统计每个函数的执行时间，最朴素的做法是每个函数内部都写一遍计时逻辑，但写了十个函数你就得复制十遍，写了二十个就得复制二十遍。装饰器可以让这段计时逻辑只写一次，然后“贴”到任意函数上。
1.2 先搞清楚三个概念的本质区别
很多初学者会把迭代器、生成器、装饰器混为一谈，其实它们根本不是同一类东西。我做一个直白的区分：
- 迭代器（Iterator）：是一个“状态对象”。它记住自己遍历到哪个位置了，你每次向它要下一个值，它就给你下一个，直到结束。
- 生成器（Generator）：是创建迭代器的一种方式，但它不是普通对象，而是一个可以暂停和恢复的函数。它用自己的函数体来描述“下一个值怎么算”，而不是先算完存起来。
- 装饰器（Decorator）：是一个“包装函数”。它接收一个函数作为参数，返回一个新的函数，新函数内部往往先做点别的事情，再调用原函数。
打个生活化的比方。迭代器像一本随翻随看的书签，读到哪里记到哪里，不会把整本书背下来；生成器像一台暂停播放的录像机，按一下播放键出一段画面，再按一下再出一段；装饰器像给手机贴膜，手机（原函数）本身没有变，但多了一层保护壳（附加功能），而且你想换膜随时可以换。
这三者底层都绕不开一个核心概念：可迭代对象（Iterable），就是任何可以用for循环遍历的东西，比如列表、元组、字符串、字典。可迭代对象不一定是迭代器，但迭代器一定是可迭代对象。这个区别在后面的常见问题部分还会展开讲，这里先记住这个结论。
2. 迭代器协议与自实现迭代器
2.1 迭代器协议的两个核心方法
看任何 Python 对象是不是迭代器，其实只看它有没有实现两个方法：__iter__()和__next__()。
__iter__()返回迭代器对象本身，让for循环能拿到它。__next__()返回下一个值，如果没有更多值了，就抛出StopIteration异常。
for循环的底层工作过程，其实就是这两步的循环：先调用iter()函数拿到迭代器，然后不停调用next()获取下一个值，直到捕获到StopIteration才结束。你可以用下面的代码模拟for循环的内部逻辑：
# 模拟 for 循环的底层执行过程 my_list = [1, 2, 3] it = iter(my_list) while True: try: item = next(it) print(item) except StopIteration: break这个理解特别重要，因为很多表象背后都是这个机制在运作。比如为什么for循环能遍历一切可迭代对象？因为它不关心对象内部是数组还是链表还是流式数据，只要对象提供了迭代协议，for就能工作。这就是“鸭子类型”的典型体现：长得像鸭子、叫得像鸭子，那它就是鸭子。
有一点需要提醒：很多人会混淆可迭代对象和迭代器。列表本身是可迭代对象，但不是迭代器。判断方法很简单，看有没有__next__()方法。列表没有，所以它不是迭代器；但列表的iter()返回的那个对象才是迭代器。这个我在实际面试别人时经常问，答错的人真的不少。
2.2 动手实现一个自己的迭代器
理解了协议之后，完全可以自己写一个迭代器类。下面这个例子实现了一个步进计数器，每调用一次就返回下一个偶数：
class EvenCounter: """生成从 start 开始的偶数序列""" def __init__(self, start=0): self.current = start def __iter__(self): return self # 迭代器返回自身 def __next__(self): value = self.current self.current += 2 # 每次步进 2 return value但是注意，这个迭代器没有终点，如果你拿它做for循环，它会无限跑下去。所以要手动控制结束条件，比如最多生成 5 个数字就抛出StopIteration：
class LimitedEvenCounter: def __init__(self, start=0, limit=10): self.current = start self.limit = limit def __iter__(self): return self def __next__(self): if self.current >= self.limit: raise StopIteration # 信号：迭代结束 value = self.current self.current += 2 return value for num in LimitedEvenCounter(0, 10): print(num) # 输出 0 2 4 6 8这里要特别强调raise StopIteration的这个动作：它相当于给for循环发送了一个“我已经到头了”的信号。如果你不抛异常，for循环会一直等下去，而且不会报错。很多人第一次写迭代器程序卡住不动，就是因为忘了这个结束信号。
2.3 迭代器的局限性与生成器的诞生
手写迭代器类有一个明显的痛点：繁琐。你明明只是想描述“下一个值怎么算”，却要写一整个类，还要管理内部状态变量。于是生成器应运而生，它的核心理念是：程序员只需要写一个普通函数，然后用yield代替return，这个函数就变成了生成器函数。函数里的局部变量会被自动保存，每次next()调用时从上次暂停的位置继续执行。
生成器把“状态保存”这件事完全自动化了，这也是它为什么如此优雅。你不需要手动维护self.current，也不需要写__next__和StopIteration，一切都由 Python 内部替你处理。这个设计的思路可以总结成一句话：把程序员从繁琐的协议实现中解放出来，专注于数据计算的逻辑本身。
3. 生成器：内存友好的懒加载机制
3.1 生成器函数与 yield 的完整执行流程
先看一个最简单的生成器函数：
def count_down(n): print(f"开始倒数，从 {n} 开始") while n > 0: yield n n -= 1 print("倒数结束") gen = count_down(3) print(gen) # 输出 <generator object count_down at 0x...>注意一个关键现象：当你调用count_down(3)时，函数体一行都没有执行，只是创建了一个生成器对象。函数体内的代码要等到你第一次调用next(gen)时才会开始跑。而且运行到yield n那一行，函数就会暂停，把n的值传给外部，然后原地待命，直到下一次next()再继续往下走。
完整执行过程如下：
- 创建生成器：不执行任何函数体代码。
- 第一次
next(gen)：执行到yield n，暂停并返回3。 - 第二次
next(gen)：从yield n之后继续，执行n -= 1，循环条件判断为真，再次执行到yield n，返回2。 - 第三次
next(gen)：同理返回1。 - 第四次
next(gen)：n变为0，循环终止，执行print("倒数结束")，然后函数自然结束，自动抛出StopIteration。
这就是yield和return最本质的区别：return表示函数一次性执行完毕并返回结果，函数状态不保留；yield表示函数可以分多次执行，每次返回一个值，函数状态保留在暂停的那一刻。如果你还是觉得抽象，就想象一下看电视剧按了暂停键，画面上的人物和场景全部定格，再按播放键才继续演，就是这个感觉。
3.2 生成器表达式：一行代码省内存
列表推导式大家都很熟悉，比如[x * x for x in range(1000000)]会立刻构建一个包含一百万个元素的列表，内存占用大概是几十 MB。但如果你把方括号换成圆括号，就得到了生成器表达式：
gen = (x * x for x in range(1000000))此时它不会创建任何列表元素，只是在内存里保存了一个生成器对象。你每调用一次next(gen)，才计算一个值。这在处理大文件、大数据集时特别有用，我再举一个实际场景。比如要读取一个大文件的每一行并统计行数，用列表推导式：
# 不推荐：数据量大时会卡死 lines = [line.strip() for line in open("large.txt", encoding="utf-8")] count = len(lines)用生成器表达式：
# 推荐：无论文件多大，内存占用都稳定 lines_gen = (line.strip() for line in open("large.txt", encoding="utf-8")) count = sum(1 for _ in lines_gen)第二种写法中，文件是逐行读取的，内存中永远只保留当前行。为什么sum(1 for _ in lines_gen)能统计行数？因为生成器每产生一个元素，就立刻被sum消费并累加计数，然后丢弃。整个过程中不会生成一整个行列表，内存占用始终是常数级别。说实话，当初我在一次面试中看到候选人用这个写法处理几 GB 的文件，我直接就判定他基本功扎实了。
3.3 生成器与协程基础
生成器还有一个进阶用法是数据接收和双向通信。yield不仅能向外产出值，还能接收外部传入的值，这就是协程的基础。看下面这个例子：
def echo(): print("等待输入...") while True: received = yield # 注意：yield 右边为空，表示只接收不产出 print(f"收到: {received}") gen = echo() next(gen) # 先让生成器走到 yield 处 gen.send("hello") # 外部向生成器发送值 gen.send("world")第一次调用next(gen)让函数执行到yield处暂停并等待；然后gen.send("hello")会把字符串"hello"传给received变量，函数继续执行打印逻辑，然后再次回到yield处等待，以此循环。
这个机制在异步编程、协程调度、管道流处理里应用非常广泛，很多框架的核心调度器就是用生成器实现的。对 Day 48 的学习内容来说，你不需要立刻深入异步编程，但理解“生成器可以双向通信”这一点，能帮你为后面学习异步打下扎实的基础。
这里有一个非常典型的坑：在调用send()之前，必须先调用一次next()让生成器运行到yield位置，否则会报TypeError: can't send non-None value to a just-started generator。我第一次写协程代码时就踩过这个错，后面才明白，生成器还没有“启动”，它根本不知道要在哪里接收数据。
4. 装饰器：为函数增加能力而不侵入代码
4.1 装饰器本质：函数接收函数，返回函数
先绕开那些花哨的语法，看装饰器的底层本质。在 Python 里，函数是一等对象，也就是说函数可以像变量一样被赋值、作为参数传递、作为返回值返回。装饰器利用的就是这个特性。
下面这个例子给函数增加了计时功能：
import time def timer(func): def wrapper(*args, **kwargs): start = time.time() result = func(*args, **kwargs) end = time.time() print(f"{func.__name__} 耗时 {end - start:.4f} 秒") return result return wrapper def slow_function(): time.sleep(0.5) return "done" # 手动使用装饰器： slow_func = timer(slow_function) slow_func()然后就可以用@语法糖简化：
@timer def slow_function(): time.sleep(0.5) return "done" slow_function()@timer等价于slow_function = timer(slow_function)。为什么需要wrapper(*args, **kwargs)？因为我们要让装饰后的函数能接受任意参数，然后原封不动地转给原函数。*args接收所有位置参数，**kwargs接收所有关键字参数，这样装饰器才能不关心原函数签名，达到“通用”的效果。
4.2 带参数的装饰器与原信息丢失问题
上面那个timer装饰器本身不带参数。如果我们要让装饰器能接收额外配置参数（比如设置超时时间），那就需要再加一层嵌套函数：
def timeout(seconds): def decorator(func): def wrapper(*args, **kwargs): # 这里可以读取 seconds 做判断 print(f"设置了 {seconds} 秒超时") return func(*args, **kwargs) return wrapper return decorator @timeout(seconds=5) def fetch_data(): return "data"为什么需要三层嵌套？因为timeout(seconds=5)要先执行一次，返回一个装饰器；这个装饰器再接收被装饰的函数；装饰器内部再返回包装函数。每一层都有自己的作用域，seconds参数会被decorator闭包捕获，所以内部wrapper可以随时访问它。这就回答了“带参数的装饰器为什么要包三层”的问题——每一层都是为了固定住一个层次的变量。
另外还有一个非常常见的问题：用了装饰器之后，原函数的元信息（比如__name__、__doc__）会被wrapper覆盖。你没看错，我见过不少人调试时发现函数名全变成了wrapper，一脸懵。解决办法是使用functools.wraps：
import functools def timer(func): @functools.wraps(func) def wrapper(*args, **kwargs): # ... return func(*args, **kwargs) return wrapperfunctools.wraps会把原函数的__name__、__doc__、__module__等属性复制到wrapper上，让装饰后的函数看起来就像原函数一样。这个细节在实际使用日志、文档生成、调试时都非常重要，如果你做的是一个公共库，不写functools.wraps几乎等于给使用者埋雷。
4.3 类装饰器与装饰器的实际应用
除了函数装饰器，Python 还支持类装饰器。类装饰器利用类的__call__方法，让类实例可以被像函数一样调用：
class CountCalls: def __init__(self, func): self.func = func self.calls = 0 def __call__(self, *args, **kwargs): self.calls += 1 print(f"第 {self.calls} 次调用") return self.func(*args, **kwargs) @CountCalls def greet(name): return f"Hello, {name}" greet("Alice") greet("Bob")实际开发中，装饰器的应用场景非常多，我列举几个最常见的：
- 日志记录：自动在函数执行前后打日志。
- 权限校验：检查当前用户是否有权限调用某个函数。
- 缓存：某些函数对相同输入的返回结果一样，可以缓存结果避免重复计算。
- 重试机制：网络请求失败时自动重试，最多重试 N 次。
- 事务管理：在函数开始前开启事务，结束后提交或回滚。
比如一个简单的重试装饰器，我第一次写的时候觉得思路很绕，理清之后发现逻辑其实很清晰：
import time def retry(max_retries=3, delay=1): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: print(f"第 {attempt + 1} 次尝试失败: {e}") if attempt < max_retries - 1: time.sleep(delay) raise RuntimeError(f"{func.__name__} 重试 {max_retries} 次后仍失败") return wrapper return decorator这种代码在线上接口调用、数据库操作等需要容错的场景下几乎是标配。你还不用到处复制粘贴一样的 try-except 逻辑，装饰器把容错逻辑抽离出来，各函数保持干净和专注，这正是装饰器最大的设计价值：关注点分离。
5. 常见问题与排查技巧实录
5.1 生成器只能用一次的问题
这是初学者最容易犯的一个错。生成器对象有点“一次性筷子”的意思，用完就没了。比如：
gen = (x * x for x in range(10)) print(sum(gen)) # 输出 45 print(sum(gen)) # 输出 0，因为生成器已经空了为什么第二次sum是 0？因为第一次遍历时生成器已经把所有值产出并丢弃了，第二次再迭代时没有任何元素。这一点跟列表完全不同，列表可以反复遍历。解决办法也简单：如果只是想让生成器能被多次使用，不要保存生成器，而是保存生成器表达式对应的数据计算逻辑，需要时重新创建生成器；或者，如果数据确实不大，直接把它转成列表缓存起来。
这个坑在我做大数据统计时也踩过：用一个生成器统计完行数之后，后面还要用它做另一项统计，结果发现数据全是空的，排查了半天才意识到是生成器被消费完了。从那以后我养成了一个习惯：生产环境里涉及多次遍历的数据，先评估数据量，小就转列表，大就用两个独立的生成器，绝对不共享同一个生成器对象不同遍历。
5.2 迭代器与可迭代对象的混淆
我前面已经明确了：可迭代对象不一定是迭代器，迭代器一定是可迭代对象。但实际写代码时仍然会混淆。判断方法简单直接：
from collections.abc import Iterator, Iterable my_list = [1, 2, 3] print(isinstance(my_list, Iterable)) # True print(isinstance(my_list, Iterator)) # False my_iter = iter(my_list) print(isinstance(my_iter, Iterator)) # True再强调一遍：for循环可以在可迭代对象上工作，但它在内部一定会先调用iter()把它变成迭代器。有时候你给for循环传一个迭代器也没问题，因为iter()对迭代器只是返回自身。但这种“迭代器同时也可迭代”的设定，容易让初学者误以为列表和迭代器是同一个东西。
5.3 装饰器顺序与性能排查
如果一个函数被多个装饰器装饰，它们的执行顺序是从下往上的。什么意思？看代码：
@timer @retry(max_retries=2) def fetch_url(url): pass执行流程是：retry先装饰fetch_url，然后timer再装饰retry的结果。所以在实际调用时，timer在最外层，先被触发，然后才进入retry的逻辑。这个顺序非常重要，如果你想让重试逻辑包含计时，就按上面的顺序写；如果你想只对重试成功的调用计时，顺序就要反过来。我调试装饰器嵌套问题时，第一件事就是检查装饰器顺序，十有八九问题都出在这里。
另外补充一个性能排查的经验：装饰器本身有开销，因为每次调用都要经过额外的一层函数。在性能关键的代码路径上，如果确认某个装饰器不需要了，直接删掉而不是留下空壳判断；因为即便装饰器内部什么都没做，一次函数调用仍然有几微秒的固定成本。虽然单次影响很小，但如果你在循环里调用十万次装饰后的函数，性能影响就不可忽略了。
5.4 列表推导式 vs 生成器表达式：什么时候用哪个
写了不少代码，我发现很多同学在这两个选择上没有一个清晰的标准。这里给出一个我自己的判断依据：
- 如果你需要多次遍历数据，或者需要索引访问（比如取第 5 个元素、切片），选列表推导式。
- 如果你只需要一次遍历，或者数据量可能很大，选生成器表达式。
- 如果你要把数据传给后续用
for循环处理，但不确定遍历几次，先转成列表更稳妥。 - 如果数据来源是文件流、网络流，追求稳定内存占用，生成器表达式基本是唯一选择。
这个决策逻辑几乎能覆盖 90% 的场景。剩下的 10% 需要根据实际业务场景做权衡，但核心判断维度始终是“内存占用”和“遍历次数”这两个变量。
结束语
Day 48 的内容我分享完了，最后聊一点自己的体会。很多人学 Python 学到进阶部分就觉得“这些东西平时用不上”，但实际上，你写的每一段高效数据处理代码、每一个优雅的可复用组件，背后几乎都有这三样东西的影子。我自己在项目重构中，最常见的优化手段就是把一个返回大列表的函数改成生成器，或者把一个重复的校验逻辑抽成装饰器，效果立竿见影。你可以试着把自己写过的一段代码拿过来改造一下，把某个列表推导式改成生成器表达式，或者给一个函数加上装饰器，亲身体验一次这种“机制级”的优化带来的差异。这种体会比看十篇文章都管用。
