为什么Python写入大量数据到Excel特别慢_改用to_csv或XlsxWriter引擎优化I/O性能

有一类问题在Python数据处理场景下反复出现：数据量一大，代码就卡死。尤其是当你试图把一份几十万行、上百万行的DataFrame，用to_excel写进Excel文件时，这种感觉就更明显了。明明只是在干活，结果要么内存直接爆掉，要么程序跑到一半系统无情地Killed——这种体验，相信不少人都不陌生。

归根结底，问题不在于Python本身慢，而在于写入Excel的底层机制带来的“隐形成本”。

为什么 to_excel 写入百万行就卡死

根本原因不是 Python 慢，而是 pandas 默认用 openpyxl 引擎写入时，每写一行都会触发三件事：XML节点构建、样式对象初始化、以及单元格对象实例化。100 万行乘以 20 列，相当于生成上千万个Python对象——内存能不涨吗？GC压力能不大吗？更要命的是，openpyxl 默认以 DOM 方式构建整个工作簿的树结构，写完才序列化成 .xlsx 文件。这意味着整个过程无法流式释放，一旦数据量上来，MemoryError 或者系统 OOM Killer 杀进程，几乎是迟早的事。

换句话讲，不是你的数据太“重”，是 openpyxl 的写入模式本身就不适合大批量数据。

改用 xlsxwriter 引擎必须加 constant_memory=True

这是提速最关键的一步，也是很多人容易漏掉的一环。xlsxwriter 虽然不走 DOM 路线，但默认情况下仍然会缓存整张表的格式状态。只有启用 constant_memory=True，它才会切换为纯流式写入：边写边 flush 到磁盘，内存占用几乎恒定。实测下来，150 万行数据，内存仅占用约 80MB 左右——对比 openpyxl 的暴涨曲线，这几乎是降维打击。

正确的写法如下：

with pd.ExcelWriter('out.xlsx', engine='xlsxwriter', 
                    engine_kwargs={'options': {'constant_memory': True}}) as writer:
    df.to_excel(writer, index=False)

当然，凡事有代价。constant_memory=True 会禁用某些高级功能，比如你不能在写入过程中插入图表，也不能动态设置某列宽度后再写数据。所有格式都需要提前定义好，或者干脆放弃。但如果你只是要“把数据写出来”，这个取舍是完全值得的。

to_csv 真的比 to_excel 快几十倍？看场景

是的，但这句话的成立条件很严格——只限于“纯数据导出”场景。CSV 是纯文本流，没有格式、不需要类型推断、更不需要 XML 封装。to_csv 底层调用的是 C 实现的 fastcsv，写入 100 万行通常只需要 1 到 3 秒。

不过，现实世界中往往有几个约束条件需要注意：

• 如果你的数据里包含公式、合并单元格、条件格式、颜色或自定义字体——CSV 根本存不了，硬转就等于丢信息
• Excel 打开大 CSV 文件时，会自动弹出“文本导入向导”，列类型经常被误判（比如把带前导零的 ID 当成数字），这时候你需要额外加 dtype=str，或者用 Excel 的“从文本/CSV 导入”功能手动指定
• 如果 CSV 行数超过 1048576 行（Excel 的行数上限），Excel 只能打开前 1048576 行，剩下的直接截断——这时候要么切分文件，要么换数据库

真正该警惕的“伪优化”操作

网上不少教程推荐“分 chunk 写入 + ExcelWriter 循环 to_excel”，这个思路看起来合理，实际上反而更慢。因为每次调用 to_excel(sheet_name='Sheet1') 都会重建 worksheet 对象，重复初始化样式表、共享字符串池等开销，得不偿失。

真正有效的做法只有两个方向：

• 内存够，就一气呵成：直接用 df.to_excel(..., engine='xlsxwriter', ...)，别拆分
• 内存紧，就手动控制：用 chunksize 配合 xlsxwriter.Workbook 原生 API 逐批写入，绕过 pandas 的中间转换开销

最后想说一句：当你的数据稳定超过 50 万行时，不妨认真思考一下——“我真的需要 Excel 吗？”在很多场景下，CSV 配合 SQLite 或 DuckDB，往往比 Excel 更快、更稳、更易自动化。选择正确的工具，比硬刚一个工具要聪明得多。