元组嵌套可变对象（如列表）会导致哈希失败，因元组可哈希性要求所有嵌套元素均不可变；单元素元组必须写为(1,)而非(1)；修改内层列表会破坏哈希一致性，引发字典查找失效。
元组里嵌了列表就报 TypeError: unhashable type
看似合法的 (1, [2, 3]) 一塞进字典就会炸，错误信息是 TypeError: unhashable type: 'list'。这不是运行时检查内容，而是 Python 在调用 hash() 时直接拒绝——因为元组的可哈希性要求**所有嵌套元素都可哈希**。
-
(1, 2)✅ 安全：两个int都不可变 -
(1, [2])❌ 报错：列表本身不可哈希，哪怕只嵌一层 -
(1, (2, [3]))❌ 同样报错：嵌套再深也没用，只要底层有可变对象 - 修复方式很简单：
(1, tuple([2]))或(1, (2,))，把内层可变结构转成不可变等价物
单元素元组写成 (1) 就不是元组
(1) 是整数，不是元组；hash((1)) 实际算的是 hash(1)，类型上完全绕开了元组语义。这会导致键行为诡异：比如你本想用元组当复合键，结果却意外复用了数字键，可能覆盖其他值或查不到数据。
- 正确写法只有
(1,)—— 逗号才是元组的语法标志，括号只是辅助 - 从用户输入动态构造时尤其危险：
tuple(user_input.split())若输入是"x"，得到('x',)没问题；但若输入是空格分隔的"a b"，得到('a', 'b')，结构变了却不易察觉 - 调试时可用
type(x) is tuple显式校验，别只看打印出来的括号
元组没改，但里面列表被 append 了，字典就失效
这是最隐蔽的坑：t = (1, [2]) 可以成功当键存进字典；但后续执行 t[1].append(3) 后，t 还是那个元组对象，id(t) 不变，可它对应的哈希值在构造时已固定，而内部列表内容已变——字典查找会失准，甚至永远找不到该键。
- 这种修改不抛异常，也不警告，只在逻辑层面悄悄破坏哈希一致性
- 多线程环境下更危险：一个线程在读字典，另一个线程在改元组里的列表，可能引发缓存错乱或 KeyError
- 真正安全的做法是确保元组“扁平+全不可变”，或改用
frozenset（适合无序唯一集合）或自定义冻结类
用 str() 或 json.dumps() 绕过限制反而更糟
有人试过把列表转成字符串当键：{str([1, 2]): "val"}，虽能跑通，但代价巨大。
立即学习“Python免费学习笔记（深入）”；
- 语义丢失：
str([1, 2]) == "[1, 2]"和str((1, 2)) == "(1, 2)"冲突，不同结构可能撞出相同字符串 - 无法反推原始类型：拿到键字符串后，你得猜它是列表还是元组还是别的，还得额外解析
- 性能差：每次访问都要调用
str()或json.dumps()，比原生hash()慢一个数量级以上 - 这不是权宜之计，是设计退化——Python 明确鼓励用干净元组，而不是靠序列化打补丁
真正难的不是写出能跑的代码，而是让元组键从构造那一刻起就杜绝可变嵌套、单元素语法错误、以及后续对内层对象的误修改。这些点不在报错路径上，却决定字典是否长期可靠。
