元组的不可变性是其类型底层实现决定的，仅指引用序列不可变，不约束所引用对象的状态，从而支持字典键、安全默认参数等场景。
不可变性不是语法糖，是对象模型的底层设计
元组的不可变性不是Python加的一层“限制开关”，而是由其类型实现决定的：tuple 类在C源码中不提供任何修改内部结构的方法（比如没有 append、__setitem__ 的可写实现），而 list 显式实现了这些方法。当你写 t[0] = 1，解释器会调用 t.__setitem__(0, 1) —— 元组类直接抛出 TypeError，列表类则执行内存重分配或原地覆盖。
为什么允许元组里放列表？这不矛盾吗
不矛盾。元组的“不可变”仅指它所持有的**引用序列**不可变，即不能增删元素、不能替换某个索引处的对象引用。但它完全不干涉被引用对象自身的状态：
-
t = ([1], {"x": 2})合法：元组存了两个可变对象的引用 -
t[0].append(3)合法：修改的是列表对象本身，元组内第0个引用仍指向同一个列表 -
t[0] = [4]报错：TypeError: 'tuple' object does not support item assignment：这是要改元组自己的引用表
不可变性带来的实际约束和收益
这种设计不是为了“难为开发者”，而是服务于具体场景的确定性需求：
- 字典键必须可哈希，而哈希值依赖对象内容稳定 →
{(1, 2): "ok"}合法，{[1, 2]: "bad"}直接报TypeError: unhashable type: 'list' - 函数默认参数若用
[]，多次调用会共享同一列表 → 改用()可避免“可变默认参数陷阱” - 多值返回如
a, b = func()本质是解包元组，依赖其长度和位置稳定；若返回的是列表，调用方无法静态保证结构不变 - CPython中元组对象头更小、无扩容冗余字段，创建和遍历确实比等长列表快约5–10%
别被“看起来能改”骗了：+= 和 * 操作的本质
像 t += (4,) 或 t = t + (4,) 看似“修改”，实则是创建新元组并重新绑定变量名：
立即学习“Python免费学习笔记（深入）”；
-
id(t)在操作前后几乎总是不同 -
t *= 2对元组也合法，但仍是新建对象：t = (1, 2); t *= 2后t是新元组(1, 2, 1, 2)，原对象未被改动 - 对比列表：
l += [4]是就地扩展，id(l)不变
真正容易忽略的是：这种“重新赋值”行为会让你以为元组“被改了”，但只要涉及变量名重绑定，就和元组本身的不可变性无关——它只是你换了个新对象来指代。
