触发器中金额处理需显式声明decimal精度（如decimal(19,4)）、避免float/money混用、null前置判断、禁用默认round、增加溢出校验与上下文错误日志。
触发器里用 CAST 或 CONVERT 转金额容易丢精度
SQL Server 和 MySQL 都支持把字符串或浮点数转成金额类型，但直接写 CAST(@val AS DECIMAL) 很可能没指定精度，结果变成 DECIMAL(18,0) —— 小数全被截断。比如 '123.45' 转完变 123，账就对不上了。
实操建议：
- 显式声明精度和小数位：MySQL 用
CAST(@val AS DECIMAL(19,4))，SQL Server 同样要写满DECIMAL(19,4)，别省略 - 避免从
FLOAT或REAL转：这类近似类型本身就有二进制表示误差，CAST(12.34 AS FLOAT)再转回DECIMAL可能得12.339999999999999 - 字符串输入先
TRIM再转：空格或不可见字符（如CHAR(160)）会导致CAST失败，报错Conversion failed when converting the varchar value ' 123.45 ' to data type decimal.
触发器中更新金额字段时，INSERTED 和 DELETED 表的数值类型不一致
常见场景是 UPDATE 触发器里要比较新旧值差额，但开发人员常忽略源表字段类型和触发器内部变量类型的隐式匹配问题。比如源表金额列是 DECIMAL(19,4)，而你在触发器里用 DECLARE @old_amt MONEY 接收，SQL Server 会自动把 MONEY 当作 DECIMAL(19,4) 处理，但计算时仍可能因舍入规则不同出偏差（MONEY 四舍五入到千分位，DECIMAL 是精确截断）。
实操建议：
- 所有中间变量类型必须和源字段完全一致：查
sys.columns确认原字段的precision和scale，然后照搬声明@new_amt DECIMAL(19,4) - 避免混用
MONEY和DECIMAL：尤其在跨版本迁移或与旧系统对接时，MONEY在 SQL Server 2022+ 已标记为“不推荐”，且和DECIMAL的算术行为不完全兼容 - 做差值运算前先检查是否为 NULL：直接写
@new_amt - @old_amt，任一为 NULL 结果就是 NULL，而不是 0 —— 这类逻辑漏洞在线上常导致对账差异
MySQL 触发器里用 ROUND() 处理金额四舍五入有陷阱
MySQL 的 ROUND() 默认使用“银行家舍入”（偶数舍入），不是数学四舍五入。比如 ROUND(2.5, 0) 得 2，ROUND(3.5, 0) 得 4。财务系统要求明确的“向上进位”或“向下截断”，不能依赖默认行为。
实操建议：
- 需要确定性舍入时，改用
CEILING()、FLOOR()或TRUNCATE()：例如手续费按分进位，用CEILING(@amt * 100) / 100 - 慎用
ROUND(x, y)做中间计算：它返回的是DOUBLE，再赋给DECIMAL字段时又触发一次隐式转换，可能引入微小误差 - 测试边界值：特别验证
.4999、.5、.5001这三类输入在目标精度下的输出，别只测整数
触发器执行失败时，金额相关错误信息不直观
典型报错像 Arithmetic overflow error converting numeric to data type numeric. 或 MySQL 的 Out of range value for column 'amount'，但没说明是哪一行、哪个值、哪个字段越界。调试时只能靠 PRINT 或日志临时加字段检查，效率极低。
实操建议：
- 在触发器开头加校验逻辑：用
IF NOT (@val BETWEEN -99999999999999.9999 AND 99999999999999.9999)主动抛出自定义错误，附带@val值和上下文 - SQL Server 中用
THROW 50000, 'Amount overflow in INSERTED.amount: ' + CAST(@amt AS VARCHAR(20)), 1;替代RAISERROR，更易捕获 - MySQL 里无法在触发器中直接抛出带变量的错误，可写入临时日志表（如
debug_trigger_log），至少保留INSERTED.id和原始字符串值，方便事后追溯
金额类型在触发器里不是“设好类型就万事大吉”的事，精度声明、NULL 处理、舍入策略、错误定位——每个环节都卡在业务逻辑的敏感点上。漏掉任意一个，上线后都是对账差异，而且很难复现。
