17370845950

read_csv 时用 dtype="string" 可启用 pandas 1.0+ 的原生可空字符串类型，支持 NaN、None 和 Unicode，避免 object 类型的性能与行为缺陷；需注意 dtype 字典键必须匹配列名、不可混用 str、版本需 ≥1.0，并通过 df[col].dtype == "string" 验证。

read_csv 时用 dtype="string" 强制启用 nullable string

从 pandas 1.0 开始，"string" 是官方推荐的可空字符串类型（对应 StringDtype），它能自然容纳 NaN、空字符串、None 和任意 Unicode 字符，且不转成 object。直接在 dtype 参数里指定列名映射即可：

df = pd.read_csv("data.csv", dtype={"col_a": 
"string", "col_b": "string"})

注意："string" 必须是字符串字面量，不是 str 或 pd.StringDtype()（后者虽等价但写法冗余）；若整表都需该类型，可用 dtype="string" 全局设置（但会强制所有列走 nullable string，可能误伤数值列）。

为什么不用 object 类型？

object 列看似能存字符串和 NaN，但它本质是 Python 对象引用数组，计算慢、内存高、API 行为不一致（比如 .str.contains() 在含 NaN 的 object 列上可能报错或返回意外结果）。而 "string" 是 pandas 原生 nullable 类型，支持完整 .str 访问器，且自动处理缺失值语义。

• 遇到混合类型（如某列含数字字符串 + NaN）时，object 会保留原始类型，"string" 会统一转为字符串（"123"、"45.6"、pd.NA）
• object 列调用 .astype("string") 可能触发隐式转换警告；直接 read_csv 指定更干净

常见踩坑：dtype 写错或被 infer_dtype 覆盖

以下情况会导致 "string" 失效：

• dtype={"col": str} —— 这是 Python 的 str，pandas 仍按旧规则推断，最终得到 object
• 同时设了 converters 或 na_values，但没配合 keep_default_na=False，导致某些空值未被识别为 pd.NA
• pandas 版本低于 1.0（"string" 不可用），此时只能降级用 object + 手动 .astype("string")（但部分老版本不支持）
• 列名拼写错误或大小写不匹配，dtype 字典键没生效

验证是否成功：检查 df["col"].dtype 输出应为 string（不是 object），且 df["col"].isna().sum() 能正确统计 pd.NA 数量。

读取后补救：astype("string") 的边界条件

如果已读入为 object，再转 .astype("string") 多数情况下可行，但要注意：

• 含 Python None 或 np.nan 的列，astype("string") 会把它们转为 pd.NA（这是期望行为）
• 含非字符串对象（如 datetime.date、自定义类实例）会抛 TypeError，必须先清洗或过滤
• 大数据集下，两次解析（先 object 再 string）比一次指定 dtype 更耗内存和时间

真正难处理的是那些在 CSV 中被自动识别为数字/布尔/日期的列——它们进来的 dtype 根本不是 object，而是 int64 或 bool，此时 astype("string") 会失败（int 列含 NaN 时甚至无法直接转）。这种列必须回到 read_csv 阶段用 dtype 强制拦截。