Python 读取 CSV 用 csv、pandas 还是 polars：按文件规模与类型约束选

同一个 CSV 文件，清洗脚本、报表分析和大文件筛选并不适合用同一套读取方式。Python 自带的 csv 适合逐行处理，pandas.read_csv() 适合快速得到可分析的 DataFrame，polars.read_csv() 更适合把类型、列裁剪和扫描规模写得明确。先看数据量、后续操作和类型容忍度，再决定依赖哪个库，通常比单纯比较读取速度更可靠。

先按任务判断，而不是按库的名气判断

假设每天收到一个 orders.csv。任务 A 只需要逐行检查订单号和金额，任务 B 要按地区汇总并导出报表，任务 C 则要从数 GB 的文件里挑出最近一天的记录。三者的“读入”其实不是同一个动作。

你可以按这个实用逻辑做判断：后续需不需要对整表做批量运算？业务场景能不能接受一次性把全量数据加载进内存？关键字段是不是必须固定为指定类型？有没有定位坏行、跳过异常数据的需求？这些问题的答案，比单纯看“哪个库读取速度更快”更能选出适配场景的方案。

三种读取路径分别解决什么问题

csv：把每一行当成明确的输入

标准库适合轻量脚本、流式校验和自定义清洗。使用文件对象时保留 newline=""，让 CSV 模块自己处理换行和引号。

import csv

with open("orders.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        if not row["order_id"]:
            continue
        amount = float(row["amount"])
        print(row["order_id"], amount)

它不会自动把金额、日期或者空字符串转换成对应的业务类型，这看起来需要多写几步转换代码，反过来也有边界清晰的好处。遇到一行不符合格式的数据，你能拿到精确的行号，处理完异常后还能继续跑完剩下的流程。

pandas.read_csv()：先得到一张可分析的表

如果读完CSV马上要做筛选、分组、缺失值填充或者多列联合计算，用DataFrame能省掉很多手写的拼接胶水代码。

import pandas as pd

orders = pd.read_csv(
    "orders.csv",
    usecols=["region", "amount"],
    dtype={"region": "string"},
)
summary = orders.groupby("region", dropna=False)["amount"].sum()

文件很大时，不要默认整表读入。chunksize=50_000 会返回分块迭代器，可以对每块聚合，再合并结果；但分块逻辑需要自己保证各块的类型和异常策略一致。

polars.read_csv()：把列和类型边界写出来

Polars 适合希望在读取阶段就裁剪列、控制类型推断或限制读取行数的任务。它支持 schema_overrides 局部覆盖推断类型，也能用 n_rows 做小样本核对。

import polars as pl

orders = pl.read_csv(
    "orders.csv",
    columns=["region", "amount"],
    schema_overrides={"region": pl.String, "amount": pl.Float64},
    n_rows=100_000,
)
summary = orders.group_by("region").agg(pl.col("amount").sum())

如果任务要保持惰性查询，不要先调用 read_csv() 再接 lazy()；官方文档建议直接用 scan_csv()，这样读取阶段仍有机会配合后续筛选。

四个维度决定最后的选择

不要把这张表格当成性能排行榜。CSV的实际读取耗时会受编码、引号规则、每行列宽、磁盘读写速度、数据脏污程度等很多因素影响；更重要的是，选型时优先保证异常可追溯、结果可复现核对，比追求极致速度更稳妥。

两个容易误判的边界

类型推断成功，不等于业务类型正确

邮编、订单号和带前导零的商品编码都很容易被自动类型推断误判成数字类型。一旦前导零被丢弃，后续不管用多快的库都没法恢复正确数据。针对这类字段一定要显式指定为字符串类型，还要在样本校验环节特意核对字段首尾的取值是否符合预期。

小样本正常，不等于整文件正常

前几百行没有坏数据，并不能证明文件后半段的引号和列数都正确。正式任务应记录总行数、空值数量、关键列类型和异常行数。Polars 的 infer_schema_length、pandas 的分块读取和标准库的逐行校验，都是不同的取舍，不要混成一个“兼容开关”。

可以直接采用的决策表

• 只做清洗、校验、转换后写出：csv.DictReader。
• 需要探索数据、分组和多列分析：pandas.read_csv()，先写 usecols 和关键 dtype。
• 需要列式表达式、显式 schema 或大文件惰性扫描：polars.scan_csv()。
• 需要兼容已有 pandas 生态：不要为了换库重写整条业务链路，优先从提前裁剪读取列、分块读取这类低改造成本的方案入手优化。

第一版实现建议配套写一个轻量的核对脚本：打印读取后的总行数、列名列表、关键字段类型，再输出两条样例数据。它的作用远大于一段只返回“读取成功”的日志，能帮你尽早发现问题。

常见问题

CSV 文件只有几千行，也需要 Polars 吗？

不一定。如果项目本身已经引入了pandas依赖，继续用pandas往往能降低后续的维护成本；如果只是需要逐行做简单格式转换，标准库csv反而更轻量。选择Polars的理由应该来自它的表达式语法、严格的类型边界或者后续列式计算能力，而不是仅仅因为文件名后缀是CSV。

pandas 的 chunksize 能完全解决大文件内存问题吗？

它确实能降低单次读入的数据量，但聚合结果、大体积字符串列和业务侧临时缓存仍然可能占用大量内存。每处理完一个数据块都要检查列类型是否正确，同时不要把所有处理完的块再统一收集到一个大列表里。

为什么用了 polars.read_csv().lazy() 还不够懒？

因为文件已经被 read_csv() 读成 DataFrame，再调用 lazy() 只是把现有数据包装成惰性对象。要让读取本身参与优化，应从 scan_csv() 开始。

读取失败时应该先换库吗？

先确认文件的编码、分隔符、引号规则、列数和坏行的具体位置。随便换个解析库可能暂时绕过报错，但相当于把输入数据本身的质量问题隐藏起来，反而给后续流程埋坑；把异常样本单独存好，才能后续逐步固定统一的解析契约。

最后的核对清单

上线前至少核对四件事：关键字符串列没有丢前导零；读取方式与内存预算匹配；坏行处理策略有日志；样例结果与原始文件逐行抽查一致。做到这四点，csv、pandas 和 Polars 的选择就从偏好问题变成了可验证的工程决策。