缓存绕过问题的关键在于定位规则冲突，需通过确认缓存真实状态、排查多层规则打架、追踪请求id链路、本地模拟验证四步揪出真凶。
缓存绕过本身不是问题，但当它发生在不该发生的请求上——比如大量正常用户请求本该命中缓存却直连后端，就说明缓存策略出了偏差。排查这类问题，关键不是“有没有绕过”，而是“谁绕过了、为什么绕过、规则是否互相打架”。下面从定位、分析、验证三步讲清楚怎么揪出规则冲突这个真凶。
先确认是不是真绕过，还是缓存压根没建起来
很多所谓“绕过”，其实是缓存根本没成功写入，或者写入后立刻被驱逐。先排除基础链路问题：
- 查 Redis key 是否真实存在：用
EXISTS user:1001或GET user:1001直连验证，别只看监控命中率； - 检查缓存写入逻辑是否被跳过：比如数据库查询返回 null 后，代码漏了
set(key, null, 2min)，导致空值没缓存； - 确认 TTL 设置是否合理：比如设置了 5 秒过期，而接口平均耗时 6 秒，相当于缓存永远赶不上请求节奏；
- 留意多级缓存场景（CDN + Nginx + Redis）：某一级缓存未命中，可能被误判为“整体绕过”，实际是 CDN 缓存未生效，而 Redis 是命中的。
重点查规则冲突：常见打架组合
缓存绕过往往不是单一配置决定的，而是多层拦截规则叠加后意外放行。以下几类冲突最典型：
-
URL 参数校验 vs 缓存 key 构造逻辑不一致：比如前端带
?v=1.2.3版本参数，后端缓存 key 却只取 path（/user/1001），但网关层限流或鉴权规则又把带v=的请求标记为“动态请求”强制 bypass 缓存； -
用户身份判断覆盖缓存策略：例如对 VIP 用户开启实时数据开关（加 header
X-Realtime: true），但中间件在识别到该 header 后直接跳过所有缓存逻辑，而部分普通用户因埋点 SDK 异常也携带了同样 header； -
CDN 缓存策略和源站 Cache-Control 冲突：CDN 控制台设置 TTL=1h，但 Spring Boot 接口返回
Cache-Control: no-cache，CDN 尊重源站响应头，结果所有请求都回源； - 灰度发布开关误影响缓存路由：A/B 测试中间件根据 cookie 或 UA 路由到新版本服务，而新版本服务尚未接入缓存客户端，或缓存 client 初始化失败静默降级。
用请求 ID 追踪一条真实绕过链路
不要只看统计数字，挑一个明确绕过的正常用户请求，从入口开始顺藤摸瓜：
- 在 Nginx 或 API 网关层打日志，记录该请求是否命中 CDN 缓存（查
X-Cache: HIT/MISS）； - 在业务服务入口加 trace 日志，打印是否进入缓存读取分支、key 值、Redis 返回结果、是否触发数据库查询；
- 对比同一用户前后两次请求：第一次 miss 后是否成功写入缓存？第二次请求的 key 和第一次是否完全一致（注意大小写、空格、编码差异）？
- 抓包看客户端发出的请求头，确认是否有隐藏字段（如
X-Debug-Skip-Cache）被内部测试工具或 DevTools 插件悄悄注入。
快速验证规则是否冲突的小技巧
不用等线上复现，本地或预发环境就能试：
- 用 curl 模拟不同组合请求：
curl -H "X-User-Type: vip" /api/user/1001vscurl -H "X-User-Type: normal" /api/user/1001，对比 Redis key 是否生成、是否查询 DB； - 临时关闭某一层规则（比如注释掉网关的 bypass 逻辑），观察命中率是否回升；
- 在缓存读取前加断点，观察条件表达式求值结果——比如
if (isVip || hasParam("debug")) { bypass = true; }，检查普通用户是否因 debug 参数残留被误判。
