在做 Spring Data JPA 开发时，实体之间的关系怎么建模，一直是个既基础又容易踩坑的点。这篇文章想聊聊两种常见思路——一种是用 JPA 标准注解来搞，另一种是回到原始社会，自己手写一个 Long 类型的字段当外键。结论其实很明确：前者才是正道，后者虽然写起来快，但代价巨大。

在 Spring Data JPA 的项目里，如何把实体之间的关系映射好，直接决定了你后续的数据一致性、查询性能、以及代码的可维护性。团队在实际开发中，一个很常见的误区就是：嫌 JPA 的关系注解麻烦，干脆直接用 private Long companyId; 这样的原始字段来代替。如果你也曾有过这种冲动，或者正在被这类代码折磨，那这篇内容应该能帮你理清思路。

先抛出几个核心判断：用 JPA 标准注解，是在“遵循规范”；用手动外键字段，是在“绕开设计”。前者是长期主义的投资，后者是短期偷懒的债务。

推荐方式：用标准 JPA 关系注解

JPA 提供的那套关系映射机制，绝不仅仅是让你少写几行代码这么简单。它是一个完整、语义清晰的结构化方案。来看一个典型的一对多场景：

@Entity
@Data
public class Employee {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    // 一对多：一个员工属于一个公司（典型业务场景）
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "company_id", nullable = false)
    private Company company;
}

@Entity
@Data
public class Company {
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    // 反向一对多（可选，用于便捷查询）
    @OneToMany(mappedBy = "company", fetch = FetchType.LAZY, cascade = CascadeType.ALL, orphanRemoval = true)
    private List employees = new ArrayList<>();
}

说明：

• @ManyToOne + @JoinColumn 清晰地表达了外键语义。Hibernate 会自动帮你生成 JOIN 查询、管理外键值、处理延迟加载，这些都不需要你操心。
• mappedBy 的写法，告诉 Hibernate 关系的维护端在 Employee.company 这边，避免了双向映射时可能出现的重复更新问题。
• FetchType.LAZY 是绝对不能省的关键设置，它能在你进行关联查询时，有效防止 N+1 问题。至于 CascadeType.ALL，它让级联生命周期管理变得简单——比如你删除公司时，员工会被自动清理掉。

那如果业务场景是真的需要把一个员工分到多家公司（多对多）呢？比如员工可以兼职。这时候就直接上 @ManyToMany 和 @JoinTable。只有当你想自定义中间表名或列名时，才需要显式地声明 @JoinTable：

@Entity
public class Employee {
    @Id private Long id;
    // ...

    @ManyToMany
    @JoinTable(
        name = "employee_company",
        joinColumns = @JoinColumn(name = "employee_id"),
        inverseJoinColumns = @JoinColumn(name = "company_id")
    )
    private Set companies = new HashSet<>();
}

不推荐方式：手动外键字段 + Native Query

接下来要说的，就是那个看上去“简单直接”但后患无穷的写法。比如这个：

@Entity
public class Employee {
    private Long id;
    private String name;
    private Long companyId; // ❌ 纯数值字段，无语义、无约束、无 ORM 感知
}

然后再配合 Native Query 来查：

@Repository
public interface EmployeeRepository extends JpaRepository {
    @Query(value = "SELECT * FROM employee WHERE company_id = :companyId", nativeQuery = true)
    List findByCompanyId(@Param("companyId") Long companyId);
}

你觉得这样写省事？其实给自己和团队挖了个巨大的坑。来看几个硬伤：

• 对象关系映射彻底失效：JPA 完全不知道 companyId 是谁、从哪里来、要到哪里去。你没法通过一个 Employee 直接拿到 Company 对象，必须手动去查、手动组装，代码又臭又长。
• 数据完整性无法保障：除非你手动在数据库层面加外键约束，否则这张表随时可能产生脏数据。而如果数据库有外键，那还用手动维护什么字段？
• 丧失 JPQL 和 Criteria API 的威力：一旦用了 nativeQuery = true，你就把自己绑定到了某种特定数据库的方言上。哪天想从 MySQL 迁移到 PostgreSQL？等着改 SQL 改到怀疑人生吧。
• 高级特性全部报废：懒加载、二级缓存、级联操作……这些 JPA 引以为傲的能力，统统跟你没关系了。
• 业务层逻辑严重耦合：每次要用 Company 时都得现查，一个 findById 塞到一个 service 里，再暴露个方法给 controller。违反了单一职责原则不说，还让代码变得极度脆弱。

总结与最佳实践建议

结论很直接：在绝大多数日常开发场景下，优先选择 @ManyToOne / @OneToMany / @ManyToMany 这些标准注解来建模关系。至于手动外键字段 + Native Query 的写法，只有在极少数特殊场景下——比如遗留系统集成、超高性能的只读报表——才值得一用，而且这时候也不应该把外键字段作为实体的核心属性暴露出来。

真正的“简单”，是遵循规范后长期可维护的简单，而不是省掉几行代码的虚假便利。