我们都接受了‘Python 税’，Pandas 3.0 刚刚降低了它。
发布: (2026年2月15日 GMT+8 14:51)
3 分钟阅读
原文: Dev.to
Source: Dev.to
我也遇到过：一个“只有”3 GB 的 CSV 文件，加载到 16 GB 机器上的 Pandas DataFrame 中，结果整个系统卡死。常见的解决办法——手动分块、删除列、祈祷 OOM（Out‑of‑Memory）之神宽恕——感觉像是为使用 Python 支付的税。
多年来，我们一直把这称作 Python Tax，自我安慰说对象 dtype 是灵活性的代价。实际上，它们是 RAM 浪费的巨大来源。
为什么旧方法低效
- 十多年里，Pandas 将字符串存储为 NumPy object dtype。
- 每个字符串都被包装在一个沉重的 Python 对象头部中，把简单的字符数组变成了指针碎片的混乱。
- 当有 1000 万行时，你不仅在存储数据，还在存储数百万个独立的 Python 对象。
Pandas 3.0 的颠覆性改变
随着 Pandas 3.0 的发布，默认的字符串存储切换为由 PyArrow 支持的专用 str 类型。无需特殊标志，也不需要调引擎——直接使用普通的 pd.read_csv() 即可。
基准测试结果
| 数据集 | Pandas < 3.0（内存） | Pandas 3.0（内存） | 降幅 |
|---|---|---|---|
| 混合类型（1000 万行） | — | 降低 53.2 % | |
| 纯字符串（1000 万行） | 658 MB | 267 MB | 降低 59.4 % |
这些数字 惊人：一次简单的升级就能让文本密集型数据的内存使用量削减超过一半。
启示
Pandas 3.0 并非完美，但对于以字符串为主的工作负载来说，忽视这次升级就等于为不必要的云资源买单。
你遇到过最离奇的 Pandas “Out of Memory” 故事是什么？
Repository: GitHub link