ROUND(amount, 2)在财务场景危险，因amount若为FLOAT/DOUBLE类型，12.345实际存储为12.344999…，导致ROUND返回12.34而非12.35；须用DECIMAL类型配合ROUND或采用ROUND(SUM())总额控制法避免累计误差。
直接用 ROUND() 处理金额几乎必然出错——它不修复精度，只放大误差。
为什么 ROUND(amount, 2) 在财务场景下危险
因为多数数据库里 amount 是 FLOAT 或 DOUBLE 类型，而 12.345 实际存的是 12.344999999999999。这时 ROUND(12.345, 2) 算的是 12.344999… 的四舍五入，结果是 12.34 而非 12.35。
- 这不是函数 bug，是 IEEE 754 浮点数的固有缺陷
- MySQL 5.7、SQL Server 默认都走浮点路径，PostgreSQL 对
NUMERIC安全但对DOUBLE PRECISION同样失效 - Oracle 的
NUMBER类型本身安全，但若输入来自 CSV 导入且用了TO_NUMBER(@col)而非显式CAST(@col AS NUMBER(15,4))，仍会掉进浮点坑
必须用 DECIMAL + ROUND 组合，且精度定义要前置
精度控制不是查询层的事，而是建表或导入时就该锁死的契约。
- 建表时强制：
ALTER TABLE financials MODIFY amount DECIMAL(15,4);（MySQL）或ALTER TABLE financials ALTER COLUMN amount TYPE DECIMAL(15,4);（PostgreSQL） - CSV 导入时：用
CAST(@amount AS DECIMAL(15,4))，绝不用CAST(@amount AS FLOAT) - 触发器中声明变量：必须写满精度，如
DECLARE @amt DECIMAL(19,4)，不能只写DECIMAL（默认变成DECIMAL(18,0)，小数全丢） - SQL Server 用户注意：
MONEY类型已不推荐，且和DECIMAL的舍入行为不一致（MONEY自动四舍五入到千分位）
SUM(ROUND()) 和 ROUND(SUM()) 差 0.01 元的根本原因
这是对账差异最常被甩锅给“系统问题”的真实源头：会计准则要求总额控制，而开发常误用明细控制。
- 错误写法：
SUM(ROUND(detail_amt, 2))→ 每行独立进位，误差叠加。例：[1.355, 1.355]变成1.36 + 1.36 = 2.72，但真实和是2.71 - 正确写法：
ROUND(SUM(detail_amt), 2)→ 先保真求和，再统一进位 - 若需在明细行展示“分配后金额”，得用补差逻辑：先算出
ROUND(SUM(detail_amt), 2)总额，按比例分配，最后一行填平余数 - GROUP BY 时禁用
ROUND(price, 2)当分组键——浮点误差会让本该相等的值分裂成不同组；应转为整数单位，如amount_cents / 100
ROUND 结果带尾随零（如 12.350）怎么去掉
这不是显示问题，是类型继承行为：ROUND() 返回值类型由输入决定，不会自动缩容。
-
ROUND(12.345, 2)输入是DECIMAL(10,3)，输出仍是DECIMAL(10,3)，只是第三位是 0 - 要真正截断成两位小数，必须显式转换：
CAST(ROUND(amount, 2) AS DECIMAL(10,2)) - MySQL 中
ROUND()对浮点数仍有风险，哪怕加了CAST，也建议在应用层或导出前用FORMAT()（仅限字符串输出）或前端处理 - Oracle/PostgreSQL 用户别依赖
TO_CHAR(x, 'FM999999.00')做计算——它返回字符串，无法参与后续数值运算
真正难的从来不是写对 ROUND()，而是意识到：精度问题必须从数据类型定义、输入源转换、运算顺序三层同时卡死。漏掉任意一环，ROUND() 就只是个优雅的误差放大器。
