如何编写Spring JPA仓库方法，通过属性表达式查询列表元素交集？

这个需求太常见了——用交集来凑确实能解决问题，但数据库层面就能搞定的事，没必要把数据捞到内存里折腾，给你几个更优雅高效的方案：

假设你的实体结构大概是这样（方便后续示例参考）：

@Entity
public class Person {
    @Id
    private Long id;
    @OneToMany(mappedBy = "person")
    private List<Address> addresses;
    // 其他字段、getter/setter
}

@Entity
public class Address {
    @Id
    private Long id;
    private String zipCode;
    @ManyToOne
    private Person person;
    // 其他字段、getter/setter
}

方案1：自定义JPQL查询（最直接） #

利用分组和统计的思路，让数据库帮我们过滤出包含所有指定ZipCode的Person：

public interface PersonRepository extends JpaRepository<Person, Long> {

    @Query("SELECT p FROM Person p " +
           "JOIN p.addresses a " +
           "WHERE a.zipCode IN :zipCodes " +
           "GROUP BY p.id " +
           "HAVING COUNT(DISTINCT a.zipCode) = :zipCodeCount")
    List<Person> findByAddressesZipCodesAllPresent(
        @Param("zipCodes") List<String> zipCodes, 
        @Param("zipCodeCount") int zipCodeCount
    );
}

原理说明： #

1. 通过JOIN关联Person和Address表，过滤出地址ZipCode在目标列表中的记录
2. 按Person的ID分组，统计每个Person匹配到的不同ZipCode数量
3. HAVING子句确保统计数量等于目标ZipCode列表的大小——这就意味着该Person的地址包含了所有指定的ZipCode

调用的时候只需要传入ZipCode列表和它的长度：

List<String> targetZips = Arrays.asList("100001", "200001");
List<Person> result = personRepository.findByAddressesZipCodesAllPresent(targetZips, targetZips.size());

方案2：Criteria API/Specification（动态场景友好） #

如果你的ZipCode列表是动态生成的（比如根据用户输入动态调整），用Criteria API更灵活：

首先定义一个Specification：

public class PersonSpecifications {
    public static Specification<Person> hasAllZipCodes(List<String> zipCodes) {
        return (root, query, cb) -> {
            // 关联Address表
            Join<Person, Address> addressJoin = root.join("addresses");
            // 过滤ZipCode在目标列表中的记录
            query.where(addressJoin.get("zipCode").in(zipCodes));
            // 按Person分组
            query.groupBy(root.get("id"));
            // 统计匹配的不同ZipCode数量，必须等于列表大小
            query.having(cb.equal(cb.countDistinct(addressJoin.get("zipCode")), zipCodes.size()));
            return query.getRestriction();
        };
    }
}

然后让Repository继承JpaSpecificationExecutor：

public interface PersonRepository extends JpaRepository<Person, Long>, JpaSpecificationExecutor<Person> {
}

调用时直接传入Specification：

List<Person> result = personRepository.findAll(PersonSpecifications.hasAllZipCodes(targetZips));

方案3：Exists子查询（逻辑更直观） #

用双重Exists子查询实现“所有指定ZipCode都存在于Person的地址中”的逻辑：

public interface PersonRepository extends JpaRepository<Person, Long> {

    @Query("SELECT p FROM Person p " +
           "WHERE NOT EXISTS (" +
               "SELECT z FROM :zipCodes z " +
               "WHERE NOT EXISTS (" +
                   "SELECT a FROM p.addresses a " +
                   "WHERE a.zipCode = z" +
               ")" +
           ")")
    List<Person> findByAllZipCodesPresent(@Param("zipCodes") List<String> zipCodes);
}

原理说明： #

外层查询Person，内层逻辑是：不存在任何一个目标ZipCode，是该Person地址中没有的——反过来就是“所有目标ZipCode都存在于该Person的地址中”。

为什么这些方案比临时交集更好？ #

• 性能更高：所有过滤逻辑在数据库层面完成，避免把大量无关数据捞到内存中处理，数据量越大优势越明显
• 代码更简洁：业务层不需要处理集合交集的逻辑，Repository层直接返回符合要求的结果
• 可维护性更强：查询逻辑集中在Repository层，后续调整需求（比如加条件）更方便

内容的提问来源于stack exchange，提问作者Gaʀʀʏ