read_csv默认慢因dtype未指定导致类型推断：先扫描部分行再回退重读，易出错且耗时；正确做法是用列名匹配的dtype字典（如{'col': 'Int64'}），配合usecols和low_memory=False禁用推断。
为什么read_csv默认很慢？dtype不指定会触发类型推断
Pandas 读 CSV 时默认对每列做类型猜测（inference），它会先扫描部分行，再回退重读——这个过程不仅耗时，还容易出错。尤其当某列前1000行全是数字，第1001行突然出现 "N/A"，pandas 就会把整列升为 object，后续计算变慢，内存占用翻倍。
- 不指定
dtype：pandas 可能将整数列存成object，哪怕数据全是1, 2, 3 - 字符串列若未显式设为
dtype='string'或dtype='category'，默认用object，内存多占 2–5 倍 - 推断失败后还会触发
low_memory=True的分块重读逻辑，反复 IO + 内存拷贝
怎么写dtype参数才真正生效？别只写字符串名
dtype 必须是字典，key 是列名（或列索引），value 是具体类型；只传一个字符串（如 dtype=str）会被忽略。
- 列名不确定？用
usecols先限定读取范围，再配dtype - 数值列优先用
pd.Int64Dtype()（支持 NaN）或np.int32（不支持 NaN，更省内存） - 字符串列强烈建议用
dtype='string'（pandas 1.0+），比object更快、更省内存 - 类别型字段（如状态、地区）直接设
dtype='category'，可压缩 70%+ 内存
df = pd.read_csv('data.csv',
dtype={'user_id': 'Int64',
'status': 'category',
'name': 'string'},
usecols=['user_id', 'status', 'name'])low_memory=False到底在关什么？不是“关了就快”
low_memory 控制是否启用分块类型推断。设为 False 并不提速，只是让 pandas 一次性读完所有行再统一推断类型——这反而可能爆内存，且仍会推断错。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 真正该做的是：关掉推断，自己定死
dtype - 所以通常应同时设置：
low_memory=False+ 显式dtype字典 - 如果连列名都未知，先用
nrows=100快速采样，用pd.api.types.infer_dtype()看各列典型类型，再写dtype
还有哪些小动作影响实际速度？skiprows和chunksize别乱用
-
skiprows 若传函数（如 lambda x: x ），每行都调用一次，比传整数列表慢 3–5 倍
-
chunksize 适合流式处理，但单次读全量时设它反而引入额外循环开销
- 确保文件编码正确，
encoding='utf-8' 比默认的 'utf-8-sig' 略快；含 BOM 的文件才需后者
- 大文件优先考虑
pyarrow 引擎：engine='pyarrow'，配合 dtype 可提速 2–4 倍（需安装 pyarrow）
skiprows 若传函数（如 lambda x: x ），每行都调用一次，比传整数列表慢 3–5 倍
chunksize 适合流式处理，但单次读全量时设它反而引入额外循环开销encoding='utf-8' 比默认的 'utf-8-sig' 略快；含 BOM 的文件才需后者pyarrow 引擎：engine='pyarrow'，配合 dtype 可提速 2–4 倍（需安装 pyarrow）最常被忽略的一点：dtype 字典里的列名必须和 CSV 实际列名完全一致（包括空格、大小写），哪怕只差一个空格，那一列就退回默认推断——速度和内存优势全丢。
立即学习“Python免费学习笔记（深入）”；
