9月2日，Polars创始人Ritchie Vink在官方博客发布2.0的首个预发布版本，正式版将在随后几周内落地。与常见的重大版本不同，Vink在开篇就把话挑明：2.0不追求炫目新功能，目标是清掉历史设计债，把默认值换成对多数人更合理的设置。如果一切顺利，绝大多数用户的升级体验应该是无感变快。
流式引擎转正
2.0影响最大的变化是所有LazyFrame查询默认运行在流式引擎上。官方给出的整体预期是轻松5倍的性能提升，内存占用同步大幅下降。之所以必须升大版本号，是因为流式引擎对join、group_by、unpivot等操作不再默认保证行序，依赖行序的代码升级后会拿到语义相同但顺序不同的结果。需要稳定行序的用户可以显式传入maintain_order参数，或者用pl.Config全局设置回退到旧的内存引擎，也可以在单条查询里直接指定engine参数。
这个默认值切换是典型的Polars式取舍：把顺序保证从隐式契约变成显式选项，换取流水线执行的自由度。数据处理领域为输出顺序付出的隐性成本很少被认真计算过，Polars选择让用户自己决定。官方同时发布了完整的迁移指南，把所有行为变化的检查点逐条列了出来。
为什么是现在
Polars这几年在Python数据栈里的位置越来越像pandas的替代品而不是补充：Rust实现、多线程执行、基于Apache Arrow的内存模型，处理十亿行级数据不需要集群。流式引擎的成熟是水到渠成，过去一年它已经在生产负载里被反复打磨，2.0只是把这条经过验证的路径设为默认。Vink在博客里说希望这次升级对用户来说是一段无聊的经历，语气里透着对自家测试覆盖的自信。
对下游生态的影响已经开始显现。各类依赖Polars输出的数据处理管道、notebook工具和云服务都在适配路径上，默认引擎变化意味着所有隐式依赖行序的下游代码都值得跑一遍回归测试。数据团队升级2.0的合理姿势是：先在预发布版上用真实查询跑分，重点检查join和group_by之后有没有依赖行序的逻辑。
技术上看，流式引擎的收益来自执行方式的重构：查询被拆成可以按批推进的流水线，数据不再需要整体装进内存，超内存数据集也能在单机上完成聚合。对常年依赖集群拆分作业的数据团队来说，这意味着一部分ETL作业可以直接下放到单机脚本，省去调度和序列化开销。Rust实现带来的内存安全与并发优势，也在这种负载里被充分利用。
版本节奏上，预发布到正式版之间官方还会根据反馈调整API细节，生产环境暂缓升级、先在CI里验证是稳妥做法。pandas统治Python数据分析超过十五年，挑战者换了一茬又一茬，Polars是目前最有机会改写默认选型的那个。2.0这步清理历史包袱的棋，比堆砌功能聪明得多。