17370845950

真正需要的是掌握pandas高效读、算、查、写数据的核心机制：read_csv需显式设dtype和usecols防内存暴增；groupby优先用agg/transform而非apply；merge须显式指定how并处理NaN；loc赋值禁用链式索引。

这标题不是学习路线，是营销包装——真正需要的不是“第260讲”，而是搞懂 pandas 怎么高效读、算、查、写数据，以及为什么某些操作一跑就卡、结果不对、内存爆掉。

为什么 pd.read_csv() 读完数据内存翻倍？

默认参数会强制推断类型，尤其对含空值的数字列，pandas 会升格为 object 或高精度 float64；字符串列没指定 dtype 也会全存为 Python object，开销极大。

• 用 dtype 显式声明：数值列优先用 pd.Int64Dtype()（支持 NaN 的整型）或 'category'（重复值多的字符串）
• 加 usecols 只读需要的列，别图省事读全表
• 大文件加 chunksize 流式处理，别一次性 read_csv 后再 head() —— head(n) 仍会触发全量解析

df.groupby().apply() 慢得离谱？先看是不是在重复造轮子

90% 的场景其实不需要 apply：聚合用 agg，广播用 transform，过滤用 filter。只有当逻辑无法拆解成向量化操作时，才考虑 apply，且必须配合 raw=True 和预编译函数。

• df.groupby('x')['y'].mean() 比 df.groupby('x').apply(lambda g: g['y'].mean()) 快 5–10 倍
• 若真要用 apply，避免在函数里调 df.copy()、pd.concat() 或反复索引
• 注意 apply 默认按列传入 Series，想按行处理得加 axis=1，但性能更差，优先改用 np.where 或 pd.Series.map()

merge 之后数据变多或变少？检查 how 和 indicator

不显式写 how 参数，默认是 'inner'，但很多人误以为是 'left'；更隐蔽的问题是 key 列含空值 —— NaN != NaN，所有含 NaN 的行在 merge 中自动被丢弃，且不报错。

• 永远显式写 how='left' / 'inner' / 'outer'，别依赖默认
• merge 前用 df[key].isna().sum() 检查空值，必要时用 df.fillna({'key': 'MISSING'}) 对齐
• 加 indicator=True 生成 _merge 列，一眼看出哪些行只在左/右/两边都存在

df.loc[condition, col] = value 报 SettingWithCopyWarning？不是警告，是危险信号

这个警告意味着你正在修改一个视图（view）或副本（copy）的值，原 df 可能根本没变。根源通常是链式索引：df[df.x > 1]['y'] = 2。

• 只用一次 .loc 或 .iloc 完成定位+赋值：df.loc[df.x > 1, 'y'] = 2
• 确认是否真在操作原始 DataFrame：打印 df._mgr.blocks 或用 df.is_copy（已弃用但仍有用）辅助判断
• 保险起见，构造新列时用 df.assign(y=df.y.mask(condition, value))，函数式无副作用

真正卡住人的从来不是“没学过”，而是不知道 read_csv 默认干了什么、groupby 哪些操作偷偷转了循环、merge 怎么无声吞掉 NaN 行、loc 赋值为何有时生效有时失效——这些细节不亲手试错两三次，光看“第260讲”没用。