JPA/Hibernate单元测试按ID查询JobOffer始终返回空对象

触发问题的几个典型代码缺陷 #

• clear()和flush()的调用顺序完全违背JPA运行规则
  现有测试是在完成所有DAO保存操作后，先执行entityManager.clear()，再执行entityManager.flush()。这个顺序下，clear()会把当前持久化上下文里所有托管的实体转为游离态，所有还没真正同步到数据库的插入操作会直接失效；等缓存清空后再调用flush()，此时持久化上下文里已经没有待同步的内容，根本不会执行任何插入SQL，数据库里自然没有对应记录，后续查询必然返回空。
  正确的执行逻辑应该是：完成所有实体的保存调用后，先调用flush()把所有挂起的持久化SQL真正执行到数据库层面，再调用clear()清空一级缓存，排除缓存对后续查询的干扰。
• 手动设置的id值和数据库实际存储的主键完全不匹配
  测试代码构造JobOffer时手动指定了108L、208L这类固定id，但如果JobOffer实体的@Id字段配置了自动生成策略（比如IDENTITY、SEQUENCE），JPA在执行持久化时会直接忽略代码里手动设置的id值，使用生成器规则分配主键。
  同时DAO层保存逻辑用merge()而非persist()做新实体入库，这个行为会进一步放大id不匹配的问题：merge操作遇到配了自动生成策略的id时，会完全丢弃代码手动设置的id值，最终数据库里实际存储的主键和测试代码用来查询的108L、208L没有任何关联，自然查不到对应数据。
• DAO保存方法的逻辑设计冗余且存在逻辑漏洞
  saveJobOffer方法虽然加了@Transactional注解，但内部的判断逻辑是“按传入的id查不到记录才执行保存”，这个逻辑在自动生成id的场景下完全失效：每次保存时手动设置的id在数据库里本来就不存在，判断永远会走到保存分支，但最终写入数据库的id和传入的id又不匹配，整个流程完全偏离预期。

对应的修复方向 #

• 调整测试代码中clear()和flush()的调用顺序，保证所有插入操作真正同步到数据库后，再清空缓存开展后续查询校验
• 替换新实体的持久化方法：测试场景下保存新实体时优先用persist()而非merge()，如果测试需要固定id做校验，要在测试环境临时关闭id自动生成策略，避免代码设置的id被持久化框架覆盖
• 重构DAO的保存判断逻辑：不要再用传入的手动设置id做存在性校验，等实体被持久化、拿到框架生成的真实id后，再基于真实id开展后续的查询校验

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