元组不可变是因底层内存结构固定，不支持修改操作；其不可变性仅限顶层，内部可变对象仍可修改；用作字典键时要求所有元素均可哈希。
为什么修改元组元素会报 TypeError: 'tuple' object does not support item assignment
因为元组在 Python 中是不可变（immutable）对象，它的底层结构在创建后就固定了——不是“禁止写操作”的逻辑限制，而是内存里那块连续空间压根没预留修改入口。你试图执行 t[0] = 1，解释器直接拒绝，连尝试拷贝或重分配都不会做。
常见错误现象：把元组当列表用，比如想动态追加元素、交换位置、清空内容；或者误以为 += 对元组是原地操作（其实它会触发隐式重建，等价于 t = t + (x,)）。
- 真正需要“不变性”时才用元组：函数返回多个值（
a, b = func()实际拆包的是元组）、字典键（d[(1, 'a')] = True）、配置项常量（STATUS_CODES = (200, 404, 500)） - 别为了“看起来轻量”硬套元组：如果后续要增删改，一开始就用列表，否则每次修改都要新建元组，反而更耗内存和 CPU
- 嵌套元组的“不可变”只作用于顶层：
t = ([1, 2], 3)中，你能改t[0].append(4)，因为列表对象本身可变——元组管不住它内部的引用目标
元组比列表省内存？看 sys.getsizeof() 和实际场景
是的，但差距有限，且只在纯数据、无引用的情况下明显。元组没有列表那种预留扩容空间的冗余字段（如 ob_size 和用于 append 的额外槽位），所以同长度纯数值元组通常小 8–16 字节。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
sys.getsizeof()测真实开销：sys.getsizeof((1,2,3))vssys.getsizeof([1,2,3])，别凭感觉猜 - 一旦元组里包含可变对象（比如列表、字典、自定义类实例），内存优势基本归零——因为主要空间花在那些对象身上，元组头只存指针
- 高频创建/销毁小元组（如循环中
for x in data: key = (x.id, x.tag)）确实比列表略快，但若之后还要解包或遍历，差异微乎其微，别为此牺牲可读性
什么时候该用 tuple() 而不是括号字面量？
tuple() 是构造函数，只在需要从其他可迭代对象动态生成元组时才有意义；括号 () 是语法糖，仅用于字面量或解包上下文。
容易踩的坑：
-
tuple('abc')返回('a', 'b', 'c')，不是('abc',)；单元素元组必须写逗号：('abc',)，否则只是带括号的字符串 -
tuple([1,2,3])会复制一份，不共享底层数据；而(1,2,3)是编译期确定的常量，在相同模块里多次出现可能被 CPython 缓存复用（但别依赖这点） - 函数参数传元组？别写
func(tuple(x for x in data))，除非真需要切断与原可迭代对象的关联（比如防止它被中途修改）；多数情况直接传生成器或列表更自然
用元组作字典键出错：TypeError: unhashable type: 'list'
字典键要求对象可哈希（hashable），即生命周期内 __hash__() 输出不变，且满足 a == b → hash(a) == hash(b)。元组本身可哈希，但前提是它所有元素都可哈希。
典型翻车现场：
-
{([1], 2): 'bad'}报错，因为列表不可哈希；换成((1,), 2)就行 - 自定义类实例放进元组当键前，必须实现
__hash__且保证它不随实例状态变化（比如只基于初始化时的 immutable 字段） - 浮点数做元组元素当键要小心：
(0.1 + 0.2,)和(0.3,)可能不等（精度误差），导致查不到预期键值
不可变性不是银弹，它只保证容器结构不动，不保证里面每个对象都“安全”。真要当键用，逐层检查元素类型比事后调试省事得多。
