Python 的列表和元组到底差在哪？拆开 PyListObject 和 PyTupleObject，为什么一个能改一个不能

结论先行 ：list 和 tuple 的差别不只是"能不能改"这么简单。实测 CPython 3.13.14：tuple 字面量创建比 list 快 6.7 倍 （0.012s vs 0.078s，各 100 万次）、迭代快约 16% 、索引快约 18% 、空容器省 16 字节。代价只有一个：创建后不能改。本文用实机数据拆开两者的底层结构，告诉你什么时候该用哪个。

1. 先看内存：同样装 1000 个元素，差了多少

python 复制代码

import sys
for n in [0, 3, 10, 1000]:
    l = list(range(n)); t = tuple(range(n))
    print(n, sys.getsizeof(l), sys.getsizeof(t))

实测输出（CPython 3.13.14，64 位）：

元素数	list	tuple	差值
0	56 B	40 B	16 B
3	88 B	64 B	24 B
10	136 B	120 B	16 B
1000	8056 B	8040 B	16 B

为什么 list 永远更胖？ 拆开 C 源码看结构：PyTupleObject 只需要存一个定长的指针数组；而 PyListObject 除了指针数组，还多带一个 allocated 字段------它要记录"预分配了多少空间"，为后面的 append 扩容做准备。这个字段就是 8 字节，加上对象头差异，list 天生比 tuple 重。

2. 创建速度：tuple 字面量快 6.7 倍，但有个反转

python 复制代码

import timeit
print(timeit.timeit("[1,2,3,4,5]", number=1000000))   # 0.078s
print(timeit.timeit("(1,2,3,4,5)", number=1000000))   # 0.012s

100 万次字面量创建：list 0.078s，tuple 0.012s，tuple 快 6.7 倍。

原因藏在编译期：只含常量的 tuple 字面量会被 CPython 做常量折叠 ------编译时就算好存进常量表，运行时直接从常量表里取引用，几乎零成本；而 list 字面量每次都要真刀真枪地调 BUILD_LIST 重建一个新对象。可变的东西没法折叠，这是"可变"的第一笔税。

但别急着下结论，换个写法就反转了：

python 复制代码

print(timeit.timeit("list(range(1000))", number=1000))   # 19.4ms
print(timeit.timeit("tuple(range(1000))", number=1000))  # 21.0ms

从迭代器构造时，list 反而略快 （19.4ms vs 21.0ms）。因为 tuple(...) 对任意可迭代对象要先走一遍通用迭代协议，而 list(...) 有专门的快速路径。所以"tuple 一定快"这个说法，只在字面量场景成立。

3. 读操作：tuple 全面小胜

python 复制代码

l = list(range(10000)); t = tuple(range(10000))
print(timeit.timeit("for x in l: pass", globals={'l': l}, number=1000))  # 103.8ms
print(timeit.timeit("for x in t: pass", globals={'t': t}, number=1000))  #  89.4ms
print(timeit.timeit("l[500]", globals={'l': l}, number=1000000))  # 0.0359s
print(timeit.timeit("t[500]", globals={'t': t}, number=1000000))  # 0.0295s

迭代 10000 元素 × 1000 次：tuple 快 16%；索引取值：tuple 快约 18%。

两者底层都是指针数组 + 随机访问，为什么 tuple 还快？因为 tuple 是定长不可变对象，解释器对它少了边界和容量检查的分支，GC 跟踪也更轻。差距不大，但在热循环里是白捡的。

4. 写操作：append 68 纳秒 vs 拼接 430 纳秒

python 复制代码

l = [0]*100
print(timeit.timeit("l.append(1)", globals={'l': l}, number=1000000))  # 0.068s → 68ns/次
t = tuple(range(100))
print(timeit.timeit("t + (1,)", globals={'t': t}, number=10000))       # 430ns/次

这就是"不可变"的真正代价：tuple 没有 append，想"加"一个元素只能 t + (1,) 重建一个全新对象，把旧元素整个拷贝一遍。n 元素的 tuple 拼一次是 O(n)；而 list 的 append 靠超额分配，摊还下来是 O(1)，实测 68 纳秒一次。

更关键的是 allocated 字段的扩容策略：list 的空间不是用一个分一个，而是按约 1.125 倍超额分配，所以连续 append 1000 次，真正重新分配内存的次数只有十几次。这就是为什么循环里往 list 追加很快，往 tuple"追加"是灾难。

5. 一个常被忽略的功能差异：能不能当字典的 key

python 复制代码

d = {(1, 2): "ok"}   # 正常
d = {[1, 2]: "ok"}   # TypeError: unhashable type: 'list'

tuple 在元素全部可哈希时自己也可哈希，能当 dict 的 key、能进 set；list 不能。做坐标点、复合键、缓存键的时候，tuple 是唯一选择。 另外函数默认参数、*args 收进来的东西，CPython 一律给的是 tuple------因为解释器要保证你拿到的这份东西不会被别处悄悄改掉。

6. 选型清单（收藏这张表）

场景	用哪个	原因
常量序列 / 字面量	tuple	常量折叠，创建快 6.7 倍
需要增删改	list	append 68ns vs tuple 重建 O(n)
当 dict key / 进 set	tuple	可哈希
热路径只读遍历	tuple	迭代/索引快 16~18%
函数返回值（多值）	tuple	不可变，调用方改不坏
从迭代器大批量构造	list	专门快速路径，略快

小结：tuple 的"快"来自不可变------常量折叠省创建、定长省检查、省 16 字节头部；list 的"灵活"也贵在有预分配字段和扩容策略。一句话：数据是"定死的一坨"就用 tuple，是"会长大的容器"就用 list，选反了不会报错，但会白白交性能税。

你在项目里因为把 list 当 tuple（或反过来）踩过坑吗？评论区聊聊。

实测环境：CPython 3.13.14（64 位 Windows），timeit 默认计时，各场景取文中标注的次数。数值随机器有波动，但相对关系稳定。