不能直接用触发器全自动完成安全的加盐哈希，因盐值需唯一且不可预测，而触发器无法安全生成密码学强度随机盐；MySQL 8.0+ 的 RANDOM_BYTES 在触发器中不可重复调用、易复用导致盐重复，仅适用于单行 INSERT 且需 HEX 转换。
不能直接用触发器全自动完成安全的加盐哈希 —— 因为盐值必须唯一、不可预测，而触发器内无法安全生成密码学强度的随机盐。 你看到的“自动加盐”方案，要么依赖应用层预生成盐，要么在触发器里用弱随机源（如 RANDOM_BYTES 或 NEWID()），但后者有兼容性与安全性边界，必须明确知道代价。
MySQL 触发器中调用 RANDOM_BYTES 的实际限制
MySQL 8.0+ 支持 RANDOM_BYTES(n)，但该函数在触发器中**不可重复调用多次**，且不能用于生成不同行的独立盐值（比如批量插入时所有行会拿到相同盐）。更关键的是：RANDOM_BYTES 在语句级上下文可能被缓存或复用，导致盐值重复。
- 只适用于单行 INSERT 场景，且需配合
HEX()转换：SET NEW.salt = HEX(RANDOM_BYTES(16)); - 若表已有数据，
UPDATE触发器中再调用RANDOM_BYTES可能引发不可预期的盐变更（比如误改已存在的盐） - 低版本 MySQL（
SQL Server 中用 NEWID() 作盐的隐患
NEWID() 生成 GUID，看似随机，但它本质是时间戳+MAC地址+随机数混合，**在高并发短时插入下存在碰撞风险**；更重要的是，GUID 作为盐值存储为 VARBINARY(16) 后，若后续用 CAST(... AS NVARCHAR) 拼接密码，字符编码差异（如宽字节截断）会导致哈希结果不一致。
- 正确拼接方式应统一为二进制操作：
HASHBYTES('SHA2_256', @Password + @Salt)（@Salt保持VARBINARY类型） - 千万别写成：
HASHBYTES('SHA2_256', @Password + CAST(@Salt AS NVARCHAR))—— 这会因 Unicode 转码引入不可见字符，比对必然失败 -
NEWID()不适合做长期盐值：它不可重现，也无法审计；生产环境建议盐由应用层用CryptGenRandom或SecureRandom生成后传入
真正可落地的“半自动”方案：触发器只做哈希计算，盐由应用控制
把风险最高的盐生成和密码拼接逻辑移出数据库，触发器只负责确定性哈希运算。这样既利用了 SQL 层性能，又规避了随机性缺陷。
- 建表时预留
salt和password_hash字段，但salt允许 NULL 或由应用 INSERT 时显式提供 - 触发器定义为
BEFORE INSERT，仅当NEW.salt IS NULL时跳过处理；否则执行：SET NEW.password_hash = SHA2(CONCAT(NEW.plaintext_password, NEW.salt), 256) - 应用层在注册前调用
SELECT HEX(RANDOM_BYTES(16))获取盐，再拼好哈希后一次性提交 —— 触发器此时只是校验字段完整性，不参与随机 - 登录验证仍必须在应用层做：查出 salt 后本地计算哈希再比对，绝不在 SQL 中用
WHERE password_hash = SHA2(...)直接比对（防时序攻击）
最易被忽略的一点：加盐哈希不是“设个触发器就完事”，而是整条链路的信任重构。盐的生命周期、哈希算法选择（SHA-256 已不够，推荐 argon2id）、空密码/弱密码拦截、错误响应一致性 —— 这些都在触发器能力之外。把触发器当成最后一步计算工具，而不是安全策略的承载者，才能避开多数线上事故。
