元组的不可变性仅指其直接元素的引用不可增删或替换，但内部可变对象（如列表）的内容仍可修改；例如t[1].append(2)合法，而t[1] = [2]会报错。
因为元组只保证自身结构不可变，不递归冻结嵌套对象的可变性。
元组的“不可变”到底指什么
元组的不可变性仅作用于其直接元素的引用——你不能增删元素，也不能用 a[0] = ... 替换某个位置上的对象。但元组里存的是对象引用，如果那个对象本身是可变的（比如 list），它的内部状态仍可被修改。
-
id(my_tuple)和id(my_tuple[2])是两个独立的地址：元组只锁住索引到对象的映射关系，不锁对象本身 - 执行
my_tuple[2].append(99)改的是列表对象的内容，没动元组的任何 slot - 而
my_tuple[2] = [1, 2]会失败，因为这是在改元组第 2 个 slot 的引用目标
常见错误现象：误以为“能改列表”等于“元组可变”
实际调试中容易混淆两类操作：
- ✅ 合法：
my_tuple = (1, 2, [3, 4]); my_tuple[2][0] = 99→ 元组不变，列表内容变 - ❌ 报错：
my_tuple[2] = [99, 4]→TypeError: 'tuple' object does not support item assignment - ⚠️ 隐患：
my_tuple[2].clear()或my_tuple[2].sort()会静默改变数据，可能破坏业务逻辑预期
性能与兼容性影响：别在关键路径上依赖这种行为
虽然语法允许，但嵌套可变对象会让元组失去“值语义”保障：
立即学习“Python免费学习笔记（深入）”；
- 无法安全用作
dict键或set成员（除非嵌套对象全不可变） - 序列化（如
pickle或 JSON）时可能因深层可变性产生意外结果 - 多线程环境下，即使元组本身线程安全，其内嵌列表仍需额外加锁
- 类型提示（如
tuple[int, int, list[int]]）不阻止运行时修改，静态检查器也无法捕获副作用
真正需要“深层不可变”时，得用 frozen 工具（如 types.MappingProxyType 包裹字典）或手动深拷贝+冻结，而不是依赖元组的浅层保护。
