redis ip黑名单必须用set+expire分步操作而非setex，避免重复封禁重置过期时间；校验时应使用exists命令而非get防止序列化空值误判；需结合本地缓存、定时扫过期key及cidr规则动态加载保障可靠性。
Redis里设IP黑名单，过期时间必须用EXPIRE而不是SET的EX参数
直接用 SET ip:192.168.1.100 "blocked" EX 3600 看似省事，但实际会出问题：如果同一IP反复触发封禁（比如攻击重试），每次SET都会重置过期时间，导致本该解封的IP一直卡在黑名单里。真正可控的方式是先SET值，再单独调EXPIRE——这样能配合拦截器做“仅首次封禁才设过期”的判断。
常见错误现象：TTL ip:192.168.1.100 返回-1（永不过期）或远大于预期，查日志发现是并发写入时被多次SET EX覆盖了。
- 封禁逻辑里，先
SETNX ip:192.168.1.100 "blocked"，返回1才执行EXPIRE ip:192.168.1.100 3600 - 避免用
SETEX，它无法区分“新增封禁”和“刷新封禁”，而业务通常只希望首次封禁计时 - Redis 6.2+ 支持
SET ... NX EX原子命令，但Java客户端（如Lettuce）需显式启用RESP3，老项目慎用
Spring Boot拦截器里校验IP是否在Redis黑名单中，别直接用StringRedisTemplate.opsForValue().get()
用StringRedisTemplate的opsForValue().get()查IP，看似简单，但默认序列化器会把null转成字符串"null"，导致if (result != null)永远为true——你得手动判空字符串，还容易漏掉连接超时、Redis宕机等异常分支，结果放行恶意请求。
使用场景：高频访问接口（如登录、短信发送）的前置校验，QPS > 500时明显暴露性能瓶颈。
立即学习“Java免费学习笔记（深入）”；
- 改用
redisTemplate.execute()配RedisCallback，直接走原生exists命令，不反序列化值（只要判断存在性） - 加一层本地缓存（如Caffeine），设置短过期（60s）+ 异步刷新，防Redis抖动导致全量穿透
- 务必捕获
RedisConnectionFailureException，降级策略设为“放行”，别让Redis故障拖垮整个Web层
自动解封不能只靠Redis过期，得加定时任务兜底
Redis key过期是被动删除，内存里可能积压大量已过期但未被清理的key（尤其用了惰性删除+定期删除混合策略时）。某次大促后发现KEYS ip:*扫出2W+“理论上已过期”的IP，其中37%仍能被EXISTS命中——说明过期没及时生效。
性能影响：纯依赖Redis过期，监控里expired_keys指标波动剧烈，且无法精确控制解封时刻（比如要求整点解封）。
- 用
@Scheduled(fixedDelay = 60000)每分钟扫一次SCAN匹配ip:*，对TTL ≤ 0的key执行DEL - SCAN要分页（
COUNT 100），避免单次阻塞；生产环境KEY数量超10万时，改用Redis Lua脚本批量处理 - 记录解封日志到ELK，字段包含IP、原始封禁时间、实际解封时间，方便审计“封禁是否准时”
封禁规则动态更新时，拦截器里的IP校验要避开正则硬编码
有人把黑名单IP段写成"192\.168\.\d+\.\d+"放在拦截器里，结果运维加了个10.0.0.0/8网段，代码就得发版——这违背了“配置驱动”的基本前提。
容易踩的坑：从Redis读取的规则字符串，未经校验直接传给Pattern.compile()，遇到非法正则（如[a-z{）会导致拦截器初始化失败，整个应用启动不了。
- 规则统一存Redis Hash：
HSET ip_rules cidr_10_0_0_0 "10.0.0.0/8"，拦截器用HGETALL ip_rules加载到ConcurrentHashMap - IP匹配优先用
org.apache.commons.net.util.SubnetUtils处理CIDR，比正则更准、更快、不抛异常 - 加个
@PostConstruct方法，在启动时预编译所有正则（如有），失败则打印warn并跳过该条规则，不中断启动
复杂点在于封禁动作本身要可追溯：每次DEL操作前，最好用GET ip:xxx取原始封禁原因（比如"login_fail_5times"），连同时间戳记进审计表——不然运维根本没法区分是自动解封还是人工清除。
