带过期缓存应使用两个平行字典：_cache 存值、_expires 存过期时间戳；get() 时先判键存在再比对时间，过期则删除并返回 None，避免解包开销和逻辑耦合。
用 dict + time.time() 实现带过期的缓存，核心就一条：写入时记时间，读取时比时间
直接上手就能用，不需要额外依赖。关键不是“怎么存”，而是“什么时候判定过期”。每次 get() 都检查 timestamp 是否超过 ttl，过期就删掉键值对并返回 None。注意别在 set() 时主动清理旧数据——那会拖慢写入，且没必要；清理交给读操作触发更轻量。
常见错误是把时间戳存在值里（比如 {'key': (value, timestamp)}），导致每次读都要解包；更优做法是用两个平行字典：self._cache 存值，self._expires 存对应过期时间戳（time.time() + ttl）。这样读写都只需一次哈希查找。
手动实现 get() 和 set() 时，必须处理 KeyError 和过期逻辑分离
很多初学者把过期判断塞进 try/except KeyError 里，结果过期项没被删，下次还读到旧值。正确顺序是：先查键是否存在 → 存在则查是否过期 → 过期就 del 并返回 None → 否则返回值。
-
set(key, value, ttl=30)：写入self._cache[key] = value，同时self._expires[key] = time.time() + ttl -
get(key)：若key not in self._cache，直接返None；否则检查self._expires[key] ，成立就 <code>del self._cache[key]和del self._expires[key]，再返None - 不提供
__getitem__魔术方法，避免隐式调用绕过过期检查
用 threading.Lock 保护多线程下的读写竞态，但别锁整个 get/set 流程
多个线程同时 get() 同一个即将过期的 key，可能都判断为未过期，然后都返回值——这没问题；但若同时 set()，或一个 set() 一个 get()，就可能让 _expires 和 _cache 不一致。所以写操作（set、过期后的 del）必须加锁，读操作中仅涉及 del 的部分也要锁。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
示例片段：
def get(self, key):
if key not in self._cache:
return None
if self._expires[key] <= time.time():
with self._lock:
if key in self._cache: # 双重检查，防被其他线程先删
del self._cache[key]
del self._expires[key]
return None
return self._cache[key]别依赖 time.sleep() 或定时器做后台清理，它解决不了并发场景下的内存泄漏
有人想另起线程每秒扫一遍 _expires 删过期项，看似“自动”，实则问题一堆：扫描间隔内仍会累积脏数据；多线程下删字典时可能触发 RuntimeError: dictionary changed size during iteration；而且绝大多数缓存访问是稀疏的，冷 key 几天都不碰，后台轮询纯属浪费 CPU。
真正该做的是：接受“过期项只在被访问时清理”这个事实，并确保单次清理动作是原子、安全的。如果业务真有大量长期不访问的冷 key，应在上层设计中控制 key 的生成粒度（比如加用户 ID 前缀后定期归档），而不是靠缓存自己硬扛。
最易被忽略的一点：系统时间回拨（如 NTP 校正）会让大量缓存瞬间“假过期”。生产环境若对时间敏感，应改用 time.monotonic() 记录相对 TTL，但需注意它不能跨进程共享——这意味着多进程部署时，仍得回到 wall-clock 时间，只能靠监控告警兜底。
