过期键未被定时扫描删除，仍会在内存淘汰时被顺手清理；淘汰前会遍历expires字典调用expireifneeded()兜底清理，但loading中、db未选中、主字典缺失或从节点只读时可能漏删。
过期键没被定时扫描删掉，就一定会在内存淘汰时被顺手清理
Redis 的内存淘汰（maxmemory-policy）不是只看“当前是否占内存”，而是把“已过期但尚未删除”的键视作“逻辑上已失效、物理上仍残留”的垃圾。只要触发淘汰流程（比如 set 写入导致内存超限），它就会把这些键当作候选对象一并踢掉——不管它们有没有被 expireIfNeeded() 检查过，也不管定期扫描漏没漏。
为什么淘汰阶段会顺手删过期键
淘汰流程（如 evict() 函数）在挑选待删 key 之前，会先做一轮快速兜底清理：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 遍历当前 db 的
expires字典，对每个带 TTL 的 key 调用expireIfNeeded()—— 这是惰性删除的逻辑复用，不依赖访问触发 - 如果该 key 确实已过期，直接调用
dbDelete()删除，不计入淘汰计数，也不走 LRU/LFU 排序 - 这步清理发生在真正执行淘汰策略（如
volatile-lru）之前，属于“免费顺手清场” - 所以哪怕你从没
get过它、定期扫描也一直没抽中它，只要内存告急，它大概率在这一步就被干掉了
哪些情况会导致淘汰时也漏掉过期键
这个兜底清理不是 100% 全量扫描，仍有边界条件让它跳过：
-
server.loading == 1（正在加载 RDB/AOF）时，expireIfNeeded()直接返回 0，跳过检查 - key 所在的 db 没被当前淘汰循环选中（Redis 淘汰默认轮询所有 db，但若配置了
maxmemory-samples极小，可能跳过某些 db） - 该 key 在
expires字典里，但对应主字典（dict）里已无实体（比如被其他命令意外 unlink），此时dbDelete()失败，但不会报错也不会重试 - 集群模式下，如果你连的是从节点且
slave-read-only yes，而淘汰只在主节点发生，从节点上的过期键可能长期滞留（因从节点不主动淘汰）
volatile-ttl 策略下过期键的特殊待遇
当配置为 volatile-ttl 时，Redis 不会“顺手清理”，而是**专门挑过期时间最短的 volatile key 来删**：
- 它只遍历
expires字典，按剩余 TTL 升序排序，取第一个（或前几个样本） - 这个过程会真实触发
expireIfNeeded()，所以哪怕 TTL 已为负，也能确保删除 - 但它不处理 non-volatile key（即没设 TTL 的），也不清理已过期但 TTL 字段异常的 key（如系统时间回拨导致
when值错乱） - 注意：
volatile-ttl的实际效果高度依赖maxmemory-samples值——设成 1 就极易误删刚设 TTL 的 key；建议至少设为 5
真正容易被忽略的是：这个“顺手清理”只发生在内存压力触发淘汰时，平时没压力，它就继续躺着。别指望靠淘汰机制兜底日常清理，得靠合理设置 hz 和 active-expire-effort 把定期扫描顶上去。
