应用启动时清理指定缓存键应使用ApplicationRunner配合StringRedisTemplate.delete("key")，避免flushDb()误删全库；需匹配序列化方式，禁用耗时操作以防启动超时。
启动时清理指定缓存键
如果只是想在应用启动后立刻删掉几个已知的缓存键（比如 userCache、configCache），用 ApplicationRunner 最直接可靠：
- 必须用
StringRedisTemplate或RedisTemplate的delete方法，不能用flushDb()—— 后者会清空整个 DB，连其他服务共用的缓存也一并干掉 -
StringRedisTemplate.delete("key")只能删字符串类型键；若缓存是对象序列化存的（比如用RedisTemplate<string object></string>），得用对应类型的RedisTemplate实例，否则可能删不掉或报SerializationException - 别在
run()里写耗时操作（比如遍历大量 key），否则会拖慢启动，甚至触发 Spring Boot 的启动超时（默认 60 秒）
运行时批量删除匹配前缀的缓存
日常运维中更常见的是按业务前缀清理，比如删掉所有以 user: 开头的缓存，而不是全库扫荡：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
redisTemplate.keys("user:*")获取匹配 key 列表，再逐个delete—— 注意：该方法在 Redis 4.0+ 且数据量大时会阻塞主线程，生产环境慎用 - 更稳妥的做法是改用
redisTemplate.getConnectionFactory().getConnection().scan(...)配合游标分批扫描，避免单次请求压垮 Redis - 确保你存缓存时用的是同一个
RedisTemplate实例（比如都用RedisTemplate<string object></string>），否则keys()可能查不到某些 key ——StringRedisTemplate和RedisTemplate序列化方式不同，key 名实际存储格式不一致
清空整个 Redis 数据库的风险与替代方案
直接执行 flushDb() 看似简单，但实际非常危险：
-
redisTemplate.getConnectionFactory().getConnection().flushDb()是最接近原生命令的调用，但它不区分命名空间，删的是当前 DB 下全部数据 - 如果你的应用和别的服务共享一个 Redis 实例（哪怕只用 DB 0），这个操作等于给所有人“断电”
- 真正需要全清的场景（如测试环境重置），优先考虑换用独立 Redis 实例，或改用
FLUSHALL前先确认连接池指向的是隔离环境 - 开发阶段可加开关控制：比如配置项
redis.clear-on-start=false，默认关闭，上线前人工确认再打开
缓存清理逻辑该放在哪一层？
别把清理逻辑散落在 Controller 里，容易失控：
- 高频、确定性清理（如更新用户信息后删
user:{id}）应封装进 Service 方法，配合@CacheEvict注解自动触发 - 低频、管理型操作（如后台手动清缓存）建议单独建
CacheAdminService，统一处理前缀匹配、分页扫描、日志记录 - 绝对不要在实体类或 DTO 里写
redisTemplate.delete(...)—— 缓存操作和领域模型耦合，后续换缓存中间件时会哭 - 如果用了 Spring Cache 抽象（
@Cacheable等），清理优先走CacheManager.getCache("xxx").clear()，它会适配底层实现，比直连 Redis 模板更安全
