Oracle触发器无法安全生成密码学强度盐值，因语句级上下文共享随机状态，批量INSERT时极易复用同一盐值；唯一可行方案是应用层生成盐并传入，触发器仅执行确定性哈希。
Oracle 触发器本身不能安全地生成密码学强度的盐值，RANDOM_BYTES 不可用，NEWID() 不存在，DBMS_RANDOM.STRING('P', 16) 或 DBMS_CRYPTO.RANDOMBYTES(16) 虽可调用，但**在批量 INSERT 中极易复用同一盐值**——这不是配置问题，是 Oracle 触发器执行模型决定的：语句级上下文共享随机状态，多行插入时所有 NEW.salt 可能完全相同。
为什么不能在 BEFORE INSERT 触发器里直接生成盐
Oracle 没有类似 MySQL 的 RANDOM_BYTES() 函数，常用替代方案有：
-
DBMS_RANDOM.STRING('P', 16)：生成含符号的字符串，但非密码学安全，且在单条 INSERT ... SELECT 多行时返回重复值 -
DBMS_CRYPTO.RANDOMBYTES(16)：真正安全，但必须用RAW类型接收；若在触发器中多次调用（如循环赋值），可能因内部缓存机制返回相同字节序列 -
SYSTIMESTAMP || DBMS_RANDOM.VALUE拼接：时间精度有限（微秒级），高并发下极易碰撞，且无法保证唯一性
更关键的是：盐一旦写入表，后续 UPDATE 触发器若未加防护，可能意外覆盖已有盐值，导致旧哈希全部失效。
真正可行的“半自动”加盐流程（应用层控盐 + 触发器只哈希）
把盐的生成、存储和密码拼接逻辑交给应用层，触发器只做确定性哈希运算——这是唯一兼顾安全性与可控性的路径。
- 建表时允许
salt字段为NULL或VARCHAR2(32)（存 HEX 后的盐） - 应用在 INSERT 前调用：
SELECT RAWTOHEX(DBMS_CRYPTO.RANDOMBYTES(16)) FROM DUAL获取唯一盐 - 应用拼接明文密码与盐（注意顺序！推荐
password || salt），再用DBMS_CRYPTO.HASH计算 SHA2-256：DBMS_CRYPTO.HASH(UTL_I18N.STRING_TO_RAW(password || salt, 'AL32UTF8'), DBMS_CRYPTO.HASH_SH256) - INSERT 语句显式传入
salt和password_hash两个字段值 - 触发器仅作兜底校验（非必需）：
BEFORE INSERT中检查:new.salt IS NULL，若为空则抛异常或设默认值（不推荐自动生成）
如果坚持用触发器生成盐，必须接受这些限制
仅适用于单行 INSERT INTO t VALUES (...) 场景，且需配合严格约束：
- 盐字段类型必须为
RAW(16)，避免字符集转换污染（比如用VARCHAR2存 HEX 后再转回 RAW，易出错） - 哈希计算必须全程保持二进制上下文：
DBMS_CRYPTO.HASH(UTL_I18N.STRING_TO_RAW(:new.plaintext_password, 'AL32UTF8') || :new.salt, DBMS_CRYPTO.HASH_SH256) - 绝不能写成：
DBMS_CRYPTO.HASH(TO_CLOB(:new.plaintext_password) || TO_CLOB(:new.salt), ...)—— CLOB 拼接会引入隐式字符集转换，哈希结果不可重现 - 批量导入（如 SQL*Loader、INSERT /*+ APPEND */）必须禁用该触发器，否则盐全量重复
最常被忽略的一点：盐不是越长越好，而是必须**每用户唯一且不可预测**。触发器内任何伪随机源都难满足后者，所以生产环境应默认信任应用层的 SecureRandom 或 CryptGenRandom，而不是把风险压进数据库层。
