缓存需权衡数据不变性、访问频率、内存开销与一致性；只缓存计算昂贵、读多写少、生命周期可控的数据，如纯函数结果、带TTL的外部API响应、低频更新的维度表；禁用动态值、毫秒级计算及大对象；选对工具并设过期与失效机制，监控命中率与存留时间，配置降级策略。
缓存不是“加了就快”，而是要在数据不变性、访问频率、内存开销和一致性之间做权衡。合理使用的关键是：只缓存那些计算昂贵、读多写少、生命周期可控的数据。
明确缓存边界：什么该缓存，什么不该
适合缓存的典型场景：
- 纯函数结果（输入相同，输出恒定），比如解析固定配置文件、生成静态 HTML 模板
- 外部 API 的响应（需配合 TTL 和错误降级，避免缓存失败响应）
- 数据库查询结果（仅限低频更新的维度表、状态枚举等，严禁缓存用户订单这类强实时数据）
明确不建议缓存的：
- 含当前时间、随机数、用户会话 ID 等动态上下文
的返回值
- 单次调用耗时低于 1ms 的本地计算（缓存本身开销可能更高）
- 大小超过几 MB 的对象（易引发内存压力或 GC 颠簸）
选对工具：内置装饰器 vs 手动管理
@lru_cache 适合简单、无副作用、参数可哈希的函数：
✅ 正确用法：def get_user_role(user_id: int) -> str: ...（user_id 是整数，角色极少变更）
❌ 错误用法：def process_request(data: dict) -> dict: ...（dict 不可哈希，会报错；且 request 数据高度动态）
需要精细控制时，用 functools.cached_property（实例属性级缓存）或第三方库如 diskcache（支持持久化、淘汰策略、线程安全）。
必须设置过期与失效机制
无过期的缓存等于埋雷。Python 标准库不提供带 TTL 的 LRU，需自行补充：
- 用 cache = TTLCache(maxsize=128, ttl=300)（来自 cashews 或 aiocache）
- 手动在
@lru_cache外包一层时间检查（适合简单场景） - 写操作后主动 cache_clear() 或按 key 删除（如更新用户信息后删掉对应
get_user(id)缓存）
特别注意：分布式环境下，单机缓存清除无效，需结合 Redis 的 publish/subscribe 或删除共享缓存。
监控与降级：缓存不是黑盒
上线后要可观测：
- 记录缓存命中率（命中数 / 总请求数），持续低于 70% 要重新评估是否值得缓存
- 统计缓存平均存留时间，过短说明更新太频繁，缓存收益低
- 设置 fallback：当缓存不可用（如 Redis 连接失败），自动回退到原始逻辑，而非直接报错
可用 tenacity 重试 + structlog 打点，把缓存行为变成可追踪的日志事件。
