(double转int)截断操作不报错但静默丢精度，向零取整导致负数“变大”，浮点误差引发错账，超范围时静默溢出，高危场景须用bigdecimal或math.round/floor等明确语义方法替代。
double 转 int 的截断操作本身不报错，但会静默丢弃小数部分，且对负数“向零取整”，这在多数业务场景中并不符合真实语义——真正危险的不是丢小数，而是丢精度、丢逻辑、丢一致性。
截断行为本质是向零取整，不是四舍五入
Java 中 (int)3.9 得 3，(int)-3.9 得 -3。它不看小数位大小，只砍掉小数部分，符号不变。这意味着：
- 正数结果 ≤ 原值（如 2.9 → 2）
- 负数结果 ≥ 原值（如 -2.9 → -2，实际“变大”了）
- 和数学上“向下取整”（floor）、“四舍五入”（round）完全不是一回事
浮点表示误差会让截断结果更不可靠
0.1 + 0.2 在 double 中实际是 0.30000000000000004，而 1.0 - 0.9 是 0.09999999999999998。看似无害的小数运算，乘以 100 后再截断，就可能从“1元”变成“0分”或“3元”变成“299分”。
-
(int)((0.1 + 0.2) * 10)→ 3（侥幸正确） -
(int)((1.0 - 0.9) * 10)→ 0（严重错账） - 这种误差无法通过四舍五入完全规避，必须从源头控制精度
超出 int 范围时不会报错，而是静默溢出
double 值如 3e10 远超 int 最大值（2147483647），但 (int)3e10 不会抛异常，而是返回一个毫无意义的负数（如 -147483648），因为高位被直接截断。
- Math.round() 返回 long，若未校验范围直接强转为 int，同样会溢出
- 没有运行时检查，日志里也看不出异常，问题往往在生产环境缓慢暴露
高危场景必须绕开截断，改用明确语义的转换
金额换算、分页计算、索引定位、动画帧计数等场景，不能依赖 (int) 的“看起来像整数”的假象。
- 金额单位换算（元→分）：用
BigDecimal.valueOf(str).multiply(BigDecimal.ONE_HUNDRED).setScale(0, RoundingMode.HALF_UP).intValue() - 需要四舍五入：用
(int) Math.round(d)，但务必先确认d在 int 范围内 - 需要向下取整（如页码、分组起始索引）：用
(int) Math.floor(d)，而非(int)d - 前端传来的金额字符串，应在 Controller 入口就转为 BigDecimal，全程避免 double 参与计算
