lru_cache基于参数的hash()结果生成缓存键，而非对象身份或简单值比较；内置不可变类型按值哈希，自定义类默认按ID哈希，可变类型直接报错。
lru_cache 对参数的哈希判断基于对象身份还是值？
@lru_cache 在缓存键生成时，对每个参数调用 hash()，再组合成元组进行哈希。这意味着：它依赖参数是否可哈希，且哈希结果由对象的 __hash__ 和 __eq__ 行为决定，**不是简单地“值相等就命中缓存”**。
常见误区是认为 [1, 2] == [1, 2] 就能共用缓存 —— 实际上列表不可哈希，直接抛 TypeError: unhashable type: 'list'；而 (1, 2) == (1, 2) 是 OK 的，因为元组可哈希且值相同则哈希相同。
- 内置不可变类型（
int、str、tuple、frozenset）按值哈希，同值同哈希 - 自定义类若未重写
__hash__，默认按对象 ID 哈希（即不同实例即使==也为不同键） - 可变类型（
list、dict、set）直接报错，无法作为参数
不同类型但值相同的参数一定不共享缓存吗？
不一定，但绝大多数情况不共享 —— 因为类型不同通常意味着 hash() 结果不同，哪怕逻辑值相等。例如：
from functools import lru_cache@lru_cache def f(x): print("called with", x) return x
f(42) # called with 42 f(42.0) # called with 42.0 → 新缓存项！ f("42") # called with 42 → 又一个新项
原因：hash(42) != hash(42.0) != hash("42")，三者类型不同，哈希值独立计算。
-
int和float即使数值相等（如1 == 1.0），哈希也不同（CPython 中
hash(1) is 1，hash(1.0) is 1碰巧相同，但hash(2.0) == 2仅限整数浮点数；非整数如1.1哈希完全不同） -
str和bytes绝对不共享，hash("a") != hash(b"a") - 用户自定义类之间，除非显式让不同类实例返回相同
hash()并互认__eq__，否则不可能命中
想让不同类型但语义相同的参数共享缓存，怎么办？
不能靠改 @lru_cache 行为，得在函数入口做标准化。核心思路：把原始参数统一转成一种规范、可哈希的中间表示（canonical form），再用它参与缓存键计算。
例如处理“ID 可以是 int、str 或 UUID”的场景：
@lru_cache
def _fetch_by_id_canonical(canonical_id):
# 实际业务逻辑，只接收标准化后的 id
return db_query(canonical_id)
def fetch_by_id(raw_id):
标准化：转成 str（或 int，取决于业务）
if isinstance(raw_id, (int, str)):
canonical = str(raw_id)
elif isinstance(raw_id, UUID):
canonical = str(raw_id)
else:
raise TypeError(f"Unsupported id type: {type(raw_id)}")
return _fetch_by_id_canonical(canonical)- 避免在装饰器内做转换（
@lru_cache不接受预处理逻辑），必须拆成两层函数 - 标准化目标要满足：可哈希 + 能无损表达原始语义（比如用
str表示 ID 通常安全，但注意前导零丢失风险） - 如果原始类型含状态（如带方法的对象），标准化需谨慎，可能丢失关键信息
为什么不用自定义哈希键（比如手动 tuple(hashable_args)）替代 lru_cache？
可以，但没必要自己重复造轮子 —— @lru_cache 已高效处理哈希、命中、淘汰。真正要注意的是：它的键生成机制是黑盒且不可插拔的，你无法绕过 hash() 直接控制键内容。
试图用 functools._make_key（内部函数）或重写 __hash__ 强行统一不同类型的哈希值，会带来严重隐患：
- 破坏类型语义：让
int和str在所有上下文中哈希相同，可能污染其他字典/集合行为 - 违反哈希契约：若
a == b但hash(a) != hash(b)，Python 允许；但反过来，若hash(a) == hash(b)却a != b，会导致字典冲突、逻辑错误 -
@lru_cache的键是参数元组，不是单个参数 —— 即便你让hash(42) == hash("42")，(42, "hello")和("42", "hello")仍是不同键
所以最稳妥的做法始终是：在调用方或包装层做显式归一化，而不是挑战哈希系统本身。
