直接drop_duplicates()会内存爆炸，因read_csv()默认全量加载且去重需构建全量哈希表；流式去重用chunksize+set逐块处理，适用于单列或组合键且重复不跨块；跨块需两遍扫描：先排序提取键与行号，再流式比对相邻行；须预处理空格、NaN、时区等干扰。
为什么直接 drop_duplicates() 会内存爆炸？
因为 read_csv() 默认一次性把整个文件读进内存，再调用 drop_duplicates() 时还要构建哈希表存所有已见的行——对千万级以上的 CSV，内存占用常超 10GB。这不是算法慢，是根本没机会跑完就被 Killed: 9 或 MemoryError 终止。
流式去重的核心思路是：不保存全部数据，只维护一个轻量“见过的键”的集合，并逐块读、逐块筛、逐块写。
关键限制：drop_duplicates() 本身不支持流式；必须自己控制读取粒度和去重逻辑。
用 chunksize + set 实现可控内存去重
适用于去重依据是单列或几列组合（如 id、email），且重复项不会跨 chunk 太远（否则会漏判）。这是最常用、最易控的方案。
立即学习“Python免费学习笔记（深入）”；
- 用
pd.read_csv(..., chunksize=N)每次读 N 行（建议 5k–50k，视内存调整） - 用
set存已出现过的 key 元组（如tuple(row[['uid', 'ts']])），比dict更省内存 - 每 chunk 内先过滤掉已在
seen中的行，再把新 key 加入seen - 用
to_csv(..., mode='a', header=False)追加写入结果文件
示例关键片段：
seen = set()
for chunk in pd.read_csv('big.csv', chunksize=10000):
# 假设按 'user_id' 和 'event_time' 联合去重
keys = chunk[['user_id', 'event_time']].apply(tuple, axis=1)
mask = ~keys.isin(seen)
chunk[mask].to_csv('dedup.csv', mode='a', header=False, index=False)
seen.update(keys[mask].tolist())
当重复行可能跨 chunk 时，必须用 sort_values() + shift() 两遍扫描
如果业务要求“全局严格去重”，且无法保证相同 key 的行在原始文件中聚集（比如日志乱序写入），那么仅靠一次流式过滤会漏掉跨 chunk 的重复。此时需两遍处理：
- 第一遍：读全文件，只提取去重字段 + 行号（
chunk.index或加usecols限定），排序后输出中间文件（或用tempfile.NamedTemporaryFile） - 第二遍：按排序后顺序流式读中间文件，用
shift()对比相邻行是否完全一致，只保留首次出现的行
注意：sort_values() 本身不流式，但可配合 awk 或 csvkit 预排序（Linux 下更稳）；Python 内做需分块排序+归并，复杂度陡增，不推荐纯 Pandas 实现。
避免踩坑：字符串空格、NaN、时区、类型不一致导致误判重复
真实数据里，'abc ' 和 'abc' 看似一样，但 tuple 判定为不同；NaN != NaN 会让含空值的行永远不被去重；datetime64 若未统一时区或精度（秒 vs 毫秒），也会失效。
- 预处理必须做：
strip()字符串、fillna('')或统一填占位符、dt.tz_localize(None) - 构造 key 时显式转类型：
row['ts'].strftime('%Y-%m-%d %H:%M:%S')比直接用Timestamp更可控 - 测试小样本时，手动检查
df.duplicated(subset=[...]).sum()和流式结果是否一致
真正难的不是代码长度，是确认你的“重复定义”在每行数据落地前，已经被干净、稳定地归一化了。
