元组能当字典键而列表会报 typeerror，因字典依赖哈希表，要求键不可变且__hash__恒定；元组若含可变元素（如列表）也不可哈希，单元素元组须写为(1,)，用str或json.dumps替代会丢失语义、降低性能。
为什么元组能当字典键而列表会报 TypeError
因为字典底层依赖哈希表，而哈希表要求键的 __hash__ 值在生命周期内恒定。元组是不可变对象，只要其所有元素都可哈希（如 int、str、其他元组），它就能稳定生成哈希值；列表是可变对象，list.__hash__ 直接被设为 None，尝试用它做键会立刻触发 TypeError: unhashable type: 'list'。
(1, 2) 可以，但 (1, [2]) 不行：嵌套可变对象的陷阱
元组自身的不可变性不等于“递归不可变”。如果元组里包含列表、字典或集合等可变类型，整个元组就失去可哈希性：
-
{(1, 2): "ok"}✅ 合法 —— 所有元素都是不可变类型 -
{(1, [2]): "bad"}❌ 报TypeError: unhashable type: 'list' -
{(1, tuple([2])): "fixed"}✅ 修复方式：把嵌套列表转成元组
实际用元组当键时，常见错误场景
不是所有看起来像元组的结构都能当键。容易踩坑的地方包括：
- 单元素元组漏写逗号：
(1)是int，不是元组；必须写成(1,)才可哈希 - 从外部数据动态构造元组时未校验内容，比如
tuple(user_input.split())若输入含空字符串或需进一步解析的数据，可能隐含可变结构 - 误以为“元组 = 安全”，却在后续代码中修改了元组内嵌的可变对象（如
t = (1, [2, 3]); t[1].append(4)），虽不破坏元组结构，但已破坏哈希一致性前提
性能与语义：为什么不用 str(key) 或 json.dumps(key) 替代元组
有人想绕过限制，把列表转成字符串再当键，比如 {str([1,2]): "value"}。这看似可行，但带来严重问题：
- 语义丢失：
str([1, 2]) == "[1, 2]"，和str((1, 2)) == "(1, 2)"冲突，不同结构可能产生相同字符串 - 类型混淆：无法再通过键反推原始数据结构，后续逻辑需额外解析
- 性能开销：每次访问都要调用
str()或json.dumps()，远不如原生元组哈希快 - 非标准做法：违背 Python 的设计直觉，增加维护成本
真正需要复合键时，老老实实用元组，并确保元素干净——这是最轻量、最可靠、也最符合 Python 惯例的方式。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
