JpaRepository实现选List还是Set？Spring Boot JPA集合使用最佳实践问询

问题根源 #

JpaRepository 接口原生定义的findAll()方法返回值为List<T>，你在单元测试中mock该方法时传入HashSet类型参数，类型不匹配自然会报错。
你之前线上运行没有问题，是因为AbstractJpaService的findAll()实现里已经手动把仓库返回的List转为了HashSet，上层调用感知不到差异，但mock是严格匹配方法签名的，所以只有测试环节会暴露这个问题。

关于JPA使用Set的合理性 #

完全可以在JPA中使用Set作为返回类型：

• Spring Data JPA原生支持将查询结果转为任意Collection子类，你自定义的findAllByActiveInstallationIsNull()返回Set能正常运行就是这个原因，框架会自动做类型适配。
• 你想修改基础findAll()方法的返回值也完全符合规范，只要在你的Repository接口中重写该方法即可，比如在FooRepository里加一行：

Set<Foo> findAll();

Spring Data JPA会自动覆盖父接口的返回类型，不需要手动编写实现。

该场景的最佳实践 #

• 优先根据业务场景选择返回类型：
  • 如果业务不需要关心结果顺序、需要自动去重（尤其是多表关联查询场景），用Set更合适，能避免重复数据问题。
  • 如果业务依赖查询排序结果、需要通过下标访问元素，就用List。
• 针对你当前的代码结构，有两种低改造成本的解决方案：
  • 不修改现有业务代码，只调整单元测试：mockfindAll()时传入List类型参数即可，when(fooRepository.findAll()).thenReturn(List.of(foo1, foo2));，服务层的转Set逻辑不受影响，上层返回依然是Set。
  • 统一仓库层返回类型：在所有Repository接口中重写findAll()方法返回Set，既可以删掉服务层手动转Set的冗余代码，mock的时候也可以直接传入Set类型参数，保持全链路类型一致。
    你当前的抽象服务层封装CRUD逻辑的设计是合理的，不需要做大的结构调整，只要统一上下层的返回类型即可。

内容的提问来源于stack exchange，提问作者M.Bugajski