不能直接用普通 dict 做带过期的缓存，因为 dict 不记录写入时间、无法自动清理过期项，每次读取需手动校验时间且遍历删除性能差、易漏删、线程不安全。
为什么不能直接用普通 dict 做带过期的缓存
因为 dict 本身不记录写入时间，也没法自动清理过期项。你查 cache['key'] 时，它不会告诉你这个值是不是已经超时了——哪怕你存的时候记了时间，每次读都得手动比对 time.time()，而且删过期项还得遍历，性能差、易漏删、线程不安全。
最简可行方案：封装一个 TTLCache 类，用 time.time() + dict 维护
核心思路是：每个 key 对应一个元组 (value, expire_at)，读取时检查 expire_at ，命中则返回值，否则删掉并返回 <code>None。写入时算好过期时间戳，不是相对秒数，避免重复计算。
- 写入时用
time.time() + ttl_seconds存绝对时间戳，比存相对时间更稳定（尤其在系统时间跳变或 NTP 同步时） - 读取时不做删除动作，只判断是否过期；真正清理交给
get()或__getitem__()中的惰性剔除 - 如果需要批量清理，可以加个
purge()方法遍历删，但别在每次get里全量扫——O(n) 太伤
import time
class TTLCache:
def __init__(self):
self._data = {}
def set(self, key, value, ttl):
self._data[key] = (value, time.time() + ttl)
def get(self, key, default=None):
item = self._data.get(key)
if item is None:
return default
value, expire_at = item
if time.time() > expire_at:
del self._data[key]
return default
return value
def __contains__(self, key):
return self.get(key) is not None
time.time() 精度和时钟漂移会影响 TTL 准确性吗
会，但通常可接受。Linux/macOS 上 time.time() 默认基于 CLOCK_REALTIME，精度约毫秒级，且受系统时钟调整影响（比如 NTP step 调整会导致时间突变）。如果你的业务对“严格±100ms 内过期”有强要求，就得换 time.monotonic() ——它不随系统时间跳变，但无法映射到真实时间点，所以必须在 set() 时记录起始单调时间，并用 ttl 做相对偏移。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 用
time.monotonic()的话，set()存的是(value, time.monotonic() + ttl)，get()比较用time.monotonic() > expire_at - 缺点：无法实现“固定时刻过期”，比如“每天凌晨 2 点清空”，只能做“写入后 N 秒过期”
- 优点：完全免疫系统时钟倒拨/跳跃，TTL 行为可预测
并发访问下 dict 不是线程安全的，怎么办
dict 的读写在 CPython 中虽有 GIL 保护，但像 if key in d: return d[key] 这种“检查-读取”操作不是原子的，多线程下可能读到过期值或触发 KeyError。真要在线程间共享，必须加锁。
立即学习“Python免费学习笔记（深入）”；
- 最简单是给整个
_data加threading.RLock()，所有方法入口加with self._lock: - 不要用
@synchronized或装饰器隐藏锁逻辑——容易漏锁，也难调试 - 如果用在 asyncio 环境，换成
asyncio.Lock()，但注意：不能混用同步/异步锁 - 高并发场景下，锁粒度太粗会成瓶颈，这时该考虑
functools.lru_cache+ 外部 TTL 轮询，或直接上redis
