本文介绍在 JPA 中不依赖数据库原生函数（如 DATE_PART）的前提下，通过标准 JPQL 和字符串截取方式，从 VARCHAR 类型的日期字符串中安全提取年份、去重并按降序返回 List<Integer> 的完整实现方案。
本文介绍在 jpa 中不依赖数据库原生函数（如 date_part）的前提下，通过标准 jpql 和字符串截取方式，从 `varchar` 类型的日期字符串中安全提取年份、去重并按降序返回 `list
在实际开发中，若 Expensive 实体的 date 字段被错误地定义为 String（如 "2023-01-01"），而非 LocalDate 或 java.time.LocalDate，则无法直接使用 JPA 的日期函数（如 YEAR()）进行类型安全操作。此时，强行使用 @Query(nativeQuery = true) 调用 DATE_PART('year', ...) 不仅丧失数据库可移植性，还可能因字段类型不匹配（如字符串未显式转为 DATE）导致运行时异常或隐式转换失败。
更健壮、可移植且符合 JPA 规范的做法是：利用 JPQL 的 SUBSTRING() 函数直接截取 ISO 格式日期字符串的前 4 位。前提是 date 字段始终以 yyyy-MM-dd 格式存储（这是该方案成立的关键前提）。
✅ 推荐实现如下：
@Query("SELECT DISTINCT SUBSTRING(e.date, 1, 4) " +
"FROM Expensive e " +
"WHERE e.userId = :userId AND e.date IS NOT NULL " +
"ORDER BY SUBSTRING(e.date, 1, 4) DESC")
List<String> findDistinctYearStrings(@Param("userId") Long userId);⚠️ 注意：JPQL 的 SUBSTRING(str, start, length) 索引从 1 开始（非 0），因此 SUBSTRING(e.date, 1, 4) 正确获取年份部分。
但上述方法返回的是 List<String>（如 ["2023", "2022"]）。若业务接口明确要求 List<Integer>，推荐在 Service 层完成安全转换，避免在查询中混合类型处理：
public List<Integer> findDistinctYears(Long userId) {
return findDistinctYearStrings(userId)
.stream()
.map(Integer::parseInt)
.collect(Collectors.toList());
}? 补充建议：
-
长远优化：应尽快将 Expensive.date 字段迁移为 LocalDate 类型，并更新实体映射：
@Column(name = "date") private LocalDate date; // ✅ 启用 JPA 原生日期函数，如 YEAR(e.date)
- 若必须保留字符串类型，建议增加数据库约束（如 CHECK (date ~ '^\d{4}-\d{2}-\d{2}$')）或应用层校验，确保格式一致性。
- 避免在 @Query 中使用 CAST(... AS DATE) + DATE_PART() 组合——它耦合特定数据库（如 PostgreSQL），且对 VARCHAR 字段存在隐式转换风险，在 MySQL 或 SQL Server 中将直接报错。
综上，采用 SUBSTRING 提取年份是兼顾简洁性、可移植性与稳定性的最佳实践。
