Python 数据处理：用 Polars 替代 Pandas 的临界点与迁移清单

Pandas 够用很多年，但数据量上到一定规模后，单线程执行与频繁的中间拷贝会成为瓶颈。Polars 不是“更快的 Pandas”，而是换了一套执行模型：惰性求值、多线程执行、列式内存布局。本文讲什么时候值得换、怎么换，以及哪些坑要提前避开。

一、判断临界点：三个信号

第一个信号是内存：DataFrame 占用超过可用内存一半，或者 groupby、merge 时频繁触发交换与拷贝。第二个信号是耗时结构：同样逻辑在 Pandas 里跑几分钟， profiling 显示时间花在逐行 apply 与多次中间物化上。第三个信号是并行：机器是多核，但 Pandas 始终只用一个核，CPU 利用率长期低于 30%。三个信号出现两个，就可以认真评估迁移；只出现一个，先优化 Pandas 写法往往更划算。

不要为了“新”而迁移。小数据、交互式探索、生态依赖重的场景（某些只支持 Pandas 的库），留在 Pandas 更稳。迁移的收益要大于重写与测试成本，这个账要先算。

二、核心写法差异：从命令式到表达式

Polars 的核心是表达式 API：df.filter(pl.col("amount") > 100).group_by("city").agg(pl.col("amount").sum())。与 Pandas 相比，差异不在语法长短，而在执行方式：惰性模式下，Polars 会先做谓词下推、投影裁剪，再生成执行计划，只读需要的列、只算需要的行。写迁移代码时，要把“先 filter 再 select 列”的顺序显式写出来，让优化器有机会工作。

常见坑有三处：字符串处理要用 str 命名空间而非 apply；缺失值语义要逐项核对，null 与 NaN 在两者里并不等价；时间类型与时区的解析规则不同，迁移后必须对时间列做抽样比对。建议先用小样本双跑，比对行数、聚合结果与空值计数，再全量切换。

三、迁移清单：分四步走

第一步，隔离 IO 层：把 read_csv、read_parquet 的调用集中到一处，Polars 的 scan_parquet 支持惰性扫描，大文件不要一次性读入内存。第二步，迁移纯变换逻辑：filter、select、with_columns、group_by、join，这些映射最直接，先做。第三步，处理特殊逻辑：自定义函数尽量改写成表达式，实在无法改写的用 map_elements 并标注它会成为性能瓶颈。第四步，双跑验证：同一输入下比对输出的行数、列顺序、聚合值与空值分布，差异超过容差就停下来查语义，而不是调参数蒙过去。

性能验证也要讲方法：同一台机器、同一份数据、冷热启动各跑三次，记录 P50 与 P95，不要只贴一次最快成绩。Polars 的优势在扫描、过滤、聚合类任务上最明显，在小数据逐行逻辑上未必更快，实测为准。

四、什么时候不换

数据量小、团队已熟悉 Pandas、上下游强依赖 Pandas 生态时，不换是正确选择。工具没有高低，只有是否匹配数据规模与团队成本。先在新项目或独立模块里试点 Polars，跑稳一个季度再扩大范围，比一次性全量重写更安全。