Polars 处理大文件需用 scan_csv() + 惰性计算，而非 read_csv()；必须显式 select 和 filter 以实现列裁剪与谓词下推；多线程依赖文件格式与操作链，避免 collect() 前中断惰性流。
直接用 pandas.read_csv 或 pandas.read_excel 加载 10GB+ 数据，99% 会触发 MemoryError。这不是配置问题，是 Pandas 架构决定的——它默认把整张表一次性加载进内存并构建索引、类型推断、副本管理。Polars 不是“更快的 Pandas”，它是另一套设计：列式 + 惰性 + 多线程原生支持，处理 10GB 文件时内存峰值可压到 1–2GB，且实际计算快 5–20 倍。
为什么 pl.read_csv() 不能直接替代 pd.read_csv()
新手最常踩的坑：把 Pandas 习惯直接搬过去，写 df = pl.read_csv("big_file.csv")，结果内存照样爆。因为 pl.read_csv() 是立即执行（eager）模式，仍会全量加载——它只是比 Pandas 快一点，但没解决根本的内存压力。
- 真正该用的是
pl.scan_csv()：不读数据，只建逻辑计划 -
scan_csv返回的是LazyFrame，所有后续操作（filter、select、groupby）都只是追加节点，不触发计算 - 只有调用
.collect()才真正从磁盘读取、过滤、聚合、返回DataFrame - 若你只需要导出结果（比如统计后写 CSV），甚至可以跳过
collect()，直接用.sink_csv()流式写出
列裁剪和谓词下推必须手动写，Polars 不会自动猜
Polars 的优化器很聪明，但不会主动帮你删掉不用的列或提前过滤。如果你加载一张 300 列的用户日志，只算 user_id 和 revenue，却没显式 select，那 Polars 依然会把全部 300 列从磁盘读进来。
- 尽早调用
.select(["user_id", "revenue", "event_time"])，投影下推生效 - 过滤条件越早写越好，比如
.filter(pl.col("event_time") >= "2025-01-01")放在scan_csv后立刻执行，而非 collect 之后再 pandas 式过滤 - 时间范围、状态码、ID 区间这类高选择率条件，务必前置——能减少 90% I/O 和内存占用
- 避免在
collect()后再用 Pythonfor循环或.apply()，这会让整个数据集物化进内存再单线程处理
多线程不是开关，而是由数据源格式和操作链决定
Polars 默认启用多线程，但能否真正并行，取决于三件事：文件是否可分块（如 CSV、Parquet）、操作是否支持并行（filter/groupby/agg 都支持）、有没有阻断惰性流（比如中间 collect()）。
立即学习“Python免费学习笔记（深入）”；
- CSV 文件天然适合多线程扫描，但需确保无跨行换行符（即每行严格对应一条记录）
- Parquet 格式更优：
pl.scan_parquet()可按 Row Group 并行读，列剪裁效果也更强 - 避免在链中插入
.to_pandas()或.to_numpy()——这会强制物化并退出 Polars 并行上下文 - 如果最终要喂给 PyTorch 或 sklearn，别在 Polars 里
collect().to_pandas()，改用collect().to_numpy().reshape(...)直接转 NumPy 数组，少一次内存拷贝
最容易被忽略的一点：Polars 的 scan_* 系列函数对文件路径是“懒解析”的——它不检查文件是否存在、不校验 schema，直到 collect() 才报错。这意味着你在本地调试时一切正常，一上生产环境遇到权限或路径错误，会卡在最后一步才崩，排查成本陡增。建议在 pipeline 开头加一行 assert Path("data.parquet").exists() 主动防御。
