这确实是JPA双向关联的预期行为，我来给你拆解原因和解决方案：

为什么会出现这个问题？ #

你定义的是双向一对多关联：

• Business 是关系的被维护端（通过mappedBy="business"指定，意思是"关联关系由Domain的business字段来维护"）
• Domain 是关系的维护端（因为@JoinColumn(name = "business_id")在这个实体上，外键的更新依赖于这个实体的business属性）

当你通过REST接口传入JSON时，JSON序列化框架（比如Jackson）只会把domains列表填充到Business的domains集合里，但不会自动给每个Domain实例设置business引用——也就是说，这些Domain的business字段还是null。而JPA只会根据维护端（Domain）的business属性来生成外键，所以最终数据库里的business_id就会是空的（不过你的@JoinColumn设置了nullable=false，理论上应该会触发约束报错，可能是测试场景的特殊情况？）

你写的测试代码能正常工作，正是因为你手动调用了d1.setBusiness(b)，维护了维护端的关联关系，JPA才能正确把Business的ID写入Domain的外键字段。

怎么解决？ #

有两种常用方式来处理这个问题：

1. 在持久化前手动遍历维护关联

就像你代码里注释的那样，在BusinessService的persist方法里循环设置：

public void persist(Business entity) {
    // 维护双向关联
    if (entity.getDomains() != null) {
        for (Domain domain : entity.getDomains()) {
            domain.setBusiness(entity);
        }
    }
    em.persist(entity);
    em.flush();
}

这种方式简单直接，适合快速解决问题。

2. 在实体类中封装关联维护逻辑（更优雅的方式）

给Business添加一个addDomain方法，在添加Domain到集合的同时，自动设置反向关联：

@Entity
@Table(name = "Business")
public class Business {
    // 现有字段...
    @OneToMany(mappedBy="business", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<Domain> domains = new ArrayList<>();

    // 替换原来的setDomains，或者新增addDomain方法
    public void addDomain(Domain domain) {
        domains.add(domain);
        domain.setBusiness(this);
    }

    // 如果需要设置整个集合，也可以这样写：
    public void setDomains(List<Domain> domains) {
        this.domains.clear();
        if (domains != null) {
            domains.forEach(this::addDomain);
        }
    }

    // 其他getter/setter...
}

这样一来，不管是JSON反序列化自动填充domains集合，还是手动添加Domain，关联关系都会被自动维护，不需要在Service层再做额外处理。

补充说明 #

• cascade = CascadeType.ALL 只是表示父实体的持久化、更新等操作会级联到子实体，但不会自动维护双向关联的引用关系，这是两个完全不同的概念。
• 保持双向关联的一致性是开发者的责任，ORM框架不会帮你自动完成这一步，因为框架无法判断你的业务逻辑是否需要这种关联（比如某些场景下可能确实需要单向关联）。

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