参数校验必须在redis查询之前完成，否则非法id将导致缓存穿透；需对主键id做范围、格式校验，并配合空值缓存、布隆过滤器及接口限流形成多层防护。
参数校验必须在 Redis 查询之前做
Redis 本身不校验业务参数，它只管存取。一旦传入非法 id（比如负数、超长字符串、UUID 格式却当数字用），缓存必然 miss，请求直接打到数据库——这不是 Redis 的问题，是业务入口没设防。
常见错误现象：findById(-1)、findById("abc")、findById(9999999999999999999) 这类调用在日志里高频出现，DB 慢查询陡增，但 Redis 监控看不出异常。
- 校验位置必须在
redisTemplate.opsForValue().get(...)之前，不能放在“查不到再查库”之后 - 对主键类 ID，至少检查范围：
id > 0 && id （比如你系统最大 ID 是 2^50，那就拦掉更大的） - 字符串 ID 要限制长度和字符集，比如只允许数字+字母，长度 ≤ 32；避免
"../etc/passwd"或 SQL 注入式构造 - Spring Boot 中可在 Controller 层用
@Valid+ 自定义@Positive注解，或在 Service 入口加if (id
空值缓存不是万能解，TTL 和 key 设计很关键
缓存空结果能拦住重复无效请求，但若不做约束，会被恶意刷爆内存。比如攻击者用脚本循环请求 user:1 到 user:1000000，Redis 就真存一百万个 ""。
- 空值必须设短 TTL：
redisTemplate.opsForValue().set(key, "", 2, TimeUnit.MINUTES)，别用永不过期或几小时 - key 命名建议带标识，比如
"empty:user:" + id，方便后期扫描清理或监控空值占比 - 避免缓存原始 null：Java 里
redisTemplate.opsForValue().set(key, null)可能序列化失败，统一转成""或"NULL"字符串 - 注意序列化器配置：如果用了
GenericJackson2JsonRedisSerializer，空字符串反序列化可能报错，建议搭配StringRedisTemplate处理空值
布隆过滤器适合“存在性预检”，但得会初始化和维护
布隆过滤器（Bloom Filter）不是 Redis 内置功能，它是前置拦截的第一道关卡，判断“这 ID 绝对不存在”，就直接返回，连 Redis 都不碰。
典型误用：上线后只初始化一次全量用户 ID，但后续新增用户没同步进过滤器，导致新用户查不到——这是数据一致性问题，不是 BF 本身失效。
- 初始化要覆盖全量合法 ID：
userBloom.AddString(fmt.Sprintf("%d", id))，建议在应用启动时从 DB 或分页扫表加载 - 增量更新难做，所以更适合 ID 稳定、变更少的场景（如用户、商品主数据）；高频增删的（如订单）慎用
- Redis 官方模块
RedisBloom提供BF.ADD/BF.EXISTS，比本地 BF 更易运维，但需单独部署和配置 - 误差率别设太低：
error_rate=0.01是合理起点；设成 0.001 会让内存翻倍，实际收益不大
别忽略接口层限流和黑名单兜底
参数校验 + 空值缓存 + 布隆过滤器，三者都可能被绕过。比如攻击者用代理池轮换 IP，发大量不同非法 ID，此时靠业务逻辑已拦不住，得靠网关或中间件级防护。
- Spring Cloud Gateway 或 Nginx 可配
limit_req，对 /user/{id} 接口按 IP 限流，比如 100 次/分钟 - 识别高频非法请求后，自动把 IP 加入 Redis 黑名单：
SET blacklist:192.168.1.100 "1" EX 3600 - Controller 中加简单统计：连续 5 次
id 就记录并告警，而不是只抛异常 - 别指望单一手段解决穿透——校验防傻，BF 防量，限流防爆，它们是层层递进的关系
最常被忽略的一点：参数校验逻辑必须和布隆过滤器的“存在定义”严格对齐。比如校验说“ID 必须是正整数”，但 BF 里存的是字符串格式的 ID，BF.EXISTS users "123" 和 BF.EXISTS users 123 可能结果不同。类型不一致，整个前置拦截就形同虚设。
