frozenset能当字典键是因为其不可变且可哈希，set因可变无__hash__方法而不可用；它适用于无序去重场景如权限组合，但需确保元素本身可哈希。
为什么frozenset能当字典键，而set不能
frozenset 是不可变类型，满足 Python 字典键的哈希性要求；set 是可变类型，没有 __hash__ 方法，直接用作键会报 TypeError: unhashable type: 'set'。这不是限制，而是设计必然——如果键能被原地修改，哈希值就可能变化，字典内部索引会失效。
常见错误场景：把临时生成的 set 直接塞进字典，比如 d[{1, 2, 3}] = "value"，立刻崩。必须显式转成 frozenset：
d[frozenset([1, 2, 3])] = "value"
frozenset作为键的实际使用模式
它最常用于表示「无序、去重、不可变」的集合语义，比如权限组合、标签组、特征组合等。和 tuple 不同，frozenset 不关心顺序，frozenset([1,2]) == frozenset([2,1]) 为 True，天然适配集合等价逻辑。
- 适合做键的场景：
frozenset({"read", "write"})表示一组权限，不因字符串顺序不同而产生重复键 - 不适合的场景：需要保留插入顺序或允许重复元素（此时该用
tuple或str） - 嵌套注意：
frozenset只能包含可哈希对象，不能含list、dict、普通set，否则初始化就抛TypeError
性能对比：frozenset vs tuple vs str 做键
哈希计算开销略高于 tuple（因为要遍历并排序哈希值以保证顺序无关性），但实际差异极小，百万级键查表中几乎不可测。真正影响性能的是键的大小和碰撞率。
立即学习“Python免费学习笔记（深入）”；
- 小集合（≤10个元素）：
frozenset和tuple查找耗时基本一致 - 大集合（≥100个元素）：建议先评估是否真需集合语义；若只是枚举，用预计算的
str（如"|".join(sorted(items))）反而更轻量 - 内存占用：
frozenset比等价tuple略高，因额外维护哈希表结构，但通常可忽略
容易踩的坑：相等性与可哈希性陷阱
两个 frozenset 相等（==），它们的哈希值一定相同，这点没问题。但反过来说，如果你自定义类并实现了 __eq__ 却没同步实现 __hash__，哪怕把它放进 frozenset，这个 frozenset 也无法做字典键——因为其元素本身不可哈希。
- 错误示例：
class Bad: def __eq__(self, _): return True→frozenset([Bad()])能创建，但无法用作键，报TypeError: unhashable type - 正确做法：要么让类可哈希（定义
__hash__），要么只用内置可哈希类型（int、str、frozenset、tuple等）构建frozenset - 调试技巧：不确定某对象是否可哈希？直接跑
hash(obj)，不报错即安全
真正麻烦的是嵌套层级深、动态构造的 frozenset，一旦某层混入不可哈希对象，错误位置可能离实际使用点很远。建议在构造后立即验证 hash(frozenset(...))。
