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 强制拦截。
