polars 并非在所有场景都比 pandas 快几十倍，仅在单次操作超500万行、cpu长期100%、内存不足或读大文件（>1gb csv/parquet）、分组聚合、链式过滤等场景下凭借多线程+惰性求值显著提速4–30倍。
Polars 真的比 Pandas 快几十倍？先看你的场景
不是所有情况都值得切。如果你处理的是 read_csv 后不到 10 万行、内存绰绰有余、且只做简单清洗和绘图的数据，Pandas 完全够用，换 Polars 反而增加认知负担。
真正该切的场景很明确：单次操作 > 500 万行、CPU 利用率长期卡在 100%（单核）、collect() 前反复调试时发现中间结果已爆内存——这时 Polars 的多线程 + 惰性求值才真正起效。
- 读 CSV/Parquet 超 1GB：Polars 默认并行，Pandas 单线程，实测快 4–15 倍（取决于磁盘 IO 和 CPU 核数）
- 分组聚合（
group_by().agg()）：Polars 自动向量化 + SIMD，Pandas 依赖 Python 循环或 Cython 封装，差距拉大到 20–30 倍 - 链式过滤+列选择（如
.filter(...).select([...])）：Polars 惰性模式下会合并为一次扫描；Pandas 每步都生成新 DataFrame，内存翻倍
从 Pandas 切过去，哪些代码必须改？
API 高度相似，但关键几处不改就报错或降速：
-
pd.read_csv()→pl.read_csv()：没问题；但想跳过加载全量数据，得用pl.scan_csv()+.collect()，否则惰性优势归零 -
df[df["x"] > 1]→df.filter(pl.col("x") > 1)：Pandas 的布尔索引语法在 Polars 不支持，直接报TypeError: unsupported operand type(s) for &: 'Expr' and 'Expr' -
df.groupby("a").sum()→df.group_by("a").agg(pl.all().sum())：Polars 的group_by返回 LazyGroupBy / GroupBy 对象，没有.sum()这种快捷方法，必须显式agg() - 缺失值填充：
df.fillna(0)在 Polars 中是df.fill_null(0)，函数名不同，参数行为也略异（例如不支持字典按列填）
多线程不是“开箱即用”，它可能偷偷拖慢你
Polars 默认启用所有逻辑核心，但虚拟机/容器里常被限制 vCPU 数量。若你跑在 2 vCPU 的云服务器上，Polars 却试图启动 8 线程，反而引发调度争抢，耗时反超 Pandas。
验证方式很简单：import polars as pl; print(pl.threadpool_size())。若返回值远大于你实际可用的 vCPU，立刻设限：
import polars as pl pl.threadpool_size(2) # 显式设为可用 vCPU 数
- 本地开发机（8 核）：默认即可
- Kubernetes Pod（limit=1000m）：强制设为 1 或 2
- Docker 容器（
--cpus=1.5）：设为 1，避免线程饥饿
别信“越多越快”——线程数 ≠ 吞吐量，尤其当数据带宽（如 SSD 读速）成为瓶颈时，多线程只是空转。
别忽略 Arrow 兼容性这个隐性成本
Polars 内部用 Apache Arrow，好处是零拷贝、跨语言互通；坏处是某些 Pandas 生态工具不认它的类型，比如：matplotlib 直接画 pl.Series 会报 TypeError: float() argument must be a string or a real number，因为 Arrow 的 date64 类型 matplotlib 不识别。
- 绘图前加
.to_numpy()或.to_list()（小数据可接受） - 传给
sklearn前，用df.to_pandas()转回（注意：这一步会触发全量内存拷贝，慎用） - 写 Parquet 时，默认用 Arrow 格式，但老版本 Spark 可能读不了，需加
use_pyarrow=True参数兼容
Arrow 是底座，不是装饰。你用 Polars 越深，越早会撞上它和周边生态的边界——这不是 bug，是设计取舍。
