redisexception转cacheexception时需手动注入key，因原异常不携带该信息；key须从缓存操作参数中显式提取并传递，再通过异常消息或自定义异常字段携带，最后在日志与监控中有效利用。
在将 RedisException 转译为 Spring 的 CacheException 时，原生异常本身不携带 key 信息，需要手动提取并注入到新异常中。关键在于：**key 通常来自业务上下文（如缓存操作参数），而非 Redis 异常对象本身，必须在捕获异常前或捕获时显式保留**。
从缓存操作参数中提取 key
Spring Cache 抽象层（如 RedisCache）执行操作时，key 是明确传入的。在自定义异常处理逻辑中，应在调用 Redis 操作前记录或传递 key：
- 若使用
@Cacheable/@CachePut等注解，key 由 SpEL 表达式生成，可在切面（@Around）中通过ProceedingJoinPoint获取方法参数，并结合CacheOperationInvocationContext解析出实际 key 值 - 若直接调用
RedisTemplate或StringRedisTemplate，key 就是方法调用时传入的参数（如redisTemplate.opsForValue().get("user:1001")），应在try-catch块外持有该 key 变量
构造带 key 信息的 CacheException
Spring 的 CacheException 是运行时异常，没有内置 key 字段，但可通过消息字符串或 cause 传递上下文：
- 推荐方式：在异常消息中拼接 key，例如
new CacheException("Redis operation failed for key ['" + key + "']: " + e.getMessage(), e) - 进阶方式：定义自定义异常（如
KeyAwareCacheException extends CacheException），添加private final Object key;字段，并提供 getter，便于日志和监控提取
在 RedisCache 子类中统一增强
若使用自定义 RedisCache 实现，可重写 get、put 等方法，在异常路径中自动包装 key：
- 覆盖
get(Object key, Callable> valueLoader)方法，在 catchRedisException时，用传入的key参数构建新异常 - 避免在底层 Redis 连接异常（如
RedisConnectionFailureException）中强行塞入业务 key——此时 key 可能无效，应区分网络异常与业务键异常
日志与可观测性建议
仅在异常中包含 key 不够，需确保它能被有效利用：
- 在全局异常处理器（
@ControllerAdvice）或日志拦截器中，检查异常是否为CacheException，尝试提取 message 中的 key 模式（如key \['(.+?)'\]）并打点记录 - 配合 MDC（Mapped Diagnostic Context），在缓存操作开始时将 key 写入日志上下文，即使异常未显式携带 key，也能关联日志链路
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
