simplekeygenerator会导致缓存互相覆盖，因其仅基于参数值生成key（如getuserbyid(123)和getorderbyid(123)均生成"123"），忽略类名与方法名，造成redis中key冲突；无参返回不可读的simplekey.empty，多参生成难调试的simplekey[id1,id2]，缺乏业务上下文区分。
为什么SimpleKeyGenerator会导致缓存互相覆盖
默认的 SimpleKeyGenerator 对单参数方法直接调用 toString()，比如 getUserById(123) 和 getOrderById(123) 都生成 key "123"。Redis 里 key 冲突，结果就是查用户返回了订单数据——这不是 bug，是设计如此，但生产环境不能接受。
它对无参方法返回 SimpleKey.EMPTY（一个空对象），对多参方法拼成 SimpleKey[id1,id2]，但这个字符串不可读、难调试、无法区分业务上下文。
实现 KeyGenerator 接口时 generate() 的关键处理点
重写 generate(Object target, Method method, Object... params) 时，别只拼 params.toString()，得兼顾可读性、唯一性和健壮性：
-
target.getClass().getSimpleName()比target.getClass().getName()更简洁，避免包名过长 -
method.getName()必须带上，否则同 service 下不同方法会撞 key -
params是Object[]，要遍历处理：null→"null"，数组/集合需递归或转 JSON 字符串，否则[1,2]和Arrays.asList(1,2)可能生成相同字符串 - 推荐用下划线
_分隔，不用冒号（:）或点（.），避免和 Redis 命名空间习惯冲突
示例片段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
public Object generate(Object target, Method method, Object... params) {
String className = target.getClass().getSimpleName();
String methodName = method.getName();
String paramStr = Arrays.stream(params)
.map(p -> p == null ? "null" : p instanceof Collection
? new ObjectMapper().writeValueAsString(p)
: p.toString())
.collect(Collectors.joining("_"));
return String.format("%s:%s:%s", className, methodName, paramStr);
}
注册后不生效？检查这三点
自定义 KeyGenerator 写对了，但缓存还是走默认逻辑，大概率卡在这几个地方：
- Bean 名必须是
cacheKeyGenerator（Spring Boot 2.4+ 强制要求），不是随便起名；或者加@Primary显式标记 -
@EnableCaching所在配置类，必须能被@ComponentScan扫到——如果 KeyGenerator 定义在com.example.util，而启动类只扫com.example.app，那就找不到 - 如果你手动构建了
RedisCacheConfiguration，比如调用了.keyPrefix("xxx")或.computePrefixWith(...)，那KeyGenerator就完全不参与 key 生成，此时 key 由 prefix + 方法参数决定，跟你的generate()方法无关
@Cacheable 中用 SpEL 自定义 key 和 KeyGenerator 的关系
两者互斥：@Cacheable(key = "#id + '_' + #type") 会跳过 KeyGenerator，直接走 SpEL 解析；没写 key 属性时才用 KeyGenerator。
所以混用时容易误判：
- 全局想统一风格？删掉所有
key=，只靠KeyGenerator - 个别方法要特殊处理？保留
keySpEL，其他走默认生成器 - 注意 SpEL 里
#p0表示第一个参数，#root.methodName可取方法名，但不如KeyGenerator灵活（比如没法取 class 简称）
真正麻烦的不是写代码，而是搞清「谁在什么时候生成 key」——KeyGenerator、SpEL、keyPrefix、序列化方式，四者叠加时，优先级和生效条件得一个个验证。
