元组本身不可变，但其内部的列表等可变对象仍可修改；这是因为元组只存储引用，不复制对象，修改列表内容不会改变元组中引用的id。
元组本身不能修改，但里面的列表可以
Python 元组是不可变（immutable）的，意思是它的元素个数、顺序、引用地址都不能变。但「不可变」只作用于元组容器本身，不递归检查内部对象。如果元组里存了一个 list，那个 list 仍是可变对象，它的内容可以被修改。
常见错误现象：TypeError: 'tuple' object does not support item assignment —— 这个报错只在你直接对元组索引赋值时出现，比如 t[0] = 1；但 t[0].append(2) 不会报错，只要 t[0] 是个列表。
- 使用场景：用元组做字典键（如
{(1, [2, 3]): "bad"}会报错，因为含列表的元组不可哈希；但{(1, "a"): "ok"}没问题） - 参数差异：函数接收元组参数时，调用方传的是
([1], 2)还是(1, 2)，会影响被调函数是否能“悄悄改掉”外面的列表 - 性能影响：元组比列表省内存、创建快，但若里面嵌了大列表，不可变性带来的安全假象反而更危险
为什么 id(t[0]) 没变，但 t[0] 的内容变了
因为元组存储的是对象引用，不是对象副本。修改 t[0].append(x) 改的是引用指向的那个列表对象，元组里存的还是同一个 id，所以元组自身没变——它只是“忠实地守着那个地址”。
容易踩的坑：t = ([1], 2); s = t; t[0].append(99); print(s) 输出 ([1, 99], 2)，你以为 s 是副本，其实它和 t 是同一元组，连带里面的列表也被共享了。
立即学习“Python免费学习笔记（深入）”；
- 调试技巧：用
id(t[0])和id(t[0][:])对比，能看出是否新建了列表 - 兼容性注意：这种行为在所有 Python 版本中一致，不是 bug，是设计使然
- 别依赖
is判断元组内容是否“真没变”，得用==+ 深度检查（如果真需要）
想真正冻结嵌套结构？得手动处理
Python 没有内置的“深度不可变元组”。如果你需要确保元组及其内部所有可变对象都不被修改，只能自己控制或封装。
实操建议：
- 初始化时用
tuple(map(tuple, original_list_of_lists))把内层列表转成元组（前提是它们不含更深的可变对象） - 用
types.MappingProxyType包装字典，用collections.namedtuple或typing.NamedTuple替代普通元组（字段名更清晰，且默认不可赋值） - 避免在元组里直接塞
list、dict、set—— 如果业务逻辑上它们不该被改，就别给这个机会
+= 对元组里列表的“静默修改”很隐蔽
t[0] += [3, 4] 看似像“给元组元素重新赋值”，实际等价于 t[0].extend([3, 4])，不会触发元组不可变报错，但会改原列表。这是最容易忽略的坑。
对比：t[0] = t[0] + [3, 4] 才会报 TypeError，因为这是真正的赋值操作；而 += 调用的是列表的 __iadd__，就地修改。
- 排查方法：遇到元组内容“意外变化”，优先搜代码里的
+=、.append、.extend、.pop - 静态检查工具（如
pylint）对这类问题基本无感，得靠人盯 - 测试时别只测元组长度或类型，要 assert 内部对象状态，比如
assert t[0] == [1, 2]
最麻烦的不是元组能不能改，而是它“看起来不能改，实际上部分能改”，而且这种能力藏在语法糖和引用机制底下，不翻源码、不打日志很难意识到。
