核心Spring Framework的Cache Abstraction不仅仅是缓存注释的集合，特别是通常所说的Look-Aside或Cache-Aside缓存。Cache-Aside模式是Spring的Cache Abstraction所基于的缓存模式。

Spring的缓存抽象是一个通用的缓存框架（和外观），具有API允许用户插入不同的“缓存提供程序”实现（例如，使用以下位的Redis或Apache Geode）。出于所有意图和目的，它是一个适当的服务提供程序接口（SPI），其实现遵循SPI定义的接口。

Spring的Cache Abstraction中的两个主要接口包括CacheManager和Cache。

这些是在添加对新缓存提供程序的支持时必须实现的主要接口和API，该提供程序可用于将缓存应用于Spring托管应用程序服务（组件或Spring容器中声明的bean）。在幕后，Spring的缓存抽象是使用SpringAOP实现的。

您可以直接在Spring托管的应用程序组件（bean）中使用CacheManager和Cache接口中的API，也可以更常用的使用缓存注释（例如@Cacheable），如果适用，它们侵入性更小，更容易禁用（例如，只需删除@EnableCach注释，或者在Spring Boot的情况下，将Spring. cache.type属性设置为无；参见此处）。

Cache接口（Javadoc）仅提供与缓存相关的基本和必要的数据访问操作（例如查询）。它不提供可能由底层缓存提供程序（例如Redis）提供的“低级”数据访问操作。

这主要是由于并非所有缓存提供程序都是平等的。一些缓存提供程序在功能和能力方面远远超过其他缓存提供程序，这些功能和能力不属于“缓存的一般关注点”。事实上，像查询或分布式计算、复制、驱逐/到期策略（因此）、一致性保证等事情，都因缓存提供程序而异。缓存提供程序通常是根据您的应用程序用例和要求选择的。

但是，如果您需要，Spring不会阻止您访问低级功能，即使是从缓存抽象中也是如此。

例如，Cache. getNativeCache（）方法返回缓存提供程序实现的Cache接口的底层实现。在Apache Geode的Spring中，这是一个缓存Region。在Redis的Spring中，我相信这是一个HASH。

关于“限制”，正如您所说，例如，“缓存POJO的集合…”，这并不完全正确。

事实上，Spring的Cache Abstraction是故意为通用缓存设计的，这涉及“查找”，而不是查询或处理复杂的对象层次结构，甚至对象的数组/集合。

虽然Spring不会开箱即用地处理这些类型的问题，但这并不意味着它们不可能。Spring被设计为Open/Closed原则，对修改“关闭”，但对扩展“开放”。

例如，可以将Spring的Cache Abstraction扩展为将单个元素缓存在由@Cacheable服务方法返回的数组或Collection（例如List）中。

请参阅我对StackOverflow问题的回答（第2个或底部）。具体来说，请参阅这篇SO文章。

问题是，虽然Spring可能没有开箱即用的直接答案，但通常总会有答案，但可能涉及一些工作（代码）。

如果你理解了底层的设计原则，那么你就可以开始插件化，并根据需要定制缓存行为的所有方面，例如缓存是如何解析的（来自提供者）、密钥生成或条件缓存。Spring提供了“默认”行为（例如），但几乎每个方面都可以通过某种方式进行定制。

尽管如此，有些东西还是非常特定于提供者的（比如“过期”），所以你并不完全不必理解你的底层提供者。没有任何技术可以完全避免理解底层基础设施，例如，甚至连数据库的JPA都不行，尤其是当你需要创建索引的时候。

希望这有意义。