Spring Data JPA：Projection接口与DTO投影的适用场景及性能对比

这是个非常实用的问题！在Spring Data JPA里做分页查询时，选DTO投影还是Projection接口，确实是很多开发者会纠结的点。我结合实际项目经验和Spring Data的设计逻辑，给你理清楚两者的适用场景和性能差异：

优先选Projection接口的场景 #

• 只读需求+极简代码：如果你只需要读取实体的特定字段，完全不需要修改这些数据，Projection绝对是首选。你只需要定义一个带目标字段getter的接口，Spring会自动帮你生成动态代理实现类，连实体转换的代码都不用写，非常省心。
• 多场景字段组合：如果不同的查询场景需要不同的字段集合，Projection可以轻松应对。比如你可以定义CustomerBasicInfoProjection、CustomerContactProjection等多个接口，Repository方法直接返回对应的Projection类型就行，不用写多个DTO。
• 简单查询场景：当你的查询不需要对字段做任何额外处理（比如格式化、计算），Projection足够轻便，代码量极少，维护成本也低。

举个简单的Projection示例：

public interface CustomerNameProjection {
    String getFirstName();
    String getLastName();
}

// 在Repository中直接用
Page<CustomerNameProjection> findAll(Pageable pageable);

必须用DTO投影的场景 #

• 需要自定义字段处理：如果你要对查询到的字段做加工——比如把出生日期转换成年龄、拼接姓名成全名，DTO投影更合适。因为DTO是普通POJO，你可以在构造方法或者专门的处理方法里添加这些自定义逻辑，灵活性拉满。
• 数据需要后续修改/传递：如果查询结果要用于业务修改，或者需要传递给其他服务做更新操作，DTO是更好的选择。它有完整的字段和setter方法，方便修改和序列化，不像Projection只能只读。
• 复杂关联数据整合：当你需要跨多个实体关联获取数据，并且要把这些关联数据整合成一个对象时，DTO的构造方法或者Builder模式能更灵活地组装数据。虽然Projection也支持嵌套，但在处理复杂关联的自定义整合时，DTO的可控性更强。

比如带自定义逻辑的DTO示例：

public class CustomerDTO {
    private String fullName;
    private Integer age;

    // 通过构造方法直接处理字段
    public CustomerDTO(String firstName, String lastName, LocalDate birthDate) {
        this.fullName = String.format("%s %s", firstName, lastName);
        this.age = Period.between(birthDate, LocalDate.now()).getYears();
    }

    // getter方法
    public String getFullName() { return fullName; }
    public Integer getAge() { return age; }
}

// Repository中用@Query指定构造方法查询
@Query("SELECT new com.example.dto.CustomerDTO(c.firstName, c.lastName, c.birthDate) FROM Customer c")
Page<CustomerDTO> findAllCustomers(Pageable pageable);

性能差异：几乎可以忽略的差别 #

从数据库层面来看，两种方案没有本质区别——Spring Data JPA都会生成只查询目标字段的SQL，不会拉取整个实体的所有字段，所以数据库的查询性能是完全一致的。

差异主要在内存和CPU层面：

• Projection是动态生成的代理类，内存占用略低，因为它只有定义的getter方法，没有额外的业务逻辑。
• DTO是普通POJO，如果有自定义处理逻辑，会有少量的内存和CPU开销，但这种差异在绝大多数业务场景下都可以忽略不计，除非你要处理百万级别的数据量。

另外，Projection的动态代理是一次性生成的，后续查询不会重复生成，所以初始化之后的性能和DTO几乎无差别。

内容的提问来源于stack exchange，提问作者Manuel Jordan