Pandas 2.0 默认启用 string[pyarrow] 和 Int64 等 nullable 类型，底层切换至 Arrow 引擎，提升内存效率、原生支持 pd.NA，并增强与 Arrow/Parquet 生态互通性，但需注意 dtype 兼容性及下游系统适配。
因为 Pandas 2.0 默认启用 string[pyarrow] 和 Int64 等 nullable 类型，底层切换到了 Arrow 引擎，而不是沿用 1.x 的 object 或 int64。
读 CSV 时字符串列变成 string[pyarrow] 了
这是 Pandas 2.0 的默认行为：当 PyArrow 可用时，pd.read_csv() 不再把文本列推断为 object dtype，而是优先用 string[pyarrow]。它更省内存、支持原生 NA（不是 np.nan），且与 Parquet/Arrow 生态零拷贝互通。
- 如果你依赖
df[col].str.contains(...)但报AttributeError: Can only use .str accessor with string values，大概率是列 dtype 是object混合了非字符串值——而string[pyarrow]会严格校验，提前暴露问题 - 想退回 1.x 风格？设
pd.options.mode.dtype_backend = 'numpy_nullable'，之后字符串列会变成string（Pandas 自研 nullable string），整数列变成Int64 - 注意：
string[pyarrow]在某些旧版openpyxl或xlsxwriter写 Excel 时可能报错，需显式.astype(str)或换 engine
merge 或 concat 后整数列变 float64 的现象少了，但类型名变复杂了
1.x 中只要一列有缺失，整数列就退化成 float64；2.x 改用 nullable 类型后，同样场景下会是 Int64（大写 I）或 string[pyarrow]，语义更准确。
- 检查 dtype 时别只看
"int"——df.col.dtype返回Int64表示 nullable int，不是传统int64；它支持pd.NA，但不支持.sum()直接返回 int（默认返回 float） - 导出到数据库或老系统前，仍需手动处理：比如
df.col.fillna(-1).astype("int64")，否则 ORM 可能拒收Int64 -
pd.concat([df1, df2], ignore_index=True)若任一 df 含 nullable 列，结果列 dtype 会自动对齐为 nullable 版本，不是降级为object
Arrow 后端让 dtype 推断更“激进”，但也更一致
Arrow 对类型更敏感：比如 CSV 中一列全是 "1", "2", ""，1.x 推断为 object；2.x（Arrow 后端）会直接推断为 string[pyarrow]，哪怕空字符串存在。
立即学习“Python免费学习笔记（深入）”；
- 这种“激进”减少了隐式类型转换带来的歧义，但也会暴露原有数据中混杂类型的问题（例如某列本该是数字，却夹了几个 "N/A" 字符串）
- 若你用
dtype参数强制指定{"col": "int64"}，Pandas 2.0 仍会尝试转成Int64（nullable），除非你加pd.options.mode.dtype_backend = 'numpy' - 性能上，
string[pyarrow]的.str.len()比object快 3–5 倍，但.str.split().str[0]在某些模式下可能略慢，取决于 Arrow 版本
真正容易被忽略的点是：dtype 变化不是孤立的，它和 pd.NA、Arrow 文件读写、甚至 to_sql() 的类型映射都绑在一起。改一行 pd.options.mode.dtype_backend 可能解决报错，但也可能让下游 Parquet 读取变慢——得看你的数据链路里哪一环真正依赖 Arrow。
