Python 的 True + True 为什么等于 2？bool 是 int 子类，这个设计坑了多少人

结论先行：在 Python 里 True + True == 2，sum([True, False, True]) == 2，isinstance(True, int) 直接返回 True——因为 bool 根本不是独立类型，它是 int 的子类，True 就是 1，False 就是 0。这个设计是从 C 语言时代继承下来的，用起来极其顺手，也极其容易埋雷：字典键碰撞、JSON 序列化、== 与 is 的混用，三个坑几乎每个项目都踩过。这篇用 9 组实验把这个「设计选择」和它的「代价」一次讲透。

1. 先看一组反常识的实验结果

>>> True + True
2
>>> True * 3
3
>>> isinstance(True, int)
True
>>> bool.__mro__
(<class 'bool'>, <class 'int'>, <class 'object'>)

很多人第一次见到 True + True 的结果是懵的：布尔值不是「真」和「假」吗，怎么能相加？

但在 Python 的对象模型里，True 和 False 不是「状态」，而是两个「数」。它们长这样：

>>> True == 1
True
>>> False == 0
True
>>> int(True), int(False)
(1, 0)

True 就是 1 的马甲，False 就是 0 的马甲。既然如此，True + True 等于 2 还有什么可奇怪的吗？

2. bool 是什么：类型继承链一张表

bool 的类型继承链说明了一切：

bool -> int -> object

注意最后一行：bool 是单例类型。bool(0)、bool(False)、bool([]) 拿到的都是同一个 False 对象：

>>> bool(0) is bool(False) is False
True

这和 int 不一样。int 的小整数（-5 到 256）有缓存，但大整数每次运算都产生新对象；而 bool 从语言设计上就锁死了只有两个实例。

3. 为什么这样设计：C 语言的账

Python 的 bool 是 2001 年才引入的（PEP 285，Python 2.3），在那之前，「真」「假」就是用 1 和 0 表示的——和 C 语言一脉相承。

但 PEP 285 没有把 bool 设计成 int 的「兄弟」类型，而是设计成了子类，理由很务实：

• 兼容性。引入 bool 之前，全世界的代码都在写 return 1 表示成功。如果 bool 和 int 再无关系，flag == 1 这种写法会大面积失效，老代码会崩。
• C 扩展的便利。底层 PyBoolObject 结构体就是在 PyLongObject 基础上封装的，C 代码里可以直接按整数读写。
• 语义。布尔值本质上是「非假即真」的二值，而整数天然覆盖这两个值，复用整数运算不需要新造一套规则。

代价是：True 从此永远背着 1 的数学身份，甩不掉了。

4. 第一个坑：字典和集合里的键碰撞

因为 True == 1 且 hash(True) == hash(1)，在字典里它们是同一个键：

>>> d = {
   }
>>> d[True] = "布尔键"
>>> d[1] = "整数键"
>>> d
{
   True: '整数键'}

你以 True 为键存了值，再用 1 去取，取到的是同一个槽位——第二次赋值直接覆盖了第一次。反过来也一样：

>>> {
   True: "a", 1: "b", 1.0: "c"}
{
   True: 'c'}

连 1.0 都来抢这个键，因为 1.0 == True 且三者哈希值相同。

实际项目里这种坑常出现在计数器和去重集合上：你以为集合里有 True 和 1 两个元素，其实只有一个：

>>> len({
   True, 1, 1.0})
1

5. 第二个坑：JSON 序列化的静默变形

json 模块序列化布尔值时当然输出 true/false，这是符合规范的。但反序列化回来的 1 不会变成 True：

>>> import json
>>> json.dumps({
   "flag": True})
'{"flag": true}'
>>> json.loads('{"flag": 1}')
{
   'flag': 1}
>>> json.loads('{"flag": 1}')["flag"] == True
True   # 相等，但不是同一个东西

麻烦在于相等：前端传 {"flag": 1}，后端 if data["flag"]: 判断照样通过，类型检查却过不了；再传给严格的校验库（如 pydantic 开启严格模式）直接报错。更隐蔽的是 sum 类聚合：

>>> json.loads('[true, false, true]')
[True, False, True]
>>> sum([True, False, True])
2

一个「布尔列表」求和得到 2——这在业务代码里经常是 bug 而不是 feature。

6. 第三个坑：== 和 is 的混用

True == 1 为真，但 True is 1 为假：

>>> True == 1
True
>>> True is 1
False

is 判断的是对象身份。True 是 bool 单例，1 是 int 对象（小整数缓存里的那个），两者不是同一个对象。

这意味着判断「是不是布尔值」不能用 == 1：

>>> (1 == True) is True
True
>>> isinstance(1, bool)   # 正确写法
False
>>> isinstance(True, bool)  # 正确写法
True

反过来，判断「是不是真值」要用 is True 或直接 if，不要写 if x == 1——否则 1、1.0、True、Decimal(1) 全都混进来。这是静态类型检查工具（mypy/pyright）反复强调的规矩。

7. bool 的「假值」远不止 False

因为 bool() 接受任何对象，而每个对象都有「真假值」：

>>> bool(0), bool(""), bool([]), bool(None)
(False, False, False, False)
>>> bool(0.0), bool({
   }), bool(set())
(False, False, False)

注意：bool 的子类身份不影响这个语义。空列表不是 0，但它「假」。判断规则是：对象实现了 __bool__ 就用它，否则用 __len__，两者都没有就为真。这套规则和 bool 继承 int 无关，属于另一套协议——不要混为一谈。

8. 想不用 bool，可能吗

有人想过：要是 bool 不继承 int 会怎样？

答案是生态会崩一半。C 扩展、NumPy、数据库驱动、protobuf 生成的代码里，True 到处被当 1 用：

>>> import numpy as np
>>> np.array([True, False, True]).sum()
2
>>> np.array([True, False, True]).dtype
dtype('bool')

NumPy 里 bool 数组是独立 dtype，但 sum() 出来的还是 2——因为整个数值生态都建立在「布尔即整数」之上。想改，得先问过二十年的存量代码。

9. 一张速查表收尾

一句话总结：bool 继承 int 是 Python 为兼容 C 时代存量代码做的务实妥协，True 就是 1、False 就是 0 是特性不是 bug；但在写字典键、JSON 边界和类型判断时，必须记住这个「马甲设定」，该用 isinstance 就别用 ==，该用 is True 就别用 == 1。