内存淘汰不会触发 invalidation 消息，因其是后台异步驱逐，不走命令执行路径，tracking 模块无法感知；只有 DEL、SET、EXPIRE 等显式变更命令才会触发。
能感知，但仅限于明确被修改或删除的 key，不包括因内存淘汰（如 maxmemory 策略触发的 LRU/LFU 驱逐）而被动下线的 key。
为什么内存淘汰不会触发 invalidation 消息
Redis 的客户端缓存 tracking 机制本质是「写时通知」：只有当某个 key 被显式执行了 DEL、SET、INCR、HSET 等变更命令时，服务端才会检查该 key 是否被某些 client tracking 记录，并推送 PUSH 类型的 invalidation 消息。
而内存淘汰（例如 volatile-lru 或 allkeys-lfu）是后台异步执行的驱逐行为，不走命令执行路径，也不产生 AOF / repl log，更不会触发 key space notification。tracking 模块根本不知道这个 key 是“被删了”，它只是“不见了”。
- 服务端不会为
evicted事件生成 invalidation 消息 -
CLIENT TRACKING ON不监听evict事件，只监听命令执行上下文中的 key 变更 - 即使开启了
notify-keyspace-events Ex，也仅影响 Pub/Sub，不影响 tracking 推送
哪些操作会真正触发 invalidation 消息
只有明确改变 key 状态的命令才会上报。注意：不是所有读写命令都算「变更」——只影响 value 或元数据的才算。
-
DEL、UNLINK：key 被删除 → 触发 -
SET、GETSET、SETEX、PSETEX：value 被覆盖 → 触发 -
INCR/DECR、HSET/HDEL、SADD/SREM等结构变更命令 → 触发 -
EXPIRE/PEXPIRE、EXPIREAT：key 过期时间被修改 → 触发（注意：过期本身不触发，改过期时间才触发） -
RENAME、RENAMENX：源 key 被移除 → 触发源 key 的 invalidation
反例：GET、EXISTS、TTL、OBJECT 等纯读命令，无论是否命中，都不会触发任何推送。
如何应对内存淘汰导致的本地缓存脏数据
这是客户端缓存最常被忽略的一致性盲区。不能依赖 tracking 自动兜底，必须主动设计 fallback 和兜底策略：
- 本地缓存需设置比 Redis TTL 更短的过期时间（例如 Redis 设 60s，本地设 45s），用时间窗口缓冲淘汰风险
- 对关键 key，在
GET后加一层EXISTS或TTL校验（代价小，但能捕获已淘汰 key） - 启用
CLIENT TRACKING ON REDIRECT+ 单独连接接收 push，并在收到 invalidation 后立即清空本地对应 key —— 但这仍不覆盖淘汰场景 - 业务层对「空结果」保持警惕：若本地有缓存但
GET返回 nil，应视为可能被淘汰，触发回源 + 强制刷新本地缓存
RESP3 push 消息本身无法区分淘汰还是主动删除
客户端收到的 invalidation 消息格式统一为：PUSH + invalidate + [key1 key2 ...]。它不携带原因字段，也不包含事件类型（如 evicted vs deleted）。你只能知道 “这个 key 不再可信”，但无法判断它是被 DEL 还是被 LRU 给踢出去的。
这意味着：哪怕你完整实现了 RESP3 push 解析和本地缓存清理逻辑，依然要为「没收到消息却已失效」的情况留余地 —— 淘汰就是静默发生的，没有 hook，没有回调，也没有日志可查。
