搞数据处理或者写后端接口的朋友，大概率都经历过这种“鬼打墙”的时刻：
数据库里明明是NULL，读到 Python 里变成了None，扔进 Pandas 做个计算变成了NaN，最后想转成 JSON 返回给前端时，因为包含NaN直接报错，或者变成了一个前端 JS 无法识别的NaN符号。
最近读了 Filip Mularczyk 的一篇名为《Nothing to Declare》的文章，很有共鸣。特别是在 Pandas 3.0 普及的当下，我们处理“没有值”这种状态时，依然容易掉坑里。
今天就来聊聊这三个长得像、但脾气完全不同的“空值”：NaN、None和null，以及如何在工程中优雅地处理它们。
三个“空”，三种命
首先得祛魅，这三位在 Python 的内存里完全是三个物种：
None (Python 的亲儿子)
- 它是 Python 的内置对象，属于
NoneType。 - 它代表**“逻辑上的无”**。比如“用户没有填昵称”，这就是
None。 - 它是一个单例（Singleton），用来做判断时，永远要用
is None而不是== None。
- 它是 Python 的内置对象，属于
NaN (数学界的怪胎)
- 全称 Not a Number，但它在 Python 里居然是
float类型！ - 它代表**“数值上的缺失或计算错误”**。比如
0/0或者读取了一个空的 CSV 数值格。 - 它最反直觉的地方在于“六亲不认”：
NaN != NaN是成立的。这意味着你没法用==去在列表里找它，必须用math.isnan()或pd.isna()。
- 全称 Not a Number，但它在 Python 里居然是
null (外来的和尚)
- Python 语法里没有
null。 - 它通常存在于JSON或SQL中。
- 当我们谈论
null时，通常是在讨论数据交换（IO）。当一个 JSON 的null传进来，Python 的json库默认把它转成None。
- Python 语法里没有
工程实践中的“灾难现场”
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 的时间。
