Oracle触发器不能直接执行复杂业务规则校验，但可通过调用满足public static、参数/返回值为Oracle支持类型、无I/O操作等硬性条件的Java存储过程间接实现；不过因易超时、锁表、静默失败，仅推荐用于纯计算类场景。
BEFORE 或 AFTER 触发器里直接调用外部存储过程（尤其是带事务、网络、I/O 的）极大概率导致锁表、超时或静默失败，不建议在 DML 触发器中调用任何非纯计算类的外部存储过程。
真正可控的做法，是把“调用”限制在三个边界内：本地内存计算 + 无事务副作用 + 参数类型严格匹配 Oracle 映射规则。超出这个范围，就该换方案——比如改用应用层异步处理，或用 DBMS_SCHEDULER 延后执行。
AFTER INSERT 触发器里调用 PROCEDURE 的硬性前提
- 被调用的过程必须是
SECURITY DEFINER，且权限已显式授予（不能靠角色继承） - 过程内部不能含
COMMIT、ROLLBACK或SAVEPOINT，否则触发器会报ORA-04092: cannot commit in a trigger - 所有输入参数必须是 SQL 可隐式转换的类型：
VARCHAR2、NUMBER、DATE、BOOLEAN（注意：PL/SQLBOOLEAN无法被 SQL 调用，得换成CHAR(1)） - 若过程含异常处理，必须捕获所有可能错误并
NULL化或转成日志，不能让异常穿透到触发器上下文，否则整条 DML 会回滚
CALL 和 EXECUTE IMMEDIATE 在触发器里的行为差异
-
CALL proc_name(...)是静态调用，编译期绑定，性能好但灵活性低；适用于参数固定、逻辑稳定的场景 -
EXECUTE IMMEDIATE 'BEGIN proc_name(:1, :2); END;' USING v_arg1, v_arg2;是动态调用，运行期解析，支持拼接逻辑，但每次执行都需软解析，且容易引入 SQL 注入风险（如果变量来自:NEW字段且未清洗）
常见错误现象：
- 报
ORA-06550 / PLS-00306: wrong number or types of arguments：参数个数或类型不匹配，特别是OUT参数没声明接收变量 - 报
ORA-00900: invalid SQL statement：在EXECUTE IMMEDIATE中写了不含BEGIN...END的裸过程调用 - 报
ORA-04091: table is mutating：过程内部又去查/改当前触发的表，且没用自治事务隔离
为什么不能在触发器里调用 Java 存储过程做业务校验
- Java 方法必须是
public static，且参数/返回值只能是 Oracle 支持的映射类型（如java.lang.String、int、java.sql.Date），不能用ArrayList、HashMap等容器类（除非你已loadjava整个 jar 并-resolve依赖链） - JVM 启动和类加载耗时不可控，DML 触发时若 Java 方法执行超 3 秒，整个事务会被阻塞，严重拖慢并发写入
-
ORA-29532: uncaught Java exception会直接终止触发器，且错误堆栈不进DBA_ERRORS，只留痕迹在 alert 日志里 - 最关键的是：Oracle JVM 不允许在触发器上下文中发起 Socket 连接、文件读写、JDBC 连接等 I/O 操作，哪怕你授了
java.net.SocketPermission，也会在运行时报安全异常
真正能落地的 Java 调用，仅限于字符串格式化、日期计算、简单加密（如 AES 加密 token）这类纯 CPU 密集型、无状态、无 I/O 的操作。
触发器不是万能胶。当业务规则开始涉及远程服务、第三方 API、文件解析、复杂缓存同步时，就该果断放弃在触发器里“硬塞”逻辑。最容易被忽略的一点是：触发器执行失败不会自动重试，也不会留下可追踪的失败记录，除非你主动写入自治事务日志表。而这类日志表本身又可能成为新的性能瓶颈或死锁源头。
