JpaRepository扩展PagingAndSortingRepository，而PagingAndSortingRepository又扩展CrudRepository。

它们的主要功能是:

CrudRepository主要提供CRUD函数。 PagingAndSortingRepository提供了对记录进行分页和排序的方法。 JpaRepository提供了一些与jpa相关的方法，例如在批处理中刷新持久性上下文和删除记录。

由于上面提到的继承，JpaRepository将拥有CrudRepository和PagingAndSortingRepository的所有功能。因此，如果你不需要存储库拥有JpaRepository和PagingAndSortingRepository提供的功能，请使用CrudRepository。

Crud Repository是基本接口，它充当标记接口。

JPA存储库还扩展了PagingAndSorting存储库。 它提供了所有对实现分页有用的方法。Crud Repository没有提供实现分页和排序的方法

你可以参考- https://www.tutorialspoint.com/difference-between-crudrepository-and-jparepository-in-java#:~:text=Crud%20Repository%20is%20the%20base,acts%20as%20a%20marker%20interface.&text=JPA%20repository%20also%20extends%20the,for%20implementing%20pagination%20and%20sorting。

spring-data-jpa 3.x的最新更新

从spring-data-jpa 3开始。X与弹簧靴一起使用。6.x和弹簧芯，

结构和层次结构已经修改，看起来更加清晰。

ListCrudRepository扩展了CrudRepository

ListPagingAndSortingRepository扩展了PagingAndSortingRepository

JpaRepository扩展了ListCrudRepository, listpaging和sortingrepository。

所以基本上新引入的ListPagingAndSortingRepository接口，ListCrudRepository现在代表了旧接口的功能，但返回类型为List<T>，而剩余的PagingAndSortingRepository, CrudRepository处理返回类型为Iterable<T>

在新的(3.x)版本中，结构如下:

在过去(3.0之前)，许多返回List<T>的声明方法都直接在JpaRepository中声明，但现在这些方法有单独的接口，它们被提取到ListPagingAndSortingRepository, ListCrudRepository中。

(3.x)之前的结构是

我希望从上面的模式中可以清楚地看到，在3中提到的JpaRepository和CrudRepository是如何被修改的。x版本。

In case you plan to migrate spring-data-jpa from 2.x into 3.x (would be necessary if you migrate from spring-boot 2.x to spring-boot 3.x) as illustrated in the above schemas you should expect to have breaking code in cases where you have used the PagingAndSortingRepository in your code, as in the past it was extending from CrudRepository and so your custom repository which extended directly the PagingAndSortingRepository already had access to the methods of CrudRepository. If this is the issue you should fix this by adapting your custom repository to also extend either the ListCrudRepository or the CrudRepository.

JpaRepository扩展PagingAndSortingRepository，而PagingAndSortingRepository又扩展CrudRepository。

它们的主要功能是:

CrudRepository主要提供CRUD函数。 PagingAndSortingRepository提供了对记录进行分页和排序的方法。 JpaRepository提供了一些与jpa相关的方法，例如在批处理中刷新持久性上下文和删除记录。

由于上面提到的继承，JpaRepository将拥有CrudRepository和PagingAndSortingRepository的所有功能。因此，如果你不需要存储库拥有JpaRepository和PagingAndSortingRepository提供的功能，请使用CrudRepository。

Ken的回答基本上是正确的，但我想回答你的问题“为什么你想使用一个而不是另一个?”

基础知识

为存储库选择的基本接口有两个主要目的。首先，您允许Spring Data存储库基础设施找到您的接口并触发代理创建，以便将接口实例注入到客户机中。第二个目的是将尽可能多的功能拉入接口，而不必声明额外的方法。

常用接口

Spring Data核心库附带了两个基本接口，它们公开了一组专用功能:

CrudRepository—CRUD方法 PagingAndSortingRepository—用于分页和排序的方法(扩展CrudRepository)

能找到接口

The individual store modules (e.g. for JPA or MongoDB) expose store-specific extensions of these base interfaces to allow access to store-specific functionality like flushing or dedicated batching that take some store specifics into account. An example for this is deleteInBatch(…) of JpaRepository which is different from delete(…) as it uses a query to delete the given entities which is more performant but comes with the side effect of not triggering the JPA-defined cascades (as the spec defines it).

我们通常建议不要使用这些基本接口，因为它们将底层持久性技术暴露给客户机，从而加强了客户机与存储库之间的耦合。另外，您还偏离了存储库的原始定义，它基本上是“实体的集合”。所以如果可以，请使用PagingAndSortingRepository。

自定义存储库基础接口

直接依赖于所提供的基本接口的缺点有两个。它们都可能被认为是理论性的，但我认为了解它们很重要:

Depending on a Spring Data repository interface couples your repository interface to the library. I don't think this is a particular issue as you'll probably use abstractions like Page or Pageable in your code anyway. Spring Data is not any different from any other general purpose library like commons-lang or Guava. As long as it provides reasonable benefit, it's just fine. By extending e.g. CrudRepository, you expose a complete set of persistence method at once. This is probably fine in most circumstances as well but you might run into situations where you'd like to gain more fine-grained control over the methods expose, e.g. to create a ReadOnlyRepository that doesn't include the save(…) and delete(…) methods of CrudRepository.

解决这两个缺点的方法是创建自己的基本存储库接口，甚至是一组基础存储库接口。在很多应用中，我看到过这样的东西:

interface ApplicationRepository<T> extends PagingAndSortingRepository<T, Long> { }

interface ReadOnlyRepository<T> extends Repository<T, Long> {

  // Al finder methods go here
}

第一个存储库接口是一些通用的基础接口，它实际上只固定点1，但为了一致性，还将ID类型绑定为Long。第二个接口通常有从CrudRepository和PagingAndSortingRepository复制的所有find…(…)方法，但不公开操作方法。在参考文档中阅读关于该方法的更多信息。

摘要- tl

存储库抽象允许您选择完全由您的架构和功能需求驱动的基本存储库。如果合适的话，使用现成提供的接口，如果必要的话，制作自己的存储库基础接口。除非不可避免，否则不要使用特定于存储库的接口。

我正在学习Spring Data JPA。它可能会帮助你: