字典和集合要求键必须可哈希，因哈希表依赖稳定hash值定位数据；可变类型不可哈希是因内容变更会导致hash值变化，使查找失效；元组仅当所有元素都可哈希时才可作键；自定义类需同时实现__hash__和__eq__且满足等值对象哈希值相等。
因为字典和集合底层用的是哈希表，而哈希表必须依赖稳定的 hash() 值来定位数据 —— 如果键不可哈希，连索引都算不出来，根本没法存或找。
哈希表怎么靠 hash() 找到值？
Python 字典不是按顺序查的，它先把键喂给 hash()，得到一个整数；再用这个整数对内部数组长度取余，得出存储位置（槽位）。下次要查同一个键，只要重新算一遍 hash()，就能直接跳到那个槽位。
这个过程要求：同一对象多次调用 hash() 必须返回相同结果；不同但相等的对象（比如 "abc" 和 str("abc")）也必须返回相同结果。否则，刚存进去就再也找不到了。
所以，不可哈希对象（比如 list、dict、set）一调 hash() 就抛 TypeError: unhashable type，压根不给进哈希表。
立即学习“Python免费学习笔记（深入）”；
为什么可变类型一定不可哈希？
可变类型的问题不在“能不能算出哈希值”，而在于“算出来也没用” —— 因为内容一改，哈希值就变，但字典不会自动更新槽位。
-
my_list = [1, 2]插入字典时，假设hash(my_list)算出是 100，存在第 100 槽 - 接着
my_list.append(3)，内容变了，hash(my_list)可能变成 205 - 再查
my_dict[my_list]，Python 还是去算新哈希值 205，结果在第 205 槽扑空
这不是 bug，是设计必然：哈希表不追踪键的生命周期，只认哈希值。所以 Python 直接禁止可变类型当键，省得你掉坑里还不知道为什么查不到。
元组能当键，但不是所有元组都行
元组本身不可变，但它只是个容器 —— 它是否可哈希，取决于里面每个元素是否都可哈希。
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
这些可以：(1, "a", True)、(("x", "y"), 42)、()
这些不行：([1, 2], "b")（列表在里面）、({"k": 1}, "c")（字典在里面）、(set([1]), "d")（集合在里面）
调试时最简单的方法就是手动试：hash(obj) 不报错才安全。别只看外层是不是元组，嵌套一层就漏检一次。
自定义类想当字典键，光不可变还不够
即使你把类设计成不可变（比如所有属性设为只读），也得显式实现 __hash__ 和 __eq__，且必须满足：如果 a == b 为真，那么 hash(a) == hash(b) 也必须为真。
常见错误是只写了 __eq__ 没写 __hash__，或者 __hash__ 返回了随机数、或依赖了可变属性。
更隐蔽的坑是：两个对象逻辑上相等（__eq__ 返回 True），但哈希值不同 —— 这会导致它们被当成两个不同键存进字典，破坏唯一性。
真正麻烦的不是“怎么让它可哈希”，而是“怎么确认它从里到外都稳得住”。尤其在嵌套结构或自定义类型里，哈希稳定性很容易被忽略，直到缓存失效、去重失败、或 key 查不到才暴露出来。
