Python元组不可变的根本原因在于其底层CPython实现中PyTupleObject结构体采用定长指针数组，内存一次性分配且无扩容或修改接口。
Python 元组不可变，根本原因不在“设计哲学”或“语义约定”，而在于其底层内存结构和对象模型的硬性约束——元组对象一旦创建，其内部存储的元素指针数组就不再允许修改。
内存布局决定不可变性
CPython 中，tuple 对象本质上是一个定长的指针数组（PyTupleObject 结构体），包含 ob_refcnt（引用计数）、ob_type（类型指针）和一个固定大小的 *ob_item 数组。这个数组在对象创建时一次性分配，长度写死在 ob_size 字段里，且没有提供任何接口去调整它。
- 调用
tuple([1, 2, 3])或(1, 2, 3)时，解释器计算出元素个数，malloc 一块刚好容纳 3 个 PyObject* 的连续内存； - 后续所有操作（如索引、迭代）都只读取该数组，不涉及扩容、移动或重分配；
- 没有
append、__setitem__等方法的 C 实现，对应 Python 层抛出TypeError是因为底层函数直接返回错误码，而非逻辑拦截。
与列表的关键差异：无动态管理机制
对比 list，其底层是带冗余空间的可变数组（over-allocated buffer），支持 append/pop 等操作需动态 realloc 内存并更新指针。而 tuple 的结构体中根本没有 capacity 字段、没有 resize 函数指针、也没有缓冲区管理逻辑。
- list 的
ob_item指向的内存块大小 ≥ 实际元素数，留有余量； - tuple 的
ob_item大小 == 实际元素数，紧致无冗余； - 尝试执行
t[0] = 10会触发 C 函数tup_setitem，该函数在源码中直接Py_RETURN_NOTIMPLEMENTED，即明确拒绝赋值语义。
不可变性带来的实际保障
这种硬编码的只读特性，使元组天然满足哈希要求和线程安全前提：
立即学习“Python免费学习笔记（深入）”；
- 哈希值可在创建时一次性计算并缓存（
hash(tuple)快且稳定），因为内容永不改变； - 作为字典键或集合元素时，无需担心运行时被意外修改导致哈希失配；
- 多线程环境下，多个线程读取同一元组无需加锁——没有写入口，不存在竞态条件。
“伪可变”技巧不改变底层事实
有人通过 id() 观察到“修改元组后地址不变”，其实是误解。例如：
t = (1, [2, 3]) t[1].append(4) # ✅ 合法：修改的是列表对象，不是元组内容
这里元组存储的仍是原来那个列表对象的指针，指针没变，所以元组本身仍不可变。真正被修改的是列表对象内部状态——这恰恰印证了元组只保证自身结构不可变，不递归保护所引用对象。
