redis不通知客户端key被删原因，客户端仅能通过get等返回nil得知“查不到”，无法区分是过期删除还是内存淘汰；真正判断依据是info stats中的expired_keys和evicted_keys指标。

Redis客户端收不到“这个key被删了”的通知

Redis 不提供任何机制让客户端得知一个 key 是因过期被惰性/定期删除，还是因内存不足被 maxmemory-policy 淘汰。客户端调用 GET 或 HGET 时，只要返回 null（或空响应），就只能知道「当前查不到」，无法区分背后是哪种清理路径。

DEL、UNLINK 和淘汰策略对客户端完全透明

无论你手动执行 DEL、UNLINK，还是 Redis 自动触发淘汰（比如 allkeys-lru），客户端收到的响应都一样：命令成功返回 OK，但后续读取就是 (nil)。没有日志、没有回调、没有 Pub/Sub 事件——Redis 的设计哲学就是不向客户端暴露内部资源管理细节。

• DEL 是同步阻塞操作，执行完 key 立即不可见；
• UNLINK 是异步摘除，key 在命令返回后立刻不可见，但内存释放延迟；
• 淘汰策略触发的删除，行为等同于 DEL（对客户端而言），只是时机由内存压力驱动。

为什么不能加个事件通知？

加事件会破坏 Redis 单线程模型的确定性，也违背其轻量定位。更关键的是：业务逻辑本就不该依赖“谁删的 key”这个信息。真正需要关注的是：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 是否设置了合理过期时间（避免过期堆积）；
• 是否配置了合适的 maxmemory-policy（比如不用 noeviction 导致写失败）；
• 是否监控 evicted_keys 和 expired_keys 这两个指标（它们才是判断淘汰/过期频次的唯一依据）。

容易忽略的调试盲区

很多人在排查缓存失效问题时，只看应用层日志里有没有 DEL 调用，却忘了检查 INFO stats 中的 evicted_keys。如果这个值持续增长，说明你的内存快满了，正在默默淘汰数据——而客户端连 warning 都不会收到。

真正的线索藏在服务端指标里，不是客户端响应里。