spring boot中@cacheable不支持动态过期时间，因spring cache抽象层仅支持全局ttl配置；需通过redistemplate手动设expire、多cachemanager配置或自定义rediscachewriter实现差异化ttl。
Spring Boot里@Cacheable默认不支持动态过期时间
Spring Cache抽象层本身没提供按key或条件设置不同TTL的能力，@Cacheable的cacheManager背后如果是RedisCacheManager，它只认全局统一的ttl配置。你写@Cacheable(cacheNames = "user", key = "#id")，哪怕加unless或condition，也改不了过期时间。
常见错误现象：@Cacheable加了timeToLive属性？编译直接报错——这个属性根本不存在于Spring原生注解中。
- 真正起作用的是
RedisCacheConfiguration里配置的entryTtl - 所有缓存操作走同一个
RedisCache实例时，TTL必然一致 - 想让
"user:123"过期2小时、"user:456"过期5分钟？必须绕开默认缓存管理器
用RedisTemplate手动设EXPIRE是最可控的方式
跳过Spring Cache抽象，直接用RedisTemplate写入+设过期，能精确到每个key。适合对缓存生命周期有强业务语义的场景，比如登录token、临时验证码、用户个性化配置。
关键不是“能不能”，而是“要不要承担多一层维护成本”：你得自己处理序列化、空值逻辑、缓存穿透防护，Spring Cache帮你兜底的部分全得自己补。
- 别用
StringRedisTemplate.opsForValue().set(key, value, duration, TimeUnit.SECONDS)——它底层调的是SETEX，无法复用已存在的key（会覆盖） - 正确姿势是分两步：
redisTemplate.opsForValue().set(key, value)+redisTemplate.expire(key, duration, TimeUnit.SECONDS) - 注意
expire()返回false意味着key不存在，要检查写入是否成功 - 如果value是对象，确保
RedisTemplate的valueSerializer和keySerializer配对，否则读出来是乱码或null
多个缓存策略共存：按业务域配不同的RedisCacheManager
如果你真需要保留@Cacheable的便利性，又得区分TTL，唯一办法是定义多个CacheManager Bean，每个绑定独立的RedisCacheConfiguration，再用@Cacheable(cacheManager = "shortLivedCacheManager")显式指定。
这不是“高级用法”，而是Spring Cache设计上的硬约束：一个CacheManager对应一套缓存策略，包括TTL、前缀、序列化方式。
- 配置里别漏掉
cacheDefaults，否则新CacheManager会 fallback 到全局默认配置 - Bean名必须和
@Cacheable里的cacheManager参数严格一致，大小写敏感 - 每个
RedisCacheManager会创建自己的连接池，大量CacheManager可能撑高Redis连接数 - 示例配置片段：
RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofMinutes(5))→ 对应短时效缓存
RedisCacheWriter自定义是最后手段，慎用
理论上你可以实现RedisCacheWriter，在put方法里根据cacheName或key动态算TTL，但这就等于重写了Spring Data Redis的缓存写入逻辑。Spring Boot 2.6+之后RedisCacheWriter接口还拆出了writeThrough等细节，兼容性风险明显。
除非你已经在维护一个高度定制化的缓存中间件，否则没必要碰这一层。90%的所谓“动态TTL需求”，用前三个方案中的某一个就能干净解决。
- 自定义
RedisCacheWriter后，@CacheEvict、@CachePut行为可能和预期不一致，得全链路测试 - Spring Boot自动配置会跳过你手写的
RedisCacheWriterBean，必须显式禁用RedisCacheConfiguration - 升级Spring Boot版本时，这个类最容易因内部方法签名变更而编译失败
真正难的不是代码怎么写，是怎么在「用Spring Cache省事」和「为TTL灵活性多写几行、多配几个Bean、多担一份维护责任」之间划那条线。很多人卡在这儿，不是不会，是不确定值不值得。
