元组能当字典键而列表不能，是因为字典依赖哈希表，要求键的哈希值恒定不变；列表可原地修改导致哈希不安全，故被禁止哈希；元组仅当所有元素（包括嵌套）均不可变时才可哈希。
因为字典键必须可哈希，而只有不可变对象才能稳定生成哈希值；list 的 __hash__ 被设为 None，一尝试用它当键就立刻报 TypeError: unhashable type: 'list'。
元组能当字典键，列表不能——底层原因是什么
Python 字典底层是哈希表，要求键的哈希值在对象生命周期内恒定不变。元组只要所有元素都可哈希（如 int、str、嵌套元组），就能稳定返回 hash() 值；列表允许原地修改（append、pop、索引赋值），一旦内容变了，哈希值就得变——但字典内部已按旧哈希值存放该键，再查就找不到，所以干脆禁止它可哈希。
-
hash((1, 2))返回固定整数，多次调用结果一致 -
hash([1, 2])直接抛出TypeError，不是计算失败，而是语言层面禁止 - 哪怕只改列表一个元素，比如
l[0] = 99，它的id()不变，但已破坏哈希一致性前提
看似是元组，却依然不可哈希的常见陷阱
元组自身的不可变性 ≠ 递归不可变。只要嵌套了任何可变对象（list、dict、set），整个元组就失去可哈希性。
-
(1, 2)✅ 合法键 —— 所有元素都是不可变类型 -
(1, [2])❌ 报错TypeError: unhashable type: 'list' -
(1, tuple([2]))✅ 修复方式：把嵌套列表转成元组 -
(1, {"a": 2})❌ 字典不可哈希，哪怕在外层套元组也没用
单元素元组写法错误导致键失效
看起来像元组，实际是其他类型——这是最隐蔽的坑。Python 中括号不决定类型，逗号才决定。
-
(1)是int，不是元组，hash((1))等价于hash(1)，但用它做键会掩盖真实意图，且后续扩展易出错 -
(1,)才是真正的单元素元组，type((1,))返回<class></class> - 从用户输入动态构造时尤其危险：
tuple(user_input.split())若输入含空格分隔的字符串，可能产生("", "x")，虽可哈希，但值本身可能不符合业务语义
用元组当键时，容易被忽略的“伪安全”行为
元组结构没变，不代表它仍适合作为键——如果它内部包含可变对象，你没动元组本身，但动了里面的东西，哈希前提就崩了。
-
t = (1, [2, 3])→t[1].append(4)不报错，t还是那个元组，但[2, 3]已变成[2, 3, 4] - 此时若用
t当字典键，后续查找可能命中错误值，或根本查不到——因为哈希值在构造时算过一次，之后没重算，但内容已变 - 这种问题在线上多线程环境里极难复现，往往表现为缓存击穿或数据错乱，而不是直接报错
真正安全的元组键，得从源头保证“扁平+全不可变”，或者手动深拷贝后冻结（比如用 tuple(map(tuple, nested_list))）；别依赖“用了元组就万事大吉”这个直觉。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
