chunksize参数只属于pandas.read_csv等少数io函数，需作为顶层参数传入，返回textfilereader对象；设为1000表示每次读1000行，须用for循环或get_chunk()遍历，且应显式指定dtype和na_values以防类型不一致。
chunksize参数到底传给谁？不是read_csv的兄弟函数
它只属于 pandas.read_csv（以及少数几个 IO 函数如 read_json），不是 pd.DataFrame 方法，也不是 groupby 或 apply 的参数。传错地方会直接报错：TypeError: read_csv() got an unexpected keyword argument 'chunksize'——说明你可能写在了 pd.read_csv(...).chunksize 后面，或者误加在 pd.concat() 里。
正确姿势是：把 chunksize 当作 read_csv 的顶层参数传进去，返回的是一个 TextFileReader 对象，不是 DataFrame。
-
chunksize=1000表示每次读 1000 行，生成一个可迭代对象 - 不设
chunksize就是一次全读进内存，哪怕文件有 20GB - 设了但没用
for循环或get_chunk()拿数据，等于白设
怎么安全地遍历chunk？别直接 for df in reader
看似最直觉的写法 for df in pd.read_csv("big.csv", chunksize=5000) 确实能跑，但容易掩盖两个隐患：类型转换失效、缺失值处理不一致。因为每块独立解析，如果某列前 5000 行全是整数，pandas 会推断为 int64；下一块出现 NaN，就强制转成 float64，后续 concat 时列类型可能错乱。
更稳妥的做法是显式统一 dtypes 和 na_values：
reader = pd.read_csv(
"data.csv",
chunksize=5000,
dtype={"user_id": "string", "score": "float32"},
na_values=["NULL", "", "N/A"]
)
- 提前指定
dtype可避免类型抖动，也省内存 - 若原始文件无表头，必须加
header=None，否则第一块会当列名，第二块开始错位 - 不要在循环里反复调
df.fillna().groupby().agg()，先做轻量过滤或映射，重计算留到合并后
chunksize设多少才不卡不死也不太慢？看内存和磁盘IO
没有万能值。设太小（比如 chunksize=100）会导致频繁磁盘寻址、Python 对象创建开销压倒计算本身；设太大（比如 chunksize=500000）又可能触发 OOM，尤其在 pandas 1.5+ 默认启用 copy_on_write=False 后，某些链式操作隐式复制变多。
经验参考（8GB 内存机器）：
- CSV 列少（chunksize=10000
- 含长文本或嵌套 JSON 字符串：降到
5000甚至2000 - SSD + 压缩 CSV（.csv.gz）：可比 HDD 时提高 30%～50%，但解压耗 CPU，别盲目拉高
真正卡顿往往不是 chunksize 本身，而是你在每块里调了 df.merge() 或 df.apply(lambda x: requests.get(...)) ——这种 I/O 或网络阻塞跟分块逻辑无关，得单独拆出来。
合并结果时 concat容易丢索引或重复计数
默认 pd.concat([df1, df2]) 会保留各 chunk 的原始行号（0, 1, 2… 0, 1, 2…），导致最终 DataFrame 出现大量重复索引。虽然不影响计算，但调 df.loc[0] 会返回多行，df.drop_duplicates() 也可能误删。
解决很简单，但常被跳过：
- 加
ignore_index=True：重排全局索引，最常用 - 需要保留原始位置信息？改用
df.assign(chunk_id=i, row_in_chunk=df.index)显式记录 - 如果最后要写回 CSV，且原文件有索引列，别依赖
index_col=0自动识别——分块读时它会被当普通列，得手动df.set_index("id", drop=True)
真正麻烦的是聚合类任务（比如求全量均值）。不能对每个 chunk 算一次 mean 再平均——得保存每块的 sum 和 count，最后总和除以总数。这个逻辑不在 chunksize 能自动解决的范围里。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
