ORA-06550是PL/SQL解析错误，非运行时错误，主因包括调用语法错误（如漏写? = 导致PLS-00221）、参数类型与ALL_ARGUMENTS视图定义不匹配、返回值未正确注册、驱动版本不兼容（如ojdbc6连19c）或底层对象权限缺失。
Java调用Oracle存储函数时报“参数类型不匹配”，不是Java编译错误，而是JDBC在构造调用语句时与PL/SQL签名对不上——Oracle在解析阶段就拒绝执行，报ORA-06550或PLS-00306，根本没走到函数体内部。
为什么{? = call func(?)}会触发类型校验失败
Oracle JDBC对存储函数调用有硬性语法要求：必须用{? = call func_name(?, ?)}格式，且第一个?是返回值占位符。如果写成{call func_name(?)}（漏掉? =），Oracle会直接报PLS-00221：“xxx is not a procedure or is undefined”，看似是找不到函数，实则是语法不合法导致解析失败。
- 返回值必须注册为
registerOutParameter(1, Types.XXX)，索引从1开始，不能跳过或错位 - IN参数按SQL中
?出现顺序依次调用setXXX()，位置偏移1就会全乱 - 驱动不会自动推断函数返回类型，
Types.NUMERIC和Types.DECIMAL在处理NUMBER(10,2)时行为不同，错选可能静默截断小数位
查清函数参数定义比猜类型更可靠
别依赖文档或记忆，直接查ALL_ARGUMENTS视图确认每个参数的data_type、in_out和position：
SELECT argument_name, data_type, in_out, position FROM all_arguments WHERE object_name = 'YOUR_FUNC' ORDER BY position;
-
data_type为VARCHAR2→ 注册用Types.VARCHAR，传参用setString() -
data_type为DATE→ 用java.sql.Date或Timestamp，别用LocalDateTime直传 -
data_type为NUMBER且精度明确（如NUMBER(5)）→ 优先用Types.DECIMAL并配合setScale()，而非Types.INTEGER - 函数返回
BOOLEAN？Oracle JDBC根本不支持，必须让DBA改函数，返回NUMBER(1)或VARCHAR2(1)
ojdbc驱动版本不匹配会掩盖真实类型问题
用ojdbc6.jar连Oracle 19c，即使调用语句语法正确、类型注册无误，也可能在execute()后拿到null或NullPointerException——旧驱动无法正确解析19c增强的元数据，把REF CURSOR或CLOB返回值识别成普通字段。
立即学习“Java免费学习笔记（深入）”；
- Oracle 19c必须配
ojdbc8.jar（对应JDK 8+）或ojdbc11.jar（JDK 11+） - 检查类路径是否混入低版本jar：
ClassLoader.getSystemResource("oracle/jdbc/OracleDriver.class")可定位实际加载路径 - 连接URL加
?useUnicode=true&characterEncoding=UTF-8不能解决类型问题，只是字符集补丁
最易被忽略的是：函数依赖的底层对象（比如它查询的视图）权限缺失，会导致ORA-00942被包裹在ORA-06550堆栈里——看起来像类型错，其实是当前用户根本看不见那个表。
