共计 4933 个字符，预计需要花费 13 分钟才能阅读完成。
前段时间我接了一个老系统的日志分析需求，需要从几个几十 GB 的日志文件里提取关键信息。我习惯性地写了个 readlines()，结果脚本跑起来没几秒，机器内存直接飙到 90%，然后就 OOM 崩溃了。当时就意识到，这种处理方式在面对大数据时简直是灾难。其实，Python 里有更优雅高效的解决方案：生成器（Generator）和迭代器（Iterator）。今天就带大家一探究竟，如何用它们来把‘内存爆炸’变成‘涓涓细流’。
你的内存，正在被悄悄“吞噬”吗？
大家在处理大量数据时，有没有想过，是不是真的需要把所有数据都一次性加载到内存里？很多时候我们只是想逐条处理数据，进行一些计算或过滤。如果数据量不大还好，一旦数据量飙升到几十万、几百万条，甚至是 GB、TB 级别的文件，直接一股脑地读进内存，后果就是我开头提到的内存溢出。
这时，生成器就像一个“按需取货”的工人，你问他要一条，他就给你一条，不会把整个仓库都搬过来。而迭代器呢，它其实是生成器工作的基础，大家可以理解为一套“协议”，只要对象实现了这套协议（即 __iter__ 和 __next__ 方法），就能像列表一样，用 for 循环逐个取出元素，但又不像列表那样占用大量内存。它们的核心思想都是： 延迟计算，按需取值 。
下面，咱们通过几个实操案例，彻底理解这两种内存优化利器。
第一步：传统方式——简单粗暴却暗藏危机
为了模拟一个大文件场景，我先创建一个包含百万行数据的文件。
import os
import time
import psutil # 用于监测内存
# 模拟创建一个大文件
file_path = "large_log_file.txt"
num_lines = 1_000_000 # 百万行
def create_large_file(path, lines):
print(f"正在创建包含 {lines} 行的大文件'{path}'...")
with open(path, 'w') as f:
for i in range(lines):
f.write(f"这是第 {i+1} 行日志数据，内容可能很长，包含各种信息。n")
print("文件创建完成！")
create_large_file(file_path, num_lines)
# 获取当前进程的内存信息
def get_memory_usage():
process = psutil.Process(os.getpid())
mem_info = process.memory_info()
return mem_info.rss / (1024 * 1024) # 返回 MB
# 传统方式读取文件
print("n--- 传统方式读取大文件 ---")
initial_memory = get_memory_usage()
print(f"初始内存使用: {initial_memory:.2f} MB")
start_time = time.time()
with open(file_path, 'r') as f:
all_lines = f.readlines() # 一次性读取所有行
# 这里我们只是读取，如果再进行处理，内存会更高
print(f"文件包含 {len(all_lines)} 行。")
end_time = time.time()
final_memory = get_memory_usage()
print(f"读取完毕！耗时: {end_time - start_time:.4f} 秒")
print(f"最终内存使用: {final_memory:.2f} MB")
print(f"内存增长: {final_memory - initial_memory:.2f} MB")
# 清理内存，如果 all_lines 列表非常大，GC 需要时间
del all_lines
import gc
gc.collect()
time.sleep(1) # 等待 GC 完成
print(f"清理后内存使用: {get_memory_usage():.2f} MB")
# 提醒下：# 这种方式看似简单，但如果文件有几 GB，甚至几十 GB，那你的内存就危险了。# 我当年就是这么踩的坑，结果服务器直接卡死，不得不改成流式处理。 小提醒： readlines() 会把文件的所有行作为一个列表加载到内存中。对于小文件来说没什么问题，但一旦文件达到几十 MB 甚至 GB 级别，你的程序可能会瞬间占用几百 MB 甚至几 GB 的内存，轻则程序卡顿，重则直接被系统“杀死”（OOM – Out Of Memory）。我的经验是，只要数据量超过百万级别，或者文件大小超过几十 MB，就得警惕这种读取方式了。
第二步：生成器登场——按需供给的艺术
现在，让我们请出生成器。它通过 yield 关键字，实现了“惰性计算”，每次只生成一个值，而不是一次性生成所有值。
import os
import time
import psutil # 用于监测内存
file_path = "large_log_file.txt" # 沿用第一步创建的文件
# 获取当前进程的内存信息
def get_memory_usage():
process = psutil.Process(os.getpid())
mem_info = process.memory_info()
return mem_info.rss / (1024 * 1024) # 返回 MB
# 生成器方式读取文件
def read_large_file_generator(path):
with open(path, 'r') as f:
for line in f: # 逐行读取是 Python 文件对象的默认行为，它本身就是迭代器
yield line # yield 关键字是生成器的魔法棒，它会暂停函数执行，返回一个值，并在下次调用时从上次暂停的地方继续。print("n--- 生成器方式读取大文件 ---")
initial_memory = get_memory_usage()
print(f"初始内存使用: {initial_memory:.2f} MB")
start_time = time.time()
line_count = 0
for line in read_large_file_generator(file_path):
# 这里可以对每一行进行处理，比如解析、过滤等
# print(f"处理行: {line.strip()[:50]}...") # 仅打印部分内容
line_count += 1
if line_count % 100000 == 0: # 每 10 万行打印一次内存，观察变化
print(f"已处理 {line_count} 行，当前内存使用: {get_memory_usage():.2f} MB")
end_time = time.time()
final_memory = get_memory_usage()
print(f"读取并处理完毕！总行数: {line_count} 耗时: {end_time - start_time:.4f} 秒")
print(f"最终内存使用: {final_memory:.2f} MB")
print(f"内存增长: {final_memory - initial_memory:.2f} MB")
# 清理文件
os.remove(file_path)
print(f"'{file_path}' 已删除。")
# 提醒下：# 大家用生成器函数时，记得它只执行一次，如果需要重复迭代，得重新调用函数生成新的生成器对象
#（别问我怎么知道的，初学时就犯过这种错误，以为可以像列表一样随便遍历，结果第二次就没数据了）。# 它的优势在于内存占用几乎是恒定的，只与当前处理的行相关，不会随文件大小线性增长。 小提醒： 对比一下两次的内存使用情况，你会发现，使用生成器读取文件时，内存占用几乎是平稳的，不会像 readlines() 那样飙升。这就是生成器的魅力——它只在需要时生成下一个数据，而不是一次性把所有数据都塞进内存。这意味着你可以处理远超你物理内存大小的文件。
第三步：迭代器——让你的对象也能“流”起来
生成器本质上就是一种特殊的迭代器。任何实现了迭代器协议（即包含 __iter__ 和 __next__ 方法）的对象都可以被 for 循环遍历。对于更复杂的场景，比如你需要从一个数据库游标、网络流或者自定义数据结构中“流式”地获取数据，就可以自己实现一个迭代器。
import time
# 模拟一个从某个数据源（比如一个巨大的结果集）逐个取数据的迭代器
class DataStreamIterator:
def __init__(self, max_items):
self.max_items = max_items
self.current_item = 0
print(f"数据流初始化，预计提供 {max_items} 条数据。")
def __iter__(self):
# 返回自身，因为这个类本身就是迭代器
return self
def __next__(self):
if self.current_item < self.max_items:
data = f"自定义数据项 -{self.current_item}"
self.current_item += 1
# 模拟数据获取或处理的延迟
# time.sleep(0.00001)
return data
else:
print("所有数据已生成完毕，停止迭代。")
raise StopIteration # 在没有更多元素时必须抛出 StopIteration 异常
print("n--- 自定义迭代器示例 ---")
# 创建一个迭代器对象，模拟从数据源获取 100000 条数据
my_data_stream = DataStreamIterator(100000)
processed_count = 0
start_time = time.time()
for item in my_data_stream:
# 模拟对每一项数据进行处理
# print(f"处理: {item}")
processed_count += 1
if processed_count % 20000 == 0:
print(f"已处理 {processed_count} 项数据...")
end_time = time.time()
print(f"所有 {processed_count} 项数据处理完毕！耗时: {end_time - start_time:.4f} 秒")
# 提醒下：# 实现 __next__ 方法时，别忘了在没有更多元素时抛出 StopIteration 异常，# 这是告诉 for 循环“我没东西了，可以歇着了”的信号。我以前调试时就忘记抛出，结果程序死循环了，# 只能强制终止，浪费了不少时间。小提醒： 自定义迭代器给了我们极大的灵活性，它能将任何我们希望按需生成的数据源变得可迭代。无论是网络请求、数据库查询结果、甚至是数学序列，只要我们遵循迭代器协议，就能高效地利用内存。
常见误区和我的经验总结
在实际开发中，生成器和迭代器虽然好用，但也有一些新手容易踩的坑。
-
忘记生成器 / 迭代器只遍历一次 ：很多初学者，包括我刚开始学时，会以为生成器像列表一样可以重复遍历。比如你创建了一个生成器
g = (i for i in range(10))，第一次for x in g:遍历完后，g就“空”了。如果你想再遍历一次，必须重新创建一个生成器对象。这是为了节省内存而设计的特性，理解这一点非常重要。 -
试图用下标访问生成器 / 迭代器元素 ：生成器和迭代器是按需生成的流式数据，不是列表或元组，不能用
gen[0]这种方式通过下标访问元素。想取第 N 个元素？你需要遍历到第 N 个，或者使用itertools.islice等工具（例如list(itertools.islice(gen, N-1, N))来获取第 N 个元素，但这会消耗前面的元素）。 -
滥用生成器 / 迭代器，过度设计 ：虽然生成器和迭代器很强大，但不是所有场景都适合。如果你的数据量很小，比如只有几十几百条记录，直接用列表可能更简洁，性能差异也不大，代码的可读性也更高。过度设计反而增加了代码的复杂性。我一般会根据数据量、内存限制和计算复杂度来决定是否使用它们。
经验总结
生成器和迭代器是 Python 处理大数据、优化内存的利器，掌握它们能让你在面对文件处理、数据流传输等复杂场景时游刃有余，将程序的内存消耗从“峰值”降低到“平稳”。
你平时在哪些场景用过生成器或迭代器？有哪些独到的经验或踩坑经历，欢迎在评论区分享！
