可直接用 criteriabuilder.function() 调用 oracle 函数，需确保函数存在、大小写严格匹配（如"to_date"）、返回类型正确（如string.class）、参数为expression类型（root.get()或cb.literal()），且个数顺序符合oracle签名；自定义函数须为deterministic或reads sql data，禁用dml，返回自定义类型时需退回到原生查询。
可以直接用 CriteriaBuilder.function() 调用，但必须确保函数在 Oracle 中已存在、参数类型匹配、返回类型声明正确——否则生成的 SQL 会报 ORA-00904 或类型不匹配错误。
如何用 Specification 调用 Oracle 内置或自定义标量函数
Oracle 的函数（如 UTL_MATCH.EDIT_DISTANCE_SIMILARITY、to_date、regexp_like）本质是 SQL 表达式，JPA 通过 CriteriaBuilder.function() 将其“翻译”为原生 SQL 函数调用。
- 第一个参数是函数名，**必须和 Oracle 中实际定义的大小写一致**（多数情况下全大写，如
"TO_DATE"） - 第二个参数是 Java 返回类型，比如
Integer.class、String.class、Date.class，不能写错 - 后续参数必须是
Expression类型：字段用root.get("fieldName")，字面量要用cb.literal("value")或new LiteralExpression(value) - 函数参数个数、顺序、类型需严格对应 Oracle 函数签名，例如
to_date(str, fmt)不能把格式串写成第三个参数
示例：对字符串字段做模糊相似度过滤
Expression<integer> similarity = cb.function(
"UTL_MATCH.EDIT_DISTANCE_SIMILARITY",
Integer.class,
root.get("registerAddress"),
cb.literal(appCustomer.getRegisterAddress())
);
predicates.add(cb.greaterThanOrEqualTo(similarity, 80));
</integer>
调用自定义 PL/SQL 函数（非存储过程）的注意事项
自定义函数（CREATE FUNCTION）和内置函数调用方式一致，但有几处关键约束：
- 函数必须是
DETERMINISTIC或至少是READS SQL DATA，否则 Oracle 可能在某些上下文（如索引组织表、物化视图刷新）中拒绝执行 - 函数体里不能有 DML（INSERT/UPDATE/DELETE），否则 JPA 查询时会抛
ORA-14551 - 若函数返回自定义类型（如 OBJECT 或 TABLE），JPA 无法自动映射，只能退回到原生查询（
@Query(nativeQuery = true)） - 函数名要带 schema 前缀（如
"MYSCHEMA.MY_CUSTOM_FUNC"），尤其当调用者非 owner 时，否则报ORA-00904
为什么 function() 有时生成的 SQL 缺失参数或报错
常见原因不是语法写错，而是 Expression 构建不合法：
-
cb.literal(null)会导致整个表达式为 null，最终 SQL 里出现FUNC(NULL, ...)，Oracle 可能直接报错或结果不可控 - 字段路径错误，如
root.get("appCustomer").get("nonExistField")在编译期不报错，但运行时生成无效列名，SQL 执行时报ORA-00904 - 类型强转遗漏：比如数据库字段是
VARCHAR2(100)，但你传了Integer.class给function()，Hibernate 会尝试 cast，可能触发隐式转换失败 - Oracle 版本差异：12c+ 支持更多函数，但 11g 不支持
JSON_VALUE等，需确认目标库版本
替代方案：什么时候不该用 function()
不是所有场景都适合走 Criteria API 调函数：
- 函数嵌套过深（如
UPPER(TRIM(COALESCE(col, '')))），可读性差且难调试，不如在数据库层封装好再调用 - 需要返回多列或复杂结构（如自定义 TYPE TABLE），
function()只支持单值标量，此时应改用@Query(nativeQuery = true)+SqlResultSetMapping - 性能敏感场景：函数未建函数索引，又在 WHERE 中大量使用，会导致全表扫描；应先确认执行计划是否走了索引
- 跨库兼容需求：该代码未来可能切到 MySQL/PostgreSQL，则
function()调用完全失效，需抽象为策略接口
真正容易被忽略的是：Oracle 函数调用发生在数据库服务端，JPA 不做任何校验或预处理——写错一个字母，只有执行时才暴露，且错误堆栈往往不指向你的 Specification 文件，而是在 Hibernate SQL 日志或 Oracle trace 里才能定位。
