因为numpy要求同构数组，长度不一的列表无法用ndarray表示，pandas只能退化为object dtype存储；这导致无法直接使用向量化方法，需用explode、json_normalize等方法展开或归一化处理。
为什么 pd.DataFrame 会把列表自动转成 object 类型？
因为 Pandas 的核心数据结构（Series 和 DataFrame）底层依赖 NumPy，而 NumPy 要求同构数组——所有元素必须是相同类型、相同长度。一旦某列包含长度不一的列表（比如 [1, 2] 和 [3, 4, 5, 6]），NumPy 就无法用 ndarray 表示，Pandas 只能退化为 object dtype 存储 Python 原生对象。
这不是 bug，是设计约束。但这也意味着你不能直接对这列调用 .mean() 或 .str.contains() 这类向量化方法。
- 检查 dtype：用
df['col'].dtype确认是否为object - 验证内容：用
df['col'].apply(type).unique()看是否真存的是list - 避免误判：字符串形式的列表（如
"[1, 2, 3]"）也会是object，但本质是str，需先用ast.literal_eval转换
如何安全展开嵌套列表列成多列或新行？
用 pd.json_normalize() 或 .explode()，取决于你要“横向展开”还是“纵向展开”。
- 想把每个列表元素变成独立行：用
df.explode('col_name')—— 它会复制其他列，只把列表逐个拆开，保留原始索引关系 - 想把列表转成多个并列字段（如
col_0,col_1）：先用pd.DataFrame(df['col'].tolist())构造新表，再pd.concat([df.drop('col', axis=1), new_df], axis=1) - 如果列表内是字典（如
[{'a':1}, {'a':2}]），优先用pd.json_normalize(df['col'])，它能自动处理嵌套键 - 注意空列表：
.explode()默认会丢弃空列表行；加参数ignore_index=False并配合dropna=False可保留 NaN 占位
apply() 处理数组列时哪些写法最稳？
别写 df['col'].apply(lambda x: x[0] if x else None) 这种裸索引——遇到 None、字符串、非列表对象就报 TypeError: 'NoneType' object is not subscriptable。
- 统一预处理：先用
df['col'] = df['col'].apply(lambda x: x if isinstance(x, list) else [])归一化 - 取首元素更安全：用
df['col'].str[0]——.str访问器对非字符串/非列表返回NaN，不崩溃 - 聚合计算：用
df['col'].apply(np.mean)比df['col'].apply(lambda x: sum(x)/len(x))更鲁棒，因为np.mean([])返回nan，而后者会除零 - 避免链式
.apply().apply()：每层都触发 Python 循环，大数据量下比向量化慢 10 倍以上
性能陷阱：什么时候该放弃 Pandas 改用纯 Python 或 Polars？
当你的操作频繁涉及“对每行列表做复杂逻辑（如条件过滤 + 合并 + 映射）”，Pandas 的 apply 会成为瓶颈，且难以调试。
- 中等数据量（.explode() +
groupby().agg()组合，清晰且够快 - 大数据量（>100 万行）或嵌套三层以上：考虑
polars—— 它原生支持 List / Struct 类型，pl.col('col').list.first()是真正向量化的 - 逻辑极复杂（如递归解析 JSON）：用
[process_row(row) for row in df.to_dict('records')]转成字典列表，用纯 Python 写清楚逻辑，再一次性构造新DataFrame - 别低估
pd.Series.map()：如果映射关系固定（如列表 → 分类标签），用map比apply快 3–5 倍，因为它内部做了缓存
嵌套结构本身不难处理，难的是混合了缺失值、类型混杂、动态长度和业务逻辑——这时候与其硬套 Pandas API，不如先用几行代码把数据“拍平”成规整表格，再进入分析流程。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
