Posit（RStudio母公司）和Polars, Inc.联合发布了一份官方速查表，把这个用Rust写成的Python数据处理库的核心语法压进几页纸：Series、DataFrame、LazyFrame三种数据结构，eager与lazy两套API，read_/scan_/write_/sink_四类读写函数。配套的是O'Reilly今年出版的新书《Python Polars: The Definitive Guide》。速查表里没有一个性能数字，纯粹是语法手册，但它标志着一件更大的事：一个2020年才从个人项目起步的库，已经被主流出版社和工具生态当作要认真学、认真用的东西对待。
速查表能让你记住怎么写，记不住的是为什么值得从pandas迁移过来。答案不在语法里，在lazy API背后的查询优化器和流式执行引擎，这也是Polars真正对pandas、DuckDB、PySpark构成威胁的地方。
从Rust个人项目到O'Reilly出书
Polars的起点很小。Ritchie Vink在2020年6月提交了第一行代码，最初只是他学习查询引擎、Apache Arrow和Rust的练习项目。2021年2月公开亮相，2023年8月公司化，2024年7月发布生产就绪的1.0版本。四年时间，从一个人的业余项目走到有专门公司运营、有O'Reilly出书、有Posit这样的成熟开源基金会合作方站台。
有一处细节需要提醒：速查表当前标注对应版本为1.43.0，页面更新日期写着"2026年8月"——比新书2025年2月的出版日期还晚一年多。这种时间线本身就不太对劲，更像是网页缓存或版本号占位造成的噪声，而不是真实的发布节点。想核对Polars具体走到哪个版本，最好直接去官方文档确认，别照单全收网页上的日期戳。
谓词下推、投影下推：懒惰为什么更快
pandas执行代码是写一行跑一行。Polars的lazy API不这样：你先搭一条查询计划，调用.collect()才真正执行。中间这一步，优化器会做谓词下推（尽早过滤，减少要处理的数据量）和投影下推（只读用得到的列，其余直接丢弃）。
这不是纸面概念。Polars官方架构文章给过一个具体例子：同一段查询，加上优化器之后，耗时从约544毫秒降到135毫秒，接近四倍提升。
速查表里那些over()窗口表达式、group_by_dynamic()时间分组、rolling()滚动窗口，语法看着简单，背后都要靠这套优化器把计算量压下去，这才是Polars区别于pandas的核心，不只是"方法链好看"这种表面差异。
和DuckDB、PySpark比，到底快多少
有了优化器和流式引擎（数据超过内存也能处理）撑腰，Polars开始正面对标DuckDB和PySpark。官方在2025年5月做的PDS-H基准测试里，数据规模放大十倍（从SF-10到SF-100）之后，差距被明显拉开。
在SF-10这种较小规模下，Polars流式引擎（3.89秒）反而比DuckDB（5.87秒）更快；但数据放大到SF-100，DuckDB反超流式引擎，Polars传统内存引擎更是被甩开近八倍。这说明流式引擎不是万能加速器，官方文档自己也写明：不支持或不适合流式处理的操作，会自动回退到内存引擎，收益取决于具体查询形态。
另有一份标注2026年6月的测试称，Polars单机比PySpark快约6.4倍，分布式配置下快约3.2倍——同样卡在那个可疑的未来日期上，需要审慎对待。
- 风险.这些数字都来自Polars自己发布的博客，没有第三方复现，"比PySpark快6倍"更接近营销素材，不是中立测评。
谁该动，谁先别急
对已经熟悉pandas的数据分析师，语法迁移成本不算高：DataFrame没有行索引、方法链取代原地修改，速查表基本能覆盖日常写法。真正要花时间适应的是lazy API和流式引擎的边界——什么时候该用scan_*延迟读取、什么时候该切engine="streaming"，这些判断需要跑几次explain()和profile()才能摸清楚。
语法门槛低，工程判断门槛不低。
对企业级选型者，官方基准数据能作为参考起点，但不该是唯一依据。Polars仍是一个1.0发布刚过一年多的年轻工具，生态兼容性、社区支持、调试链路都还在补课，跟DuckDB、Spark这类已经跑了多年生产环境的系统相比，稳定性还需要更多独立场景去验证。
- 建议.先拿自己的真实查询跑一遍
lf.explain()和lf.profile()，别只信供应商自测的跑分。