Hibernate中FetchType.Lazy标记的子集合为何触发额外SELECT？

我在理解Hibernate的FetchType.Lazy工作机制时遇到了困惑，定义的实体如下：

Order实体 #

@Entity
@Table(name = "customer_order")
public class Order {

@Id
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@OneToOne(cascade = CascadeType.ALL)
private Cart cart;
// unidirectional association

... other stuff omitted for brevity ...
}

Cart实体 #

@Entity
@Table(name = "cart")
public class Cart {

@Id
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

 ... some stuff omitted for brevity ...

@JsonManagedReference
@OneToMany(mappedBy = "cart", cascade = CascadeType.ALL, orphanRemoval = true)
private List<OrderItem> orderItems = new ArrayList<>();

public void addItem(OrderItem item) {
    orderItems.add(item);
    item.setCart(this);
}

public void removeItem(OrderItem item) {
    orderItems.remove(item);
    item.setCart(null);
}
}

OrderItem实体 #

@Entity
@Table(name = "order_item")
public class OrderItem {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "id")
private Long id;

... fields omitted for brevity ...

@JsonBackReference
@ManyToOne(fetch = FetchType.LAZY)
private Cart cart;

@Override
public int hashCode() {
    return getClass().hashCode();
}

@Override
public boolean equals(Object obj) {
    if (this == obj)
        return true;

    if (!(obj instanceof OrderItem))
        return false;

    return id != null && id.equals(((OrderItem) obj).getId());
}
}

我通过Controller->ServiceImpl->RepositoryImpl的层级查询Order，代码如下：

@Override
public Order findById(Long id) {
    System.out.println(em.find(Order.class, id)); // to check what's fetched in memory
    return em.find(Order.class, id);
}

此时Hibernate生成了两条SQL语句：第一条是查询Order关联的相关表，第二条是查询order_item表。Postman返回的Cart对象也包含了orderItems。

根据我对FetchType.LAZY的理解，@OneToMany默认是懒加载，应该只有当调用order.getCart().getOrderItems()时才会触发order_item的SELECT语句，且JSON返回不应包含orderItems。

我想知道：

1. 这种触发额外SELECT的情况是否是预期行为？
2. 若Cart包含大量OrderItem，如何实现高效的按需加载？
3. 我描述的按需加载功能是否需要用DTO投影，而非依赖FetchType.LAZY？

1. 这种触发额外SELECT的情况是否是预期行为？ #

是预期行为，触发原因有两个：

• 你调用了System.out.println(em.find(Order.class, id))，这个操作会触发对象的toString()方法。如果你的Cart类的toString()包含orderItems（比如IDE自动生成的toString包含集合属性），就会触发懒加载，执行order_item的查询。
• Spring MVC将实体序列化为JSON时，@JsonManagedReference会让Jackson遍历Cart的orderItems集合，此时Session尚未关闭，会触发懒加载，导致额外SELECT执行。

2. 若Cart包含大量OrderItem，如何实现高效的按需加载？ #

• 控制懒加载触发时机：确保仅在明确需要时调用getOrderItems()，且操作在Session关闭前完成；避免在toString、序列化等场景意外触发懒加载。
• 配置批量抓取：在@OneToMany上显式声明fetch = FetchType.LAZY，同时添加@BatchSize(size = 20)，这样加载多个Cart时，Hibernate会批量查询对应OrderItem，减少SQL执行次数。
• 分页加载OrderItem：通过Repository方法分页查询，比如List<OrderItem> findByCartId(Long cartId, Pageable pageable)，按需获取部分数据，避免一次性加载大量数据。
• 限制Jackson序列化行为：给orderItems添加@JsonIgnore或@JsonInclude(JsonInclude.Include.NON_EMPTY)，避免序列化时自动加载集合；需要返回时再通过DTO控制。

3. 是否需要用DTO投影而非依赖FetchType.LAZY？ #

不一定必须，但DTO是更可靠的方案：

• 懒加载的局限性：依赖Session生命周期，Session关闭后访问懒加载属性会抛出LazyInitializationException；且容易因为toString、序列化等操作意外触发加载，造成不必要的性能损耗。
• DTO投影的优势：可以精准定义返回字段，完全避免加载不需要的数据，还能规避实体序列化的循环引用问题（即使你用注解解决了循环引用，DTO的灵活性更高）。比如创建OrderDTO和CartDTO，通过JPQL或Criteria直接投影查询，性能更优。
• 选择建议：简单场景下，懒加载配合序列化控制可满足需求；复杂业务或高性能要求场景，优先用DTO投影，代码更清晰，能避免懒加载相关的各种坑。

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