结论是缓存空值、布隆过滤器与接口层参数校验必须三层组合使用，单靠任一方案无法应对生产环境中的恶意穿透；第三方接口因缺乏强一致性、熔断和细粒度限流，更易因非法参数（如eventId=9999999）引发链路雪崩。
直接说结论：用 缓存空值 + 布隆过滤器 + 接口层参数校验 三层组合，才能稳住第三方接口不被无效请求打崩。单靠一种方案，在生产环境基本扛不住。
为什么第三方接口特别怕缓存穿透？
第三方接口通常不具备强一致性、无熔断兜底、限流粒度粗（比如只按 IP 限），一旦遇到恶意构造的 eventId=9999999 或 uid=abc123 这类非法参数，请求会：
- 绕过你本地缓存（因为 key 根本没预热过）
- 直连第三方服务（可能没鉴权或鉴权失败但仍计费）
- 触发其风控降级甚至封禁你的调用方身份
- 而你自己的服务还收不到明确错误码，只能看到超时或
503 Service Unavailable
这不是 Redis 缓存问题，是“缓存策略没覆盖到上游依赖”导致的链路雪崩。
redisTemplate.opsForValue().set() 缓存空值必须加随机 TTL
很多团队照搬示例代码，把空值统一设为 60 秒过期，结果在压测时发现：大量不同非法 eventId 同时涌入，Redis 内存被空值占满，有效缓存被淘汰——这反而加剧了穿透。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 空值 TTL 必须带随机偏移，例如
60 + new Random().nextInt(30)秒 - 空值 value 不能用
null或空字符串，要用业务可识别的标记，如"EMPTY_EVENT"，避免和真实空响应混淆 - key 命名要带业务上下文，比如
"thirdparty:event:DescribeBrandGoodList:9999999"，别和正常数据混用同一前缀 - 务必检查第三方返回的 HTTP 状态码：只有
404或明确的{"code":40001,"msg":"event not found"}才写空值；5xx或超时一律不缓存，防止把故障状态固化
布隆过滤器不是“开箱即用”，得和第三方数据生命周期对齐
布隆过滤器在第三方场景下最容易踩的坑，是“数据已更新，过滤器没重建”。比如 CF 奖展品列表每月 1 号全量刷新，但你的布隆过滤器还在用上个月的 ID 集合。
- 必须有定时任务（如每天凌晨）拉取第三方全量有效
eventId列表，重建布隆过滤器并推送到所有节点 - 使用
BloomFilter.create(Funnels.longFunnel(), expectedInsertions, 0.01)，误判率设为0.01（1%），别盲目调低——误判率每降低 10 倍，内存占用翻倍 - 过滤器要放在网关或 Feign Client 封装层，而不是业务 service 里；否则每个请求都走一次
bloomFilter.mightContain()，CPU 开销明显 - 当布隆判断“不存在”时，直接返回
400 Bad Request，别再往下走 Redis 或第三方调用
接口层校验比缓存更前置、更轻量
别等请求走到 Redis 才拦截。对第三方接口的入参做硬性约束，成本最低、见效最快。
-
eventId必须是正整数且< 10000000（根据第三方文档上限设定） -
pageIndex和pageSize要校验范围，比如pageSize不能超过100 - 所有字符串参数（如
lang）用白名单校验：if (!Arrays.asList("zh", "en").contains(lang)) { throw new IllegalArgumentException(); } - 用 Spring Validation 的
@Min/@Pattern注解，比手写 if 判断更可靠，且自动集成到 OpenAPI 文档
真正难的不是实现某一个方案，而是让这三层拦截在日志里能串起来：当一个非法请求进来，你要能在 ELK 里查到它被哪一层拦下、为什么没进 Redis、有没有触发布隆重建告警——否则出了问题，还是得翻三天日志。
