手写@ApiCache注解：基于AOP与Redis实现接口缓存非侵入式改造

1. 为什么不能直接在每个接口里手写缓存代码：存量系统的困境

先把场景说清楚。去年我接手一个运营后台系统，接口 RT 从几十毫秒一路飙到两秒，数据库连接池被打满，DBA 半夜给我发截图——慢查询列表里一眼望过去全是那几个高频查询。业务方催得急，开发周期又短，最直接的办法当然是加缓存。但问题来了：这个项目是老代码，Service 层逻辑写得七零八落，有的接口还夹着各种第三方调用，你让我一个个去改方法内部逻辑塞缓存代码，风险极大。

很多人第一反应是"那就用 Spring Cache 啊，@Cacheable 码上加码"。Spring Cache 确实是个好东西，但它处理不了我们这里的几个实际问题：一是缓存过期时间不够灵活，不同接口需要不同 TTL；二是 key 前缀散乱，想按业务维度统一管理很费劲；三是缓存不可用时不能直接拖垮主流程，需要降级处理。所以我当时选了一条折中路线：自己做一个轻量注解，专门给存量接口"贴标签"，让缓存逻辑和业务逻辑彻底分离。

这个方案的核心价值就三个字：非侵入。原有的方法签名不动，业务代码不动，只需要在方法上增加一个注解，缓存逻辑由统一切面处理。对团队来说，新成员上手也快——不用理解每个接口内部怎么写的，只看注解就知道有没有缓存、缓存多久。这种做法非常适合"给现有接口加缓存"这类改造场景，而不是从零开始的新项目。

2. 注解缓存背后的关键机制：AOP 代理与缓存抽象

2.1 Spring Cache 是原理样板，但不是最终答案

要理解自定义缓存注解，先要搞清楚 Spring Cache 是怎么实现的。@Cacheable 之所以能被"感知"，靠的是 Spring AOP 动态代理。容器里注册的 Bean 在初始化阶段会生成一个代理对象，外部调用方法时经过代理，代理在方法执行前检查缓存，命中就直接返回，没命中才执行真实方法，再把返回值放进缓存。整个过程对业务代码完全透明。

明白了这个原理，你就能理解为什么"直接调方法内部"绕开了缓存——代理只对"外部调用"有效。

Spring Cache 其实已经帮我解决了一部分问题：CacheManager 抽象、CacheInterceptor、KeyGenerator、Condition/Unless 表达式解析。但我最终没有直接用它，原因很现实：它的一些默认行为在存量系统改造里不好控制。比如缓存空值需要额外配置，缓存名的粒度粗，TTL 只能按 CacheManager 级别统一设置，代码里一旦用了 @Cacheable(cacheNames="user", key="#userId")，想单独给某个方法设置 10 秒、给另一个方法设置 30 分钟，就很别扭。Spring Boot 2.x 之后虽然可以用 CacheManagerCustomizer 做个性化配置，但配置代码一点都不少，还不如自己做一个切面，想怎么控制就怎么控制。

2.2 代理模式与注解生效的前提条件

这里必须强调一个概念：Spring 容器中的代理机制。Spring Boot 默认开启 CGLIB 代理（spring.aop.proxy-target-class=true），也就是说被代理类会生成一个子类，子类重写目标方法，在方法前后插入拦截逻辑。这个子类是被 Spring 管理的，而你在 @Service 类内部用 this.xxx() 调用，走的是原始对象的方法，不是代理对象的方法——所以注解失效。

还有一点：要求方法必须是 public 的。CGLIB 对 protected 和 private 方法的处理很有限，注解处理器不一定拦得到。所以我给出的方案里，强制要求加缓存注解的方法必须是 public，调用方必须通过 Spring Bean 注入。

code复制调用链路示例：

外部调用 -> Spring代理对象 -> 缓存切面(ApiCacheAspect) -> 真实方法

如果外部调用 -> 真实对象，则切面不参与，注解不生效

2.3 缓存抽象层：CacheManager 与 Cache

我在自定义注解的时候，复用了 Spring 缓存抽象，但把实现简化了。核心就三样东西：

• CacheManager：管理多个 Cache，可以通过 getCache("userCache") 获取指定缓存。
• Cache：一个命名的存储桶，可以往里放 key/value，也可以取、删。
• Cache.ValueWrapper：取缓存时的包装类，避免缓存值本身为 null 时无法区分"有缓存但值是 null"和"没有缓存"。

我自己做注解的时候，没有直接用 CacheManager，而是直接操作 StringRedisTemplate。因为我要处理的是 Redis 缓存，而 Redis 的操作远比 Cache 接口的 get/put 丰富：可以设置过期时间、可以做增量操作、可以模糊删除。如果你只需要本地缓存，可以用 CacheManager 来适配；但如果对接 Redis，直接操作 RedisTemplate 反而灵活得多。

3. 手写一个可落地的 @ApiCache 注解：从参数设计到切面实现

3.1 注解参数设计：要满足什么场景

动手写注解前，先想清楚需要哪些配置项。我总结下来，一个能应对存量系统的接口缓存注解，至少要支持以下参数：

key 设计是最重要的。缓存 key 粒度太粗会被不同参数互相覆盖，太细则缓存命中率低下。我推荐的做法是：方法全限定名 + 业务唯一标识。比如 getUserById 方法，key 可以写成 "user:getUserById:" + #id，用一个统一前缀区分不同系统。前缀最好在注解里别写死，通过配置中心下发，方便以后迁移 Redis 集群时批量改 key。

3.2 注解定义与切面完整实现

先看注解定义：

java复制@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ApiCache {

    /** 缓存分区名称，默认 api */
    String cacheName() default "api";

    /** 动态 key，支持 SpEL 表达式，如 "#id"、"'user:' + #user.id" */
    String key() default "";

    /** 过期时间数值，默认 300 */
    long ttl() default 300L;

    /** 过期时间单位，默认秒 */
    TimeUnit unit() default TimeUnit.SECONDS;

    /** 是否缓存空值，默认 true，防止缓存穿透 */
    boolean cacheEmpty() default true;

    /** 满足条件才缓存，SpEL 表达式，为空则始终缓存 */
    String condition() default "";
}

然后是核心的切面类。我用 @Around 环绕通知，这样可以在方法执行前后做完整控制：

java复制@Aspect
@Component
public class ApiCacheAspect {

    private static final StringRedisTemplate redisTemplate;
    private static final ObjectMapper objectMapper;

    // 构造注入略

    @Around("@annotation(apiCache)")
    public Object around(ProceedingJoinPoint pjp, ApiCache apiCache) throws Throwable {
        // 1. 解析 condition，不满足直接放行
        if (!conditionPassed(apiCache.condition(), pjp)) {
            return pjp.proceed();
        }

        // 2. 生成缓存 key
        String cacheKey = buildCacheKey(pjp, apiCache);

        // 3. 查缓存
        String cachedValue = redisTemplate.opsForValue().get(cacheKey);
        if (cachedValue != null) {
            // 处理空值占位符
            if (NULL_PLACEHOLDER.equals(cachedValue)) {
                return null;
            }
            // 反序列化为方法返回类型
            MethodSignature signature = (MethodSignature) pjp.getSignature();
            Class<?> returnType = signature.getReturnType();
            return objectMapper.readValue(cachedValue, returnType);
        }

        // 4. 执行真实方法
        Object result = pjp.proceed();

        // 5. 写缓存
        if (shouldCache(result, apiCache.cacheEmpty())) {
            String value = objectMapper.writeValueAsString(result);
            long ttl = apiCache.unit().toSeconds(apiCache.ttl());
            redisTemplate.opsForValue().set(cacheKey, value, ttl, TimeUnit.SECONDS);
        }

        return result;
    }
}

这段代码是最简版本，实际项目里还需要处理几件事：泛型返回类型的反序列化、方法抛异常时不要写缓存、Redis 连接异常时降级（catch 住异常直接放行）。这些我放在第 5 章展开。

3.3 SpEL 参数的解析与 Key 生成

key 参数支持 SpEL，这是让注解具备通用性的关键。用户可以在注解里写 "#userId"，切面通过方法参数名解析出实际值。Spring 默认在编译时不会保留参数名，所以建议在 pom.xml 里加上 -parameters 编译参数，否则就得通过 DefaultParameterNameDiscoverer 来拿。下面这段代码是通用的 SpEL 解析模板：

java复制private String buildCacheKey(ProceedingJoinPoint pjp, ApiCache apiCache) {
    MethodSignature signature = (MethodSignature) pjp.getSignature();
    Method method = signature.getMethod();
    Object[] args = pjp.getArgs();
    String[] paramNames = parameterNameDiscoverer.getParameterNames(method);

    EvaluationContext context = new StandardEvaluationContext();
    for (int i = 0; i < paramNames.length; i++) {
        context.setVariable(paramNames[i], args[i]);
        // 也支持 pjp.getArgs()[0] 这种方式
        context.setVariable("p" + i, args[i]);
    }

    String keySpel = apiCache.key();
    String keyPart = StringUtils.hasText(keySpel)
            ? parser.parseExpression(keySpel).getValue(context, String.class)
            : signature.getDeclaringTypeName() + "." + method.getName() + ":" + Arrays.toString(args);

    return apiCache.cacheName() + ":" + keyPart;
}

这里有个小细节：如果 key 表达式解析出来是 null，或者用户没写 key，我采用方法全限定名加参数列表兜底。这样不会因为漏写 key 导致缓存互相覆盖。

3.4 为什么自定义注解而不是直接用 Spring Cache

总结一下我选择自定义注解而非 Sprig Cache 的几个理由：

第一，控制粒度。Spring Cache 的 TTL 在 RedisCacheManager 里配置，通常是按 cacheName 配置一组，虽然能配，但要给每个方法单独设置 TTL 还是麻烦。自定义注解把 TTL 放在方法上，一眼就能看出这个接口缓存多久。

第二，业务落地友好。存量系统里很多接口返回的是 Map<String, Object>、List<Object> 这类类型，Spring Cache 默认的 JDK 序列化存进 Redis 后，类结构一变就反序列化失败。自定义切面直接用 JSON 序列化，兼容性好很多。

第三，监控和降级可控。我可以在切面里加埋点，统计缓存命中率、Redis 平均耗时，Redis 挂了还能静默放行，保证主链路不受影响。这些逻辑塞进 Spring Cache 的拦截器里就只能靠扩展点，写起来非常绕。

4. 把注解接到 Redis：缓存配置、序列化与 TTL 策略

4.1 基础设施准备：依赖与连接配置

既然要落地到 Redis，先把基础配置做完。项目是 Spring Boot，pom 里加依赖：

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-pool2</artifactId>
</dependency>

yml 配置：

yaml复制spring:
  data:
    redis:
      host: your-redis-host
      port: 6379
      password: your-password
      lettuce:
        pool:
          max-active: 50
          max-idle: 20
          min-idle: 5
          max-wait: 3000ms

注意 Spring Boot 2.x 以后默认客户端是 Lettuce，不是 Jedis。Lettuce 是 Netty 实现的，连接复用比 Jedis 好，线程安全，但它的连接池语义和 Jedis 不完全一样。你只要知道：通过连接池拿连接执行命令，用完归还，就行了。

4.2 自定义 RedisTemplate：序列化问题必须处理

直接用 Spring Boot 自动配置的 RedisTemplate 有一个大坑：key 的默认序列化器是 JdkSerializationRedisSerializer，value 也是。这意味着你在 Redis 客户端里看到的 key 是一长串乱码，value 是二进制对象。更要命的是，JDK 序列化后的对象如果类结构变了（比如加了个字段、改了包名），反序列化直接抛异常。对于接口缓存这种长期存储的数据，JDK 序列化是灾难。

我自己的项目中统一这样配置：

java复制@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, String> stringRedisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, String> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        StringRedisSerializer stringSerializer = new StringRedisSerializer();
        template.setKeySerializer(stringSerializer);
        template.setHashKeySerializer(stringSerializer);
        template.setValueSerializer(stringSerializer);
        template.setHashValueSerializer(stringSerializer);
        return template;
    }
}

把 value 也设置成 String 序列化，存进去的就是纯字符串或 JSON 字符串。这样在 Redis 里可以直接看到缓存内容，排查问题方便很多。对应的，我在切面里用 ObjectMapper 做对象和 JSON 字符串的互转。

4.3 TTL 策略：缓存雪崩的预防要提前做

不同接口对数据时效性的要求差别很大。比如用户基础信息的缓存可以放 30 分钟，而某个库存接口只能缓存 10 秒。我在注解参数里设计了 ttl 和 unit，就是为了让开发人员按接口实际情况调整。

但这里有一个非常隐蔽的问题：如果多个热点数据同时过期，Redis 会在同一时间收到大量删除操作，数据库瞬间压力飙升，这就是缓存雪崩。预防手段很简单：在注解默认的 TTL 上再加一个随机偏移量。我在切面里没有直接用 apiCache.ttl()，而是加上了一个随机秒数：

java复制long ttlSeconds = apiCache.unit().toSeconds(apiCache.ttl());
// 默认加 0~60 秒的随机偏移，避免大量 key 同时过期
long finalTtl = ttlSeconds + ThreadLocalRandom.current().nextLong(60);

这样做有个副作用：缓存实际的过期时间比注解上写的 TTL 多了最多 60 秒。如果业务对时间敏感，可以把随机范围做成注解的一个可选参数 randomTtlRange，默认 60，高级用法按需调整。

4.4 缓存穿透防护：空值缓存和布隆过滤器

线上经常出现一种情况：攻击者或异常请求来查一个根本不存在的 key，比如 userId = -1。每次查询都会打到数据库，而数据库查不到，缓存也就没法写，DB 压力只增不减。这就是缓存穿透。

我的 cacheEmpty 参数就是干这个用的。当方法返回值是 null 时，按布尔值决定是否写缓存。写的时候用占位符：

java复制private static final String NULL_PLACEHOLDER = "NULL_CACHE";

if (result == null && apiCache.cacheEmpty()) {
    redisTemplate.opsForValue().set(cacheKey, NULL_PLACEHOLDER, ttl, TimeUnit.SECONDS);
}

注意写的是占位符字符串，不是直接写 "null"。如果网上有人教你把 JSON 序列化结果 "null" 写进去，后续取出来仍然要解析，而且 if (value != null) 永远成立，处理起来容易混淆。用专用占位符，一眼就能看出这是"空值缓存"，取到就直接返回 null。

如果空值量太大、占满 Redis，就要考虑布隆过滤器，在切面里先判断 key 是否可能存在问题。但布隆过滤器需要单独预热，存量系统改造时不一定能快速接入，所以我通常是先开空值缓存，等到空 key 数量超阈值再加布隆过滤器。

5. 真实项目里的翻车现场：缓存失效、自调用与一致性排查

5.1 注解失效场景：为什么切面没生效

我在把这个注解推给团队时，第一个同事就踩了坑。他在 Service 内部调用了一个加了 @ApiCache 的方法：

java复制@Service
public class OrderService {

    public Order getOrder(String orderId) {
        // 直接 this 调用，注解失效
        return this.getOrderFromDb(orderId);
    }

    @ApiCache(key = "#orderId", ttl = 30)
    public Order getOrderFromDb(String orderId) {
        // 查询数据库
    }
}

为什么失效？前面说过，Spring 的代理对象是容器里那个被注入的 Bean。外部调用 orderService.getOrder 时，走的是代理对象；但 this.getOrderFromDb() 中的 this 是原始对象，不是代理对象，所以里层方法上的注解根本没机会被拦截。

解决方案有几种：第一，把方法拆到另一个 Service，通过注入调用；第二，使用 AopContext.currentProxy() 获取当前代理对象（需要开启 @EnableAspectJAutoProxy(exposeProxy = true)）；第三，把缓存注解放到 Controller 层或者 Facade 层。我个人的习惯是放在最外层接口类上，这样业务内部无论如何调用都不会绕开代理。

还有一个低级但常见的坑：注解所在的类没有被 Spring 容器管理。比如类上没加 @Service、@Component 等，写了个 new OrderService() 手动创建，代理自然就不存在。检查顺序：类是否被容器管理 -> 方法是否是 public -> 调用方是否是外部引用。

5.2 事务与缓存注解之间的顺序问题

另一个高频问题来自 @Transactional 和 @ApiCache 同时使用。假设这样一个场景：

java复制@ApiCache(key = "#id", ttl = 30)
@Transactional(rollbackFor = Exception.class)
public User updateUser(Long id, String name) {
    userDao.updateName(id, name);
    return userDao.selectById(id);
}

如果先进入缓存切面，执行方法体后把返回值写进缓存，然后事务提交——一切正常。但如果缓存切面在最外层，事务切面在内层，事务尚未提交，缓存层就写入了数据。这时候如果事务后来回滚了，Redis 里的是脏数据，后续请求拿到的数据就和数据库不一致了。

解决思路：让缓存切面在事务的最外层，也就是"先写缓存、再提交事务"要改成"事务提交成功后再写缓存"。

但 Spring 切面的执行顺序不好精确控制。我后来采用了一个更稳妥的方案：不在更新方法上加缓存注解，而是让更新方法主动删除对应的缓存 key。这就是标准的 Cache Aside 模式：

java复制@Transactional(rollbackFor = Exception.class)
public User updateUser(Long id, String name) {
    userDao.updateName(id, name);
    // 事务提交后删除缓存
    TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
        @Override
        public void afterCommit() {
            redisTemplate.delete("user:" + id);
        }
    });
    return userDao.selectById(id);
}

这样设计的好处是：更新逻辑里不用关心缓存怎么回填，只负责失效；查询接口的 @ApiCache 在下次查询时自动回填新数据。代码清晰，一致性也相对有保障。

5.3 缓存击穿与热点 Key 重建的暴力解法

缓存击穿说的是一个热点 key 在过期瞬间有大量请求同时打到数据库重建缓存。普通的缓存方案解决不了这个问题，因为大家都发现缓存过期了，就都去执行方法了。

我在切面里加了一个可选的互斥锁方案。当缓存 miss 后，先尝试获取 Redis 分布式锁，拿到锁的线程执行真实方法并写缓存，其他线程则短暂等待后继续查缓存。

java复制// 缓存 miss 后：
String lockKey = cacheKey + ":LOCK";
Boolean locked = redisTemplate.opsForValue().setIfAbsent(lockKey, "1", 5, TimeUnit.SECONDS);

if (Boolean.TRUE.equals(locked)) {
    try {
        Object result = pjp.proceed();
        redisTemplate.opsForValue().set(cacheKey, objectMapper.writeValueAsString(result), ttl, TimeUnit.SECONDS);
        return result;
    } finally {
        redisTemplate.delete(lockKey);
    }
} else {
    // 其他线程短暂等待后重查缓存
    Thread.sleep(50);
    String cached = redisTemplate.opsForValue().get(cacheKey);
    if (cached != null) {
        return objectMapper.readValue(cached, returnType);
    }
}

这个方案牺牲了一点并发性能，但保证了热点 key 重建时只有一个请求打到数据库。对于读多写少、数据量大的接口，实测下来非常有效。如果你不想引入分布式锁，也可以用"逻辑过期"方案：缓存里存一个过期时间标记，后台异步刷新，但实现复杂度高一些，存量系统改造不推荐一上来就用。

5.4 Redis 不可用时的降级：缓存不能成为新的故障点

把缓存加在关键链路上，最怕的就是 Redis 挂了，接口反而比不加缓存更慢、甚至直接失败。我踩过这个坑：有次 Redis 服务主从切换，切面里没做异常处理，Redis 命令超时导致接口全部超时，业务方直接炸了。

所以我的切面里，所有 Redis 操作必须 catch 住异常：

java复制try {
    String cachedValue = redisTemplate.opsForValue().get(cacheKey);
    if (cachedValue != null) {
        // ...
    }
} catch (Exception e) {
    // 缓存不可用，直接放行，不影响主流程
    log.warn("cache get error, fallback to direct invocation", e);
    return pjp.proceed();
}

写缓存的地方也是一样。Redis 故障期间，所有请求直接走数据库，系统退回没有缓存的状态。等 Redis 恢复后，缓存会自动重新预热。这种做法是"缓存是可牺牲的"这个原则的落地：缓存是为了提升性能，而不是为了保证正确性，它不能影响主链路的可用性。

6. 把注解推广到团队前，我反复强调的几个判断标准

6.1 什么样的接口才值得加缓存

并不是所有接口都适合这个注解。我在团队里立了一个规矩：加缓存之前先回答三个问题。

第一个问题：这个接口的读写比是多大？如果读请求占比不到 70%，缓存带来的收益有限，反而增加一致性维护成本。

第二个问题：这个接口的数据量有多大？如果数据量很小，数据库本来就毫秒级返回，加缓存纯粹是增加复杂度。

第三个问题：这个接口能容忍多长时间的缓存不一致？比如订单支付状态这种接口，缓存 10 秒都嫌多；而用户头像、商品详情这类数据，缓存 5 分钟甚至更长也没有问题。在注解上把 TTL 写清楚，其实就是把业务容忍度显式化了。

6.2 缓存命中率怎么看：没有监控就别上缓存

上了缓存之后，第一件事不是看接口变快了多少，而是看命中率。Redis 的 INFO stats 命令里有 keyspace_hits 和 keyspace_misses 两个指标，命中率等于 hits / (hits + misses)。如果命中率长期低于 80%，说明 key 设计有问题，比如把用户 ID 和时间戳一起拼进 key，导致同一个用户每次请求都打到不同的 key。

我在切面里加了埋点，配合 Micrometer 上报到监控系统，指标名就叫 api_cache_hit_total 和 api_cache_miss_total。这样每个接口的命中情况一目了然，后续调优才有依据。

6.3 冷启动预热的操作思路

新上缓存接口后，刚开始命中率一定低，因为缓存里什么都没有。如果接口是核心链路（比如首页商品列表），冷启动阶段的高延迟不能忍。我的做法是写一个简单的预热脚本，在服务启动后主动调用一次接口，或者从数据库查出热点数据直接写入 Redis。

java复制@Component
public class CacheWarmer implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) {
        List<String> hotIds = queryHotIds();
        for (String id : hotIds) {
            String key = "product:" + id;
            if (Boolean.FALSE.equals(redisTemplate.hasKey(key))) {
                Product product = productMapper.selectById(id);
                redisTemplate.opsForValue().set(key, objectMapper.writeValueAsString(product), 600, TimeUnit.SECONDS);
            }
        }
    }
}

预热逻辑要幂等，重复执行不会覆盖已有缓存。我见过同事写的预热脚本每次启动都全量刷新缓存，结果把 Redis 内存和数据库连接同时打满，得不偿失。预热只针对热点数据，不需要全表扫描。

6.4 本地缓存与 Redis 二级缓存的一点思考

如果有些接口 QPS 特别高，单靠 Redis 仍然会有网络开销和序列化开销。这时候可以考虑在应用内加一层本地缓存（比如 Caffeine），形成二级缓存。但二级缓存的复杂度是几何级上升的：本地缓存的数据更新必须广播到所有实例，否则会出现各实例数据不一致的情况。我的建议是，先做好 Redis 一级缓存，命中率做到 90% 以上，如果仍然扛不住，再考虑本地缓存，而且一定要引入消息机制来做缓存失效广播。

在我的实际项目中，绝大多数接口用 Redis 一层缓存就够了。只有像用户 Token、权限配置这类每个请求都要读、且几乎不怎么变的数据，才会用本地缓存。

7. 一个很容易被忽略的动作：缓存 key 的统一约定与清理

最后说一个我认为这个方案里最具"工程感"的细节。用注解加缓存，时间一长，Redis 里的 key 会越来越多。有业务下线了，接口不要了，Redis 里还留着旧数据占空间。所以我在注解里强制要求 cacheName 必须以业务模块命名，并且和 Redis 的 key 前缀一一对应。比如订单模块统一 order:，用户模块统一 user:。

清理时按前缀批量删就行：

bash复制# redis-cli 中按前缀删除
redis-cli --scan --pattern "order:*" | xargs -L 100 redis-cli DEL

这里有一个重要提醒：线上环境千万不要用 KEYS order:* 来匹配大量 key，KEYS 命令会阻塞 Redis 单线程，生产环境直接卡住数秒。用 SCAN 命令分批扫描，虽然慢一点，但是对服务无感。

另外就是 key 的过期时间。我见过很多开发人员为了省事给所有缓存 key 都设置 1 小时，结果接口改完数据，缓存里老的键要等一小时才消失。我的建议是，宁可 TTL 偏短，也不要为了省事设置过长。缓存一旦超过业务容忍时间，脏数据影响的是用户，而不只是技术指标。

8. 我实际用下来觉得最值回票价的几个收益

这套方案上线到现在大半年，回头看我当初的决定，有几点是我觉得特别值回票价的：

第一，新接口加缓存的时间成本几乎是零。开发人员在方法上标注一行注解，就完成了缓存接入。不需要理解 Redis 有没有配置好，不需要写序列化代码，不需要关心 key 的格式。这种"无脑好用"的体验对团队推进非常有帮助。

第二，排查问题非常直观。由于 value 是 JSON 字符串，key 是有意义的前缀加业务 ID，在 Redis 客户端里一眼就能看出数据对不对。排查缓存一致性问题时，不需要再写 Java 代码来反序列化看对象内容了。

第三，因为切面统一收口，后续想加"灰度开关"、"动态 TTL"、"缓存命中率监控"都很方便。这些能力如果散落在各个业务方法里，改一处要动几十个类；在我这里，只需要改一个切面类。

如果你也在做存量接口的性能优化，我建议你别急着在 Service 里塞 redisTemplate.opsForValue() 这样的代码。花一两个小时把注解和切面搭好，后面所有接口都在收益。但要记住：缓存不是银弹，它能解决读多写少场景的性能问题，却掩盖不了数据库设计本身的缺陷。先把慢查询、大事务、全表扫描这些底子问题解决了，再谈缓存，效果会好得多。

还有一个经验之谈：加缓存这件事，一定要让业务方参与确定 TTL。技术团队觉得"缓存 5 分钟没问题"，业务方可能接受不了；反过来，业务方要求的实时性，技术团队也要理解对应的成本。把 TTL 做成注解参数，大家坐下来填一个数，比在代码里争论半天要高效得多。