如何在 Spring Boot 中正确缓存 Pageable 查询结果

说到 Spring Boot 中的分页缓存，很多开发者第一反应往往是手动拼接缓存键：把 page、size、sort 一个个提取出来，再拼成一个字符串。其实完全没必要——Spring 的缓存抽象比你想象的要聪明得多。

关键在于 Pageable 这个接口的标准实现，比如 PageRequest，已经老老实实地重写了 equals() 和 hashCode() 方法。这意味着什么呢？举个具体的例子：你调用 PageRequest.of(0, 20, Sort.by("name")) 两次，这两个对象语义完全一致，它们的哈希值也一样；但如果把页码改成 1，或者排序字段换成 price，就会生成一个完全不同的哈希值。这套机制天然就能区分不同的页码、页大小和排序条件——按页粒度的缓存，直接开箱即用。

所以，下面这种写法不仅合法，而且值得推荐：

@Service
public class MarketServiceImpl implements MarketService {
    @Autowired
    private MarketDao marketDao;

    @Cacheable(value = "marketData")
    public Page findAllMarket(Pageable pageable) {
        return marketDao.findAll(pageable);
    }
}

这里有几个关键点需要注意：

• 不需要显式指定 key 属性——Spring 默认会把所有方法参数（这里就是 pageable 对象）拿来构建缓存键；
• 多维度区分是天然支持的——页码、每页条数、排序字段和方向都会参与到哈希计算中，一个不落；
• 线程安全且无副作用——PageRequest 是不可变对象，多线程环境下用起来很放心。

当然，有几个坑得提前避开：

• 如果你自己写了一个自定义的 Pageable 实现，却忘了重写 equals() 和 hashCode()，那缓存要么失效，要么出现诡异的冲突——建议一律使用 PageRequest.of(...) 来构造；
• 缓存容量要合理设置（比如用 Caffeine 时记得配置 maximumSize），否则用户翻几万页，每个页号都生成一条缓存，内存很快就被吃光了；
• 别忘了配合 @CacheEvict 清理相关缓存——比如新增或删除了商品，就应该把 marketData 里所有分页结果都清掉，否则用户看到的还是旧数据。

总结起来，Spring Boot 对 Pageable 的缓存支持简洁又健壮。你只需要相信默认行为，把精力放在业务逻辑上，分页级缓存的能力就已经摆在那了。