drop_duplicates() 默认保留第一条记录，因其 keep='first' 参数按行扫描顺序去重，遇重复即丢弃后续行；若数据按时间递增追加，则需设 keep='last' 并确保时间列已升序排序。
为什么 drop_duplicates() 默认保留第一条记录？
因为 Pandas 的 drop_duplicates() 默认参数是 keep='first'，它按行扫描顺序去重，遇到重复项就丢弃后续行。如果你的数据是按时间递增追加的（比如日志表），那“最新记录”其实是最后出现的——此时默认行为反而保留了最老的一条。
解决方法很简单：把 keep 改成 'last'，但要注意这仅适用于你已按时间升序排列的情况。如果原始数据时间乱序，keep='last' 仍只看物理位置，不是逻辑时间。
- 先确认时间列是否已排序：
df['timestamp'].is_monotonic_increasing - 若未排序，必须先按时间列排序再去重：
df.sort_values('timestamp', inplace=True) -
drop_duplicates(subset=['id'], keep='last')才能真正保留每个id的最新记录
用 groupby().tail(1) 替代去重时要注意什么？
当你要基于多列判断重复、同时又依赖时间列选最新时，groupby().tail(1) 比 drop_duplicates() 更灵活，但它不直接“去重”，而是分组后取每组末尾行——前提是该组内时间已升序排列。
常见错误是忘记排序就直接 groupby(...).tail(1)，结果取到的未必是最新时间点的记录。
立即学习“Python免费学习笔记（深入）”；
- 正确顺序：
df.sort_values('updated_at').groupby('user_id', sort=False).tail(1) -
sort=False可避免 groupby 再次排序开销，前提是外层已排好序 - 如果内存吃紧，别用
inplace=True，改用链式赋值：df = df.sort_values(...).groupby(...).tail(1)，更安全
大数据量下 drop_duplicates() 卡住或爆内存怎么办？
当 DataFrame 超过千万行，drop_duplicates() 内部会构建哈希表并全量加载索引，容易触发 GC 压力或 OOM。这不是算法问题，而是 Pandas 对 chunk 处理不透明。
可行的绕过方式是改用 numpy_indexing + 分块处理，或者转向更底层的工具。
- 用
pd.read_csv(..., chunksize=100000)流式读取，维护一个全局seen_set = set()记录已见 key（如(id, version)元组） - 对每个 chunk，用
~df[['id']].apply(tuple, axis=1).isin(seen_set)过滤新记录，再更新seen_set - 更稳的选择：把数据导出为 Parquet，用
pyarrow.dataset或dask.dataframe做分片去重，支持磁盘溢出
为什么用 sort_values().drop_duplicates() 比 drop_duplicates().sort_values() 快得多？
顺序错了会导致重复计算。比如先 drop_duplicates() 再 sort_values()，等于对去重后的子集重新排序；而先排序再 drop_duplicates(keep='last')，Pandas 可利用已排序特性跳过部分比较（尤其在 C 实现层），实测在亿级数据上快 2–3 倍。
另外，sort_values() 若指定 kind='quicksort'（默认）在重复键多时退化严重，建议显式写 kind='mergesort' 保证稳定性和可预测性。
- 推荐写法：
df.sort_values('ts', kind='mergesort').drop_duplicates(subset=['uid'], keep='last') - 避免写法：
df.drop_duplicates(subset=['uid']).sort_values('ts')—— 丢失原始时间上下文，且无法保证“最新”语义 - 如果时间列含
NaT，sort_values()默认把它们排在最前，需加na_position='last'
