NumPy 2.0 彻底移除 np.NAN，仅保留符合 PEP 8 的 np.nan；三类常见修复：直接替换、dtype 中禁用、pandas 及配置字典同步更新。
np.NAN 在 NumPy 2.0 中已被彻底移除
不是拼写错误、不是导入问题、也不是环境混乱——np.NAN 这个属性从 NumPy 2.0 开始被正式删除，调用它会直接触发 AttributeError: module 'numpy' has no attribute 'NAN'。官方明确将其列为「已弃用且不再恢复」的符号，仅保留 np.nan（全小写）作为唯一合法的 NaN 对象。
为什么只留 np.nan，不要 np.NAN？
NumPy 长期以来存在大小写混用的历史包袱：np.NaN（首字母大写）、np.NAN（全大写）、np.nan（全小写）曾并存多年，但语义完全一致，纯属冗余。NumPy 2.0 借版本大更新统一规范，只保留 PEP 8 推荐的小写命名风格。
-
np.nan是 float 类型的单例对象，内存地址固定，np.nan is np.nan为True -
np.NAN和np.NaN在 1.x 版本中只是对np.nan的别名（alias），无独立实现 - 升级后所有文档、示例、类型提示（如
np.floating）均只认np.nan
升级后代码报错，怎么快速修复？
搜索替换即可，但要注意三类常见残留场景：
- 直接使用：
np.NAN→ 改成np.nan - 在 dtype 定义中误写：
dtype=np.NAN是非法的，应改为具体类型如np.float64；NaN 不是 dtype - 与 pandas 混用时：
pd.Series([1, 2, np.NAN])→ 改为pd.Series([1, 2, np.nan])，pandas 会正确识别 - 旧版配置字典里硬编码：
{"fill_value": np.NAN}→ 必须同步改为np.nan，否则运行时报错
容易被忽略的兼容性陷阱
有些代码看似没直接写 np.NAN，却因间接依赖失效：
立即学习“Python免费学习笔记（深入）”；
- 第三方库未适配 NumPy 2.0（比如老版本
scikit-learn 或某些私有工具包），内部仍调用 <code>np.NAN，需升级对应库 - 使用
eval()或字符串 exec 动态构造 NumPy 表达式，若字符串含"np.NAN"，运行时才暴露问题 - IDE 自动补全可能仍显示
np.NAN（缓存未刷新），但实际运行必报错，不能信补全
真正要检查的不是“有没有写错”，而是“哪些地方隐式依赖了已被删掉的符号”。
