当 user 类采用 jpa 继承策略（如 joined）且子类（如 customer）被声明为 @entity 时，自定义 native 查询易引发 hibernate 内部类型转换异常，导致 jwt 认证流程中断；改用 spring data jpa 的声明式方法（如 findbyusername）可绕过该问题。
当 user 类采用 jpa 继承策略（如 joined）且子类（如 customer）被声明为 @entity 时，自定义 native 查询易引发 hibernate 内部类型转换异常，导致 jwt 认证流程中断；改用 spring data jpa 的声明式方法（如 findbyusername）可绕过该问题。
在基于 Spring Security + JWT 的认证系统中，若采用面向继承的用户建模（如 User 为父实体，Customer/Vendor 为子实体），极易因 JPA 继承映射与查询机制的耦合而触发隐式异常——典型表现是 JwtAuthenticationFilter 在调用 UserDetailsService.loadUserByUsername() 时抛出类似 CaseStatementDiscriminatorMappingImpl$1 cannot be cast to SqlSelection 的 Hibernate 内部类型转换错误。该异常并非业务逻辑错误，而是 Hibernate 在处理多态查询（尤其是含 @Inheritance(strategy = InheritanceType.JOINED)）时，对自定义原生 SQL 或复杂 JPQL 的 AST 解析失败所致。
根本原因在于：当你为 UserRepository 显式编写 @Query(value = "...", nativeQuery = true) 或含 JOIN 的 JPQL 查询来实现 findByUsername() 时，Hibernate 需要动态生成针对继承层次的 SQL（例如联合 user_table 和 customer 表），但其内部判别器（discriminator）解析器与 SQL AST 构建器在特定版本（如 Hibernate 6.2+）中存在兼容性缺陷，导致 SqlSelection 类型强制转换失败。
✅ 正确解法是完全交由 Spring Data JPA 自动推导查询：
// UserRepository.java
public interface UserRepository extends JpaRepository<User, UUID> {
// ✅ 正确：让 Spring Data JPA 自动生成符合继承策略的查询
Optional<User> findByUsername(String username);
// ❌ 错误：避免以下任何形式的自定义查询
// @Query("SELECT u FROM User u WHERE u.username = :username") // JPQL 多态查询风险高
// @Query(value = "SELECT * FROM user_table WHERE username = ?", nativeQuery = true) // native query 触发 Hibernate AST bug
}同时确保 User 实体正确配置继承策略与判别器（即使未显式声明 @DiscriminatorColumn，JOINED 策略也默认依赖主键关联）：
@Entity(name = "user_table")
@Inheritance(strategy = InheritanceType.JOINED)
// 可选：显式指定判别器列（增强可读性）
// @DiscriminatorColumn(name = "user_type", discriminatorType = DiscriminatorType.STRING)
public abstract class User { // 建议设为 abstract，防止直接实例化
@Id
private UUID userId;
@Column(unique = true, nullable = false)
private String username;
@Column(nullable = false)
private String password;
// ... 其他通用字段
}⚠️ 注意事项：
-
Customer和Vendor子类必须保留@Entity注解，否则继承关系失效，但禁止为其单独定义@Table（除非需覆盖默认表名），且不可重复定义@Id； -
CustomUserDetails必须正确委托User的凭据与权限，尤其注意getPassword()返回user.getPassword()，getAuthorities()应基于角色字段或逻辑生成； - 若需在 Token 中携带子类特有信息（如
firstName），应在loadUserByUsername()中做类型判断并注入到CustomUserDetails的扩展字段中，而非在 JWT Claims 中直接序列化整个实体（避免敏感数据泄露与序列化循环）； - 升级至 Spring Boot 3.2+ / Hibernate 6.3+ 可缓解部分继承查询问题，但仍推荐优先使用声明式方法而非手动优化查询。
通过回归 Spring Data JPA 的约定优于配置原则，既规避了 Hibernate 底层解析缺陷，又保持了代码简洁性与可维护性——这是在多态实体场景下构建安全、稳定 JWT 认证链的关键实践。
