JPA复合主键实现：直接声明多@Id与使用@IdClass/@EmbeddedId的差异及必要性

你遇到的多@Id直接可用的情况，是Hibernate框架提供的非标准扩展实现，并非JPA规范的要求，这种写法存在多个明确隐患：

• 兼容性不符合JPA标准
  JPA规范明确要求：实体存在复合主键时，必须通过@IdClass（外部主键类）或@EmbeddedId（内嵌主键类）声明复合主键结构。仅在多个字段上加@Id的写法属于Hibernate的私有关怀特性，一旦切换到其他JPA实现（如EclipseLink、OpenJPA），项目会直接启动失败，完全无法运行。
• 无法使用标准主键查询API
  JPA的EntityManager.find()方法要求传入唯一的主键对象作为查询参数，如果你没有单独定义复合主键类，就无法使用这个最简便的主键查询API，只能手动写JPQL/SQL拼接两个主键字段查询，增加冗余代码，也容易出现拼写错误。
• equals/hashCode实现不符合主键要求
  复合主键要求必须基于主键字段实现正确的equals和hashCode方法：
  1. 你当前用@Data注解生成的equals/hashCode会包含所有字段（包括非主键的level字段），一旦修改了level的值，该实体对象的哈希值会发生变化，放到HashSet、HashMap等集合中时会出现找不到对象、数据重复的问题。
  2. 如果手动实现equals/hashCode，需要每次新增主键字段时同步修改逻辑，而使用独立主键类可以把主键相关的逻辑封装在单独类中，和实体的业务字段解耦，避免漏改。
• 和JPA高级特性兼容差
  JPA的一级缓存、二级缓存、关联映射的级联操作、持久化上下文的实体状态管理，都是基于标准主键结构实现的。使用非标准的多@Id写法，很容易出现缓存不一致、关联查询结果异常、实体状态同步失败等隐性问题，排查成本极高。

额外注意：你注释中写的@IdClass(Friendship.class)是错误用法，@IdClass不能指定实体自身作为主键类，会引发类加载循环依赖，必须单独定义一个仅包含主键字段的POJO作为主键类。

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