线上经常遇到一种很无解的缓存问题。
给Redis的Key设置了过期时间，比如10分钟自动失效。时间到了之后，我们预想的是缓存清空、自动走数据库刷新数据。
但实际线上表现很诡异：过期之后一段时间内，接口依然能读到旧缓存数据，新数据迟迟不刷新。
查Redis控制台，Key确实没了。但代码就是能读到值，真的折磨人。
很多人第一反应怀疑过期时间没生效、代码时区问题、缓存没删干净，排查一圈啥问题找不到。
其实根本原因，是很多后端不知道 Redis 的过期删除机制根本不是实时删。
Redis不会精准到毫秒把过期key删掉，它的删除逻辑分三套：惰性删除、定时抽样删除、内存淘汰。
绝大多数过期数据，根本不是到点就消失。
先说最坑的惰性删除。
你的key过期后，如果一直没人访问，Redis根本不会管它。它安安静静躺在内存里，占用空间、滞留数据。
只有下一次代码主动去查这个key的时候，Redis才会校验过期，然后当场删掉返回空。
这就解释了那个玄学问题：过期了还能读到数据。
如果过期后瞬间有请求进来，刚好卡在删除前，旧数据直接被读取出来，业务读到过期缓存，造成数据延迟更新。
其次是定时抽样删除的局限性。
Redis后台只会随机抽样一部分过期key清理，不会遍历全量key。
如果你的过期key特别多、冷热数据混杂，大量过期垃圾key会一直残留内存，迟迟清不干净。轻微的内存占用变高，严重的一直读到脏数据。
最隐蔽的坑，是内存淘汰策略叠加过期机制。
很多生产Redis配置的是volatile-lru，只淘汰带过期的key。
当内存紧张时，优先删快要过期的，已经过期的反而可能滞留。导致明明过期很久的缓存，依旧常驻内存。
本地测试、测试环境内存充足，完全复现不了。只有线上流量大、内存满载的时候，问题疯狂暴露。
还有一个业务层大坑：缓存更新只靠过期，不主动删。
很多团队偷懒，数据更新、修改、删除之后，不主动清理缓存。完全依赖过期时间自动刷新。
过期机制本身就有滞后性，再加上Redis删除不实时，结果就是线上长期数据不一致，用户看到的一直是旧内容。
新手总觉得：设了expire，缓存就绝对可控。
实际上expire只是"最晚失效时间"，不是"精准删除时间"。
做久了中间件运维我总结出一个很实在的经验：
所有对数据一致性有要求的缓存，绝对不能靠过期自动刷新。
数据更新必须主动删缓存，过期时间只做兜底，防止代码异常导致缓存永久滞留。
很多线上数据不一致、缓存滞后、刷新不及时的bug，根本不是业务代码写错，是对Redis底层删除机制认知不足。
看似简单的缓存过期，其实藏着最多的隐形坑。