Int64是Pandas的可空整数扩展类型，非Python/NumPy原生int，底层用pd.NA表示缺失值，支持整数语义与三值逻辑，需显式声明（如dtype="Int64"）而非astype(int)。
为什么 Int64 不是普通 int，而是一种可空整数类型？
在 Pandas 2.0 之前，整数列只要含 NaN 就被迫转成 float64，导致语义丢失（比如 ID、计数本不该是浮点）。Pandas 2.0 引入的 Int64（以及 Int32、Int16 等）是真正支持缺失值的整数扩展类型，底层用 pd.NA 表示空值，而非 np.nan。
关键区别在于：Int64 是 nullable integer dtype，属于 ExtensionDtype，不是内置 Python 或 NumPy 类型。它允许你在保持整数语义的同时表达“未知”或“不适用”。
-
df["col"].dtype返回Int64，不是int64 -
df["col"].isna()正确识别pd.NA，而np.isnan()会报错 - 算术运算中遇到
pd.NA默认返回pd.NA（可配置），不会变成nan
如何创建和转换为 Int64 类型？
不能直接用 astype(int) —— 那会失败或静默转成 float64。必须显式指定 nullable 整数类型。
- 新建 Series 时用
dtype="Int64"：pd.Series([1, 2, None], dtype="Int64") - 已有含
NaN的列转换：df["id"] = df["id"].astype("Int64")（若含float值，会先尝试转整，失败则报错） - 读取 CSV 时提前声明：
pd.read_csv("data.csv", dtype={"user_id": "Int64"}) - 使用
convert_dtypes()自动推断：df = df.convert_dtypes(dtype_backend="pandas")（Pandas 2.0 默认启用，会把可空整数列转为Int64）
pd.NA 和 np.nan 混用时常见错误
混合使用会导致隐式类型降级或意外行为。例如把 pd.NA 插入原本是 float64 的列，Pandas 可能保留 float64 并用 np.nan 表示缺失，从而丢失整数语义。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 赋值时注意一致性：
df.loc[0, "count"] = pd.NA（前提是列已是Int64；否则会触发类型转换警告或失败） - 避免用
fillna(0)后再转Int64—— 应该先确保无NaN，再用astype("int64")；若需保留空值语义，就别 fill，直接用Int64 -
query()中比较需小心：df.query("age > 18")会自动过滤掉pd.NA行（符合三值逻辑），但df[df["age"] > 18]会因布尔索引含NA报错，得改用df[df["age"].gt(18, fill_value=False)]
性能与兼容性要注意什么？
Int64 比原生 int64 占用更多内存（每个值额外存一个 validity mask），且部分底层操作（如某些 groupby 聚合、Cython 加速路径）尚未完全优化。
- 数值计算快慢取决于操作：加减乘除基本正常，但
agg("sum")在大表上可能比float64慢 10–20% - 与 NumPy 交互受限：
df["col"].to_numpy()默认返回object数组；要转成带np.nan的float64，得加dtype=float参数 - 某些旧库（如旧版 SQLAlchemy、xlwings）可能不识别
Int64，写入数据库或 Excel 前需显式转float64或int64（并处理pd.NA）
真正需要的是语义正确性，而不是盲目追求“整数列看起来像整数”。如果业务逻辑里“缺失”和“零”有本质区别，Int64 就值得用；否则，简单填 0 或 -1 可能更省事。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
