Java中无法直接通过@Cacheable原生支持“缓存过期+穿透查库重建”，需结合Spring Cache、自定义注解、AOP及Redis/Caffeine实现：配置TTL、利用@Cacheable自动穿透查询、防空值穿透、动态TTL及分布式锁防雪崩。
Java 中无法直接通过标准注解（如 @Cacheable）原生支持“缓存过期时间 + 缓存未命中时 JDBC 穿透查库并重建缓存”的完整流程。Spring Cache 的注解是声明式缓存抽象，本身不控制过期策略细节，也不内置穿透查询逻辑。但你可以结合 Spring Cache、自定义注解、AOP 和缓存组件（如 Redis + Caffeine）来实现这一目标。
用 @Cacheable 配合 TTL 实现基础缓存与过期
Spring 自身的 @Cacheable 不支持为每个 key 设置独立过期时间，但底层缓存实现（如 Redis 或 Caffeine）可以支持。你需要：
- 选用支持 TTL 的缓存管理器（如
RedisCacheManager或CaffeineCacheManager） - 为缓存配置统一 TTL（例如所有
user:开头的 key 过期 10 分钟） - 注意：Spring 默认不把方法参数自动转成带 TTL 的 key，需自定义
CacheResolver或KeyGenerator
示例（Redis + 自定义 cache manager）：
（配置类中）RedisCacheConfiguration 可设置默认过期时间：
立即学习“Java免费学习笔记（深入）”；
RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(10)); // 所有缓存项 10 分钟后过期
缓存未命中时自动 JDBC 查询并写入缓存（穿透处理）
Spring 的 @Cacheable 在 miss 时会执行方法体，并将返回值写入缓存——这天然就是“穿透查询 + 写缓存”的行为。关键在于确保你的业务方法本身做了 JDBC 查询：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 方法上加
@Cacheable(cacheNames = "users", key = "#id") - 方法体内直接调用
JdbcTemplate.queryForObject(...)或 MyBatis Mapper 查询 MySQL - 查询结果非 null 时自动缓存；若查不到，可返回 null 或抛异常，由上层决定是否缓存空值（防穿透）
⚠️ 注意：若数据库查不到（空结果），默认不会缓存 null，可能引发缓存穿透。建议配合 @Cacheable(..., unless = "#result == null") 或手动缓存空对象（布隆过滤器 + 空值缓存更佳）。
进阶：用自定义注解支持 per-key 动态过期时间
如果不同数据需要不同 TTL（比如用户信息 30 分钟，配置项 24 小时），标准注解不够用。可自定义注解（如 @CachedWithTTL）+ AOP 实现：
- 定义注解，含
ttlSeconds()属性 - AOP 切面拦截该注解，先尝试从 Redis 按 key 读缓存（带 TTL 检查）
- 若缓存不存在或已过期，则执行原方法（JDBC 查询），再将结果以指定 TTL 写回 Redis
- 避免重复查询：可用 Redis 的
SET key value EX ttl NX原子操作防击穿
这种方案绕过了 Spring Cache 抽象，更灵活，也更贴近你描述的“精确控制过期 + 穿透重建”语义。
推荐技术栈组合
落地时建议搭配使用：
- 本地缓存：Caffeine（高性能、支持 expireAfterWrite、自动刷新）用于高频低变更数据
- 分布式缓存：Redis（支持 setex、lua 原子操作、发布订阅）用于多实例共享场景
- 穿透防护：查询前先查布隆过滤器（或缓存空值 + 随机过期时间）
- 刷新机制：配合 MySQL binlog（如 Canal）或应用内事件，异步更新缓存，而非纯被动穿透
不复杂但容易忽略：缓存重建过程要加锁（如 Redis 分布式锁），否则高并发下多个线程同时穿透查库，造成雪崩。
