不能在 BEFORE UPDATE 触发器中直接计算整行 HASH，因 :new 为只读记录型伪变量，不支持字段拼接调用 STANDARD_HASH 或 DBMS_CRYPTO.HASH；且 NULL 会导致结果失效，语法亦不允许多字段链式操作；真正可行的是在 AFTER 触发器中写入审计表比对 old_hash/new_hash。
不能在 BEFORE UPDATE 触发器里直接计算整行 HASH 值——因为 NEW.* 是只读的，且 Oracle 不允许在触发器表达式中拼接多个 :new 字段后调用 STANDARD_HASH 或 DBMS_CRYPTO.HASH；强行写会报 ORA-04082: NEW or OLD references not allowed in table level triggers（即使加了 FOR EACH ROW）或隐式类型转换失败。
BEFORE 触发器里为什么算不了整行 HASH
Oracle 的行级触发器中，:new 和 :old 是记录型伪变量，不是普通变量集合。你不能写 STANDARD_HASH(:new.id || :new.name || :new.email, 'SHA256')，原因有三：
-
:new.id || :new.name这类拼接在触发器 PL/SQL 块中不被允许（语法上不支持对记录字段做链式字符串操作） - 即使拆成单字段赋值再拼，
STANDARD_HASH要求输入是RAW或VARCHAR2，而:new.xxx可能为NULL，||一遇到NULL整个结果就变NULL，HASH 值失效 - 触发器上下文不支持直接调用
DBMS_CRYPTO.HASH（需显式RAW输入，且函数本身不在 SQL 表达式中可用）
真正可行的 HASH 计算位置：AFTER INSERT/UPDATE + 审计表
行哈希的合理用途是事后比对，不是事前拦截。正确做法是把 HASH 存进独立审计表，用 AFTER 触发器驱动：
- 建审计表：
CREATE TABLE audit_log (id NUMBER, table_name VARCHAR2(30), row_id ROWID, old_hash RAW(32), new_hash RAW(32), op_time DATE) - 在目标表上建
AFTER INSERT OR UPDATE OR DELETE FOR EACH ROW触发器 - 在触发器里用
DBMS_CRYPTO.HASH(UTL_RAW.CAST_TO_RAW(:new.id || COALESCE(:new.name, '') || ...), 4)算新值（注意：必须手动处理NULL，用COALESCE替换，且所有字段转成VARCHAR2再拼） -
INSERT INTO audit_log时，:old和:new都可访问，但DELETE时只有:old有效
想让数据“不可篡改”，别靠 HASH，用 GENERATED COLUMN + CHECK
如果目标是防止某行内容被静默修改（比如合同正文、签名时间），MySQL 的 GENERATED COLUMN + CHECK 思路在 Oracle 里对应的是 FUNCTION-BASED INDEX 加应用层约束，但更直接的是：
- 对关键列设
BEFORE UPDATE触发器，强制还原旧值：:new.created_at := :old.created_at; - 或抛异常：
RAISE_APPLICATION_ERROR(-20001, 'created_at is immutable'); - 不要试图用 HASH 校验来实现防篡改——它慢、易绕过、且无法在事务提交前阻断非法更新
最常被忽略的一点：HASH 值本身也得防篡改。审计表没加权限控制、没开审计日志、没定期比对 old_hash 和重算值，那这个 HASH 就只是个装饰字段。
