Python爬虫崩溃主因是pandas内存处理不当：read_csv()全量加载致OOM；chunksize误用拼接仍爆内存；to_csv()缓冲全量数据；字符串列隐式膨胀3–5倍。应分块处理、流式写入、截断/哈希长文本。
Python爬虫本身不会因为“数据量大”直接崩溃，真正崩溃的通常是后续的数据处理环节——尤其是用 pandas.read_csv() 一次性加载GB级文件、或用 df.to_csv() 全量写入时内存爆满、进程被系统OOM Killer干掉。
为什么 pandas.read_csv() 会触发崩溃而不是报错？
它默认把整个文件读进内存构建成 DataFrame，不校验可用内存。当文件实际占用内存超过系统剩余物理内存（尤其 Windows 上“已缓存”内存不释放），read_csv() 就会卡住、无响应，最终被系统强制终止，错误日志里往往只看到 MemoryError 或直接 Process finished with exit code -9（Linux/macOS）或 APPCRASH（Windows）。
- 典型诱因：爬虫拉回一个 2.3GB 的 CSV，本地只有 8GB 内存，且 Chrome、PyQt5 等其他进程已占去 4GB+
- 注意：
low_memory=False不是解药，它只是关掉类型自动推断警告，反而可能让内存峰值更高 - 真实瓶颈不在磁盘 IO，而在 Python 对象内存开销：一个字符串列在 pandas 中实际占用内存可能是原始文本的 3–5 倍
用 chunksize 分块读取，但别直接拼接
很多人以为设了 chunksize=10000 就万事大吉，结果在循环里写 all_df = pd.concat([all_df, chunk])，等于又把所有 chunk 全部加载进内存——和没分块一样。
- 正确做法：对每个
chunk独立清洗、过滤、转换，立刻丢弃（不保留引用） - 若需聚合统计（如计数、均值），用
sum()/mean()等支持 chunk-wise 的方法，而非先存再算 - 示例：统计某列非空值数量
total_count = 0<br>for chunk in pd.read_csv("data.csv", chunksize=5000):<br> total_count += chunk["price"].notna().sum()
流式写入：避免 to_csv() 积压内存
df.to_csv() 默认缓冲全部内容再刷盘；如果 DataFrame 有百万行，即使你只调用一次，也会在写入前把整份字符串序列化内容塞进内存。
立即学习“Python免费学习笔记（深入）”；
- 安全替代：用
csv.writer手动逐行/逐块写入，控制内存驻留量import csv<br>with open("output.csv", "w", newline="", encoding="utf-8") as f:<br> writer = csv.writer(f)<br> writer.writerow(["url", "title", "status"]) # header<br> for chunk in pd.read_csv("input.csv", chunksize=1000):<br> for _, row in chunk.iterrows():<br> writer.writerow([row["url"], clean_title(row["html"]), row["status"]]) - 若必须用 pandas 写，至少加
mode="a"+header=False避免重复写表头，并确保每次只传入一个 chunk
真正容易被忽略的点：字符串列的隐式膨胀
爬虫数据里大量 URL、HTML 片段、JSON 字符串，用 object 类型存进 pandas 后，Python 会为每个字符串单独分配对象头+引用，比 C 风格连续存储膨胀数倍。一旦列中存在长文本（比如抓到的完整网页源码），哪怕只有一行，就可能瞬间吃光内存。
- 对策一：读取时用
dtype={"html": "string"}（pandas ≥ 1.3）启用新 string 类型，内存更紧凑 - 对策二：对超长字段，读取后立即截断或哈希（如
df["html_hash"] = df["html"].apply(lambda x: hashlib.md5(x.encode()).hexdigest() if isinstance(x, str) else "")），原字段设为None释放引用 - 对策三：根本不用 pandas 存原始 HTML —— 抓完立刻解析提取关键字段，丢掉原始响应体
