真正需要的是掌握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 中自动被丢弃，且不报错。
立即学习“Python免费学习笔记（深入）”；
- 永远显式写
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讲”没用。
