核心思路是前置验证热点key是否集中过期、回源是否失去并发控制、缓存是否被绕过；重点查redis过期事件峰值、典型key的ttl趋同性、预热脚本时间戳逻辑、分布式锁保留情况、慢sql重复模式及网关缓存命中率。

流量切换后出现崩溃，如果怀疑是缓存击穿引发的，核心思路不是“等它发生再救”，而是顺着“热点 key 在新流量路径下是否集中过期、是否失去保护”这条线快速验证。重点看三件事：新链路里有没有未适配的热点数据、缓存是否被批量清空、回源逻辑有没有并发控制。

盯住新接入的热点 key 是否过期时间撞车

流量切换常伴随缓存预热或全量刷新，容易把一批商品、用户、活动页的 key 设置成统一过期时间。一旦这批 key 在切换后几小时内集中失效，又恰逢新流量高峰，就极易触发击穿。

• 查 Redis 监控里的 key 过期事件速率（如 Redis 的 expired_keys 指标），看切换后是否出现突增峰值
• 抽样几个典型业务 key（比如爆款商品 ID、首页 banner 缓存），用 ttl key_name 手动确认它们的剩余过期时间是否高度趋同
• 检查预热脚本或配置中心——是否用了固定时间戳（如 expireAt = now + 3600）而非随机偏移，导致集体到期

验证回源查询是否在击穿瞬间失去保护

击穿的本质是“多个请求同时发现缓存为空，全部冲向数据库”。所以要看切换后，那个关键接口的回源逻辑是否还保留互斥重建机制。

• 翻代码：确认是否仍使用 分布式锁（如 Redis SETNX + Lua） 或 本地锁 + 双检锁 来保障只有一个请求回源，其余等待
• 看日志：搜索切换后几分钟内该接口的慢查询日志，是否出现大量重复 SQL（相同 WHERE 条件、毫秒级时间戳高度集中），这是并发回源的典型痕迹
• 模拟验证：用压测工具对一个已过期的热点 key 发起 100 并发 GET 请求，观察数据库 QPS 是否飙升、Redis 中该 key 是否只被写入一次

检查缓存层是否被意外绕过或降级

流量切换时，网关、SDK 或中间件配置可能变更，导致部分请求没走缓存，直接打库。

• 查网关日志或链路追踪（如 SkyWalking），确认切换后请求是否 100% 经过缓存代理层；特别留意 header 中是否有 X-Skip-Cache: true 类似标记被误开启
• 检查客户端 SDK 版本和配置——新流量路径是否启用了不同版本的缓存客户端，该版本是否默认关闭了本地缓存或熔断策略
• 看 Redis 监控中的 get 命中率 和 miss 后的 set 操作比例：若 miss 率骤升但 set 次数远低于 miss 次数，说明大量请求 miss 后根本没走到回填逻辑（可能被异常拦截或提前返回）

不复杂但容易忽略。