缓存有效期失效指缓存项在应有效期内提前不可用，需排查“本该活多久”和“谁让它提前死”；分三类：上游响应头解析异常（如Cache-Control含非法字符）、Redis层TTL异常（ttl命令查-2/-1/正数及monitor抓清除动作）、框架层绕过缓存（如ThinkPHP的APP_DEBUG=true静默禁用、Spring Boot序列化失败返回null）。
缓存有效期失效，不等于“时间一到就自动消失”，而是指缓存项在本该有效的时间段内提前不可用——可能被误删、解析失败、配置覆盖或系统时钟异常。排查核心不是查“过了多久”，而是查“它本该活多久”和“谁/什么让它提前死了”。下面分三类典型场景讲清怎么定位、怎么看日志、怎么验证。
看上游响应头是否被正确解析（HTTP/反向代理缓存）
Nginx、Varnish等代理缓存的过期逻辑，完全依赖后端返回的 Cache-Control 或 Expires 响应头。但这些头一旦含非法字符（比如空格、不可见Unicode、换行、重复字段），Nginx 就会静默忽略，导致实际缓存时间为 0（即不缓存）。
- 在 location 块中加调试日志：log_format cache_debug '$remote_addr "$request" $status $upstream_http_cache_control $upstream_http_expires';，再配 access_log 输出
- 重点检查 $upstream_http_cache_control 是否为 public, max-age=3600 这类合法值；若为空、为 max-age= （末尾带空格）或 max-age=3600（零宽空格），说明后端输出了脏数据
- 用 curl -v http://your-api/xxx + xxd 查原始响应头二进制内容，确认有无控制字符
- error_log 中若出现 "invalid cache control header" 或 "invalid expires header"，就是根因
查 Redis 等存储层 key 的真实 TTL（应用级缓存）
代码里设了 30 分钟，不代表 Redis 里真存了 30 分钟。可能是写入时 TTL 被覆盖、序列化错误导致 key 写错、或被 flush 操作清空。
- 直连 redis-cli，执行 ttl your_key：返回 1720 是正常剩余秒数；-1 表示永不过期；-2 表示 key 根本不存在
- 批量查 3～5 个高频 key 的 ttl，看是否集中在某分钟归零——这是雪崩信号
- 执行 monitor（注意容器环境要查日志文件），观察是否有 flushdb、del、expire 等命令触发
- 查 info stats 中的 expired_keys（自然过期数）和 evicted_keys（内存淘汰数），区分是“到期”还是“被踢出”
验框架层是否绕过或禁用了缓存（ThinkPHP/MyBatis/Spring Boot）
很多缓存失效，根本没走到存储层——框架在中间就拦截、跳过或重写了 TTL。
- ThinkPHP：开启 cache 日志，检查 runtime/log/cache/ 下日志是否记录了 set 操作；确认 APP_DEBUG=false，否则缓存写入会被静默忽略
- MyBatis：一级缓存只在同一个 SqlSession 内有效，@Transactional(propagation = REQUIRES_NEW) 会新建 Session，导致前序缓存失效；BaseMapper 方法默认 flushCache=true，查询也清缓存
- Spring Boot + RedisTemplate：检查是否用了 setTimeToLive() 但传了负数，或序列化器（如 GenericJackson2JsonRedisSerializer）在反序列化失败时返回 null，被当成“空值缓存”处理
