别再让 NaN 和 None 把你搞晕了：谈谈 Python 里的“空值”哲学

搞数据处理或者写后端接口的朋友，大概率都经历过这种“鬼打墙”的时刻：

数据库里明明是NULL，读到 Python 里变成了None，扔进 Pandas 做个计算变成了NaN，最后想转成 JSON 返回给前端时，因为包含NaN直接报错，或者变成了一个前端 JS 无法识别的NaN符号。

最近读了 Filip Mularczyk 的一篇名为《Nothing to Declare》的文章，很有共鸣。特别是在 Pandas 3.0 普及的当下，我们处理“没有值”这种状态时，依然容易掉坑里。

今天就来聊聊这三个长得像、但脾气完全不同的“空值”：NaN、None和null，以及如何在工程中优雅地处理它们。

三个“空”，三种命

首先得祛魅，这三位在 Python 的内存里完全是三个物种：

1. None (Python 的亲儿子)

   • 它是 Python 的内置对象，属于NoneType。
   • 它代表**“逻辑上的无”**。比如“用户没有填昵称”，这就是None。
   • 它是一个单例（Singleton），用来做判断时，永远要用is None而不是== None。

2. NaN (数学界的怪胎)

   • 全称 Not a Number，但它在 Python 里居然是float类型！
   • 它代表**“数值上的缺失或计算错误”**。比如0/0或者读取了一个空的 CSV 数值格。
   • 它最反直觉的地方在于“六亲不认”：NaN != NaN是成立的。这意味着你没法用==去在列表里找它，必须用math.isnan()或pd.isna()。

3. null (外来的和尚)

   • Python 语法里没有null。
   • 它通常存在于JSON或SQL中。
   • 当我们谈论null时，通常是在讨论数据交换（IO）。当一个 JSON 的null传进来，Python 的json库默认把它转成None。

工程实践中的“灾难现场”

Filip 在文章里提到了一个非常典型的场景：使用 Pydantic 做数据校验。

假设前端给你发来这样一个 JSON：

{"temperature":null,"humidity":"NaN"}

如果你在 Pydantic 模型里定义字段为float，事情就变得微妙了。

• 对于null：Pydantic 默认可能抛错，除非你声明类型为float | None(或者Optional[float])。
• 对于"NaN"：Pydantic 会很“贴心”地把它转成 Python 的float('nan')。

问题来了：当你把这个清洗后的模型存入数据库，或者做数学运算时，混入的None和NaN会导致完全不同的结果。None可能会让数学运算抛出 TypeError，而NaN会像病毒一样，让所有跟它运算的结果都变成NaN。

怎么处理才优雅？

结合文章观点和现在的工程习惯，我有几个建议：

1. 语义分离：是“没填”还是“算错了”？

在定义数据模型（Model）时，要明确区分这两种状态。

• 如果是因为用户没填，或者数据暂缺，尽量保持为None。
• 如果是传感器读数错误、计算溢出，保留NaN是合理的，因为它保留了“这是一个数值类型”的特征。

2. 利用 Pydantic 的 Validator

不要指望自动转换能完全符合心意。在 Pydantic 中，最好写个field_validator（v2 写法）：

# 伪代码示例：确保导出时行为可控@field_validator('score')@classmethoddefhandle_empty_score(cls,v):ifvisNone:returnfloat('nan')# 如果业务要求必须是数值计算returnv

或者反过来，在序列化成 JSON 之前，把所有的NaN清洗回None，因为标准的 JSON 规范其实并不支持NaN（虽然有些解析器能容忍），传null给前端通常是最安全的做法。

3. Pandas 3.0 的新常态

现在是 2026 年，Pandas 3.0 已经让Nullable类型（如Float64、Int64，注意是大写首字母）成为了主流。

以前最让人头大的问题是：一个整数列里混进一个NaN，整列会被强制强转成浮点数。现在，推荐使用 PyArrow 后端或者 Pandas 的 Nullable 类型。这允许None（在 Pandas 里表现为<NA>）和整数和平共处，而不需要动不动就退化成浮点型的NaN。

总结

并没有一种万能的“空值”能解决所有问题。

• 做数学计算：请用NaN，并小心它的传染性。
• 做逻辑流转：请用None。
• 做接口交互：认准null，并确保在 Python 边界处（比如 Pydantic 层）把NaN和None的转换规则定死，别让它们“自由发挥”。

写代码时多想一步：“这个空，到底是因为不存在，还是因为算不出来？”这一秒的思考，能帮你省下好几个小时 debug 的时间。