用list存所有爬取结果会爆内存，因其连续存储且扩容需拷贝，而爬虫只需流式处理；应改用生成器yield逐条产出、配合session流水线消费。
为什么用 list 存所有爬取结果会爆内存
爬虫一跑几百页、每页几十条数据，如果用 results = [] 一路 append()，最终生成一个几万甚至几十万个字典的列表，内存占用会线性上涨。Python 的 list 是连续内存块，扩容还可能触发多次拷贝；更关键的是——你往往不需要“全量在内存里”，只是要逐条处理、存库或写文件。
典型症状：MemoryError、进程被系统 OOM killer 杀掉、爬到一半机器变卡、ps aux 看到 Python 进程 RSS 飙到几个 GB。
- 不是数据量大就一定得换语言，而是数据结构没选对
-
list适合随机索引访问，爬虫流水线式处理根本用不上这个能力 - 哪怕只做统计或简单清洗，也建议边取边算，而非先囤后算
用 yield 改写解析逻辑，让函数变生成器
把原来返回 list 的解析函数，改成每次 yield 一条结构化数据。调用方用 for item in parse_page(html) 迭代，就不会一次性加载全部。
def parse_page(html):
soup = BeautifulSoup(html, "lxml")
for li in soup.select("ul#post-list li"):
yield {
"title": li.h2.get_text(strip=True),
"url": li.a["href"],
"date": li.find(class_="date").text.strip()
}
- 函数体里不能同时存在
return value和yield（除非return不带值，用于提前退出） - 不要在生成器里做耗时操作（如写文件、发请求），否则会阻塞整个迭代流
- 如果解析逻辑复杂，可把提取字段的代码拆成独立函数，保持
yield行干净
配合 requests.Session() + 生成器管道，控制并发与内存节奏
光有生成器不够——如果用 map(requests.get, urls) 一次性发起几百个请求，响应体还在内存里堆着，照样崩。得让请求、解析、消费串成流水线。
def fetch_pages(urls):
with requests.Session() as session:
for url in urls:
resp = session.get(url, timeout=10)
resp.raise_for_status()
yield resp.text
<h1>使用：请求 → 解析 → 处理，三阶段不堆积</h1><p>for html in fetch_pages(url_list):
for item in parse_page(html):
save_to_db(item) # 或 write_to_csv(item)
</p>
-
Session复用连接，减少 TCP 开销，也避免短时间创建太多Response对象 - 不要把
fetch_pages的结果转成list，比如pages = list(fetch_pages(...))—— 这就又绕回去了 - 如果目标网站反爬严，可在
fetch_pages内加time.sleep()，但别加在生成器外层循环里（那会拖慢整体吞吐）
什么时候不该硬上生成器
生成器不是银弹。有些场景强行用反而更麻烦，甚至出错：
- 需要反复遍历同一组数据（比如先统计总数，再按条件筛选）——生成器只能单向消费一次，得缓存或重请求
- 下游库强制要求
list或pandas.DataFrame（如某些可视化函数），这时可分批生成，比如每 1000 条list(itertools.islice(gen, 1000))处理一次 - 异步爬虫（
aiohttp）中，async def函数不能直接yield，得用async for+AsyncGenerator，语法和调试成本明显上升
真正省内存的关键，是让数据“流起来”，而不是卡在某个中间容器里。生成器只是最轻量的流接口，但要不要用、怎么接、和谁配，得看你的数据规模、处理逻辑和错误容忍度——比如网络失败时，生成器中断后很难续传，这时候可能得搭配检查点机制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
