JPA中findByUser_Id与findByUserId两种查询写法的区别是什么

1. 解析规则差异 #

• findByUser_Id(Long id)
  写法中的_是Spring Data JPA官方定义的属性路径显式分隔符，会强制按照固定路径解析：先匹配Post实体的user关联属性，再匹配user对应User实体的id属性，生成SQL时会关联user表，查询条件为user.id = ?，逻辑完全固定，不存在任何歧义。

• findByUserId(Long id)
  写法遵循JPA默认的驼峰属性匹配规则，会按优先级匹配属性：

  1. 优先检查Post实体中是否存在名为userId的直接字段，如存在则直接查询post表的user_id字段，不会关联user表
  2. 如Post中不存在userId字段，才会自动拆分驼峰为user+id，此时逻辑和第一种写法完全一致。

2. 你当前场景下的表现 #

结合你给出的实体定义，Post实体仅配置了user关联属性，没有单独的userId字段，两种写法最终生成的SQL、返回的查询结果完全相同。

但如果后续迭代中有人在Post实体中新增了private Long userId字段，两种写法的行为会出现本质差异：第二种写法会查询Post自身存储的userId字段值，第一种写法仍会查询关联User实体的id值。

3. 推荐用法 #

优先选择带下划线的findByUser_Id写法：

• 显式声明属性路径，可读性更强，其他开发者可以一眼判断是关联实体的属性
• 避免后续实体字段变更带来的隐性逻辑错误，降低维护成本

内容的提问来源于stack exchange，提问作者Med Aziz CHETOUI