Redis里那些自定义注解，灵活用起来其实没那么难讲究不少细节

（引用来源：主要基于日常开发中基于Spring Boot和Spring Data Redis框架使用缓存注解的常见实践与问题总结）

说到在项目里用Redis,很多人一开始可能就是手动调那个RedisTemplate，get、set一通写，后来发现，Spring提供了几个现成的缓存注解，像@Cacheable、@CacheEvict，用起来挺方便，感觉一下子从手工时代进入了自动化时代，但用着用着就发现，光会用这几个基本的注解，好像还不够，业务复杂起来，一些特殊的缓存需求，或者想更精细地控制缓存行为的时候，就有点力不从心了，这时候，就得琢磨着怎么把自定义注解给灵活用起来，其实这事儿说难也不难，但里面的细节确实不少，讲究也挺多。

首先得明白,为啥要用自定义注解？说白了，就是为了“偷懒”和“整齐”，你有一个特别复杂的缓存逻辑：可能要根据不同的用户类型，缓存不同的时间；或者一个数据更新了，需要同时清理掉五六个关联的缓存键，如果你每次都在方法上面写一长串的@Cacheable加上各种条件表达式（SPEL），或者堆上好几个@CacheEvict，那代码看起来就太乱了，而且容易写错，这时候，你就可以自己定义一个注解，比如叫@UserTypeCache，或者@ComplexEvict，把这些重复的、复杂的配置都封装在这个自定义注解里面，以后用到的地方，只需要简单地标上这个自定义注解就行了，代码瞬间清爽，维护起来也方便，改逻辑只需要改注解定义的那一个地方。

那具体怎么实现一个自定义注解呢？其实就是一个“套娃”的过程，核心是使用Spring的@AliasFor注解和元注解机制，你想创建一个@HotDataCache注解，它本质上还是@Cacheable，但预设了一些参数，你可以这样写：

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Cacheable(cacheNames = "hotData", key = "#id", unless = "#result == null") // 这里是预设的固定值
public @interface HotDataCache {
    // 你可以用@AliasFor，让自定义注解的某些属性“映射”到内部的@Cacheable注解上
    @AliasFor(annotation = Cacheable.class, attribute = "key")
    String key() default "#id";
    @AliasFor(annotation = Cacheable.class, attribute = "cacheNames")
    String[] cacheNames() default "hotData";
}

这样,你平时用@Cacheable(cacheNames="hotData", key="#id", unless="#result == null")，现在只需要写@HotDataCache就行了，如果某个特殊场景下key的计算方式不一样，你还可以覆盖掉默认值，HotDataCache(key = "#userId + ':profile'")，你看，这样既有了默认配置的便捷，又保留了灵活性，这就是自定义注解的第一个大好处：封装通用配置，简化代码。

光会封装还不够,更高级的用法是处理那些“组合操作”，这是最讲究细节的地方，有一个经典的场景：更新用户信息，更新成功后，你不仅要清除旧的用户缓存（key可能是"user::1"），可能还要清除一个用户列表的缓存（key是"userList"），用默认的注解，你可能得在更新方法上写两个@CacheEvict：

@CacheEvict(key = "'user:' + #user.id")
@CacheEvict(key = "'userList'")
public User updateUser(User user) { ... }

这看起来还行,但如果这种“更新一个，清除多个”的模式在好几个地方都用得到呢？每次都写两行，又啰嗦又容易遗漏，这时候，自定义注解的威力就显现了，我们可以定义一个@UserUpdateCacheEvict注解：

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@CacheEvict(key = "'user:' + #user.id") // 清除单个用户缓存
@CacheEvict(key = "'userList'") // 清除用户列表缓存
public @interface UserUpdateCacheEvict {
}

更新方法上直接一个@UserUpdateCacheEvict就搞定了，语义清晰，一劳永逸，这种基于多个元注解的组合，是自定义注解解决复杂缓存场景的利器，再比如，你可以组合@CacheEvict和@CachePut，实现一些更特殊的缓存更新策略。

第三个要讲究的细节,是关于缓存条件（condition和unless）的灵活运用，在自定义注解里，你可以预设一些复杂的判断逻辑，你只想缓存金额大于100元的订单，或者只缓存状态为成功的操作结果，你可以把这样的条件判断写在自定义注解的condition或unless属性里，但这里有个坑，就是SPEL表达式的上下文，在自定义注解里写SPEL，要清楚地知道能引用哪些变量，result（方法返回值）、#p0或#a0（第一个参数）、#root.methodName（方法名）等，如果表达式写错了，缓存可能就不生效，而且排查起来还挺麻烦，定义的时候一定要测试充分。

还有一个容易被忽略的细节是注解的继承性，如果你把一个缓存注解标在类上，是希望这个类里所有的方法都应用这个缓存规则吗？或者，如果一个方法上既有类级别的缓存注解，又有方法级别的，谁会覆盖谁？Spring的缓存注解默认是不继承的，方法上的注解会完全覆盖类上的，但通过自定义注解，你可以设计更复杂的逻辑，不过这通常需要更深入地理解Spring的缓存抽象机制，有时候甚至需要自己实现一些切面逻辑来配合，这就涉及到更深的层次了。

想说的是,自定义缓存注解虽然灵活强大，但也不能滥用，它的目的是让代码更清晰、更易于维护，而不是增加复杂度，如果业务逻辑很简单，直接用标准的@Cacheable、@CacheEvict就足够了，只有当标准注解用起来很别扭、重复代码太多，或者缓存逻辑确实很复杂时，才考虑祭出自定义注解这个法宝，在团队中使用时，一定要做好文档说明，让大家都能理解每个自定义注解的含义和用途，否则反而会变成维护的噩梦。

把Redis的自定义注解灵活用起来,关键就在于理解“封装”和“组合”这两个核心思想，同时细心处理好SPEL表达式、注解属性映射等细节，一旦掌握了，你就会发现，管理复杂的缓存策略也能变得优雅而轻松。