使用@Cacheable时后续调用返回结果不一致的原因排查

核心原因：缓存Key生成逻辑异常 #

你的问题大概率是Spring Cache的缓存Key生成未正确识别BookRequest中的hasCopy属性，导致不同参数的请求命中了同一个缓存条目，具体分为两种情况：

1. BookRequest未实现正确的equals()和hashCode()方法 #

你使用了Lombok的@Setter、@Getter但未添加@EqualsAndHashCode注解，Java默认的equals()和hashCode()是基于对象引用而非属性值的。这会导致：

• 即使两个BookRequest实例的hasCopy值不同，Spring Cache的Key生成器可能误判它们为相同Key，从而命中错误的缓存结果。

2. 缓存Key未明确指定，默认生成逻辑忽略了hasCopy #

Spring默认的SimpleKeyGenerator在处理对象参数时，若对象的序列化/反序列化过程中丢失了hasCopy属性（比如部分序列化器会忽略基本类型的默认值），会导致生成的Key不包含hasCopy的状态，让hasCopy=true和hasCopy=false的请求共用同一个缓存Key。

解决方案 #

方案一：给BookRequest添加@EqualsAndHashCode注解 #

修改BookRequest类，让Lombok自动生成基于所有属性的equals()和hashCode()方法，确保Spring Cache能正确区分不同参数的请求：

@Setter
@Getter
@AllArgsConstructor(access = PRIVATE)
@NoArgsConstructor(access = PRIVATE)
@EqualsAndHashCode // 添加该注解
public class BookRequest implements Serializable {

  private String isbn;
  private List<String> isbns;
  private LocalDate bookAddedDateFrom;
  private LocalDate bookAddedDateTo;
  private boolean hasCopy = true;
}

方案二：明确指定@Cacheable的Key #

在findBooks方法的@Cacheable注解中，手动指定包含所有查询参数的Key，避免默认生成逻辑的问题：

@Cacheable(value = "books", key = "#request.isbn + '_' + #request.isbns + '_' + #request.bookAddedDateFrom + '_' + #request.bookAddedDateTo + '_' + #request.hasCopy")
public Page<Book> findBooks(BookRequest request) {
  return bookService(request);
}

方案三：检查缓存序列化配置 #

如果使用Redis等外部缓存，确保序列化器能正确处理BookRequest的所有属性（包括LocalDate和boolean类型）。比如使用Jackson序列化时，需配置支持LocalDate的模块：

@Bean
public RedisSerializer<Object> redisSerializer() {
  Jackson2JsonRedisSerializer<Object> serializer = new Jackson2JsonRedisSerializer<>(Object.class);
  ObjectMapper mapper = new ObjectMapper();
  mapper.registerModule(new JavaTimeModule());
  mapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
  serializer.setObjectMapper(mapper);
  return serializer;
}

额外排查点 #

• 检查bookService方法是否存在状态化逻辑（比如用成员变量存储hasCopy值），确保服务是无状态的；
• 在控制器中打印request.getHasCopy()的值，验证后续请求的参数是否正确绑定。

内容的提问来源于stack exchange，提问作者Denis Kisina