double转int默认截断而非四舍五入，因主流语言强制转换语义定义为向零截断；需用Math.round()实现四舍五入，Math.floor()实现向下取整，并警惕精度丢失与溢出风险。
double 转 int 时为什么不是四舍五入而是直接截断
因为 C/C++/Java/JavaScript 等主流语言中，(int) 强制类型转换、Math.floor() 或 parseInt() 等默认行为都是向零截断（truncation），不是四舍五入。比如 -3.9 转成 int 是 -3，不是 -4；2.8 变成 2，不是 3。这是底层二进制表示和类型转换语义决定的，不是 bug。
常见错误现象：(int)3.9 得到 3，但业务需要的是 4；或者处理负数时发现结果“偏大”（比如 (int)-2.7 → -2，而你预期是 -3）。
- Java/C# 中
(int)强制转换只截断小数部分，不改变符号位 - C/C++ 标准规定：当浮点数超出
int表示范围时，行为未定义（可能崩溃或返回任意值） - JavaScript 的
parseInt(3.9)先转字符串再截，Math.trunc(3.9)才是纯截断，但Math.round()才是四舍五入
用 Math.round() 替代强制转换实现四舍五入
Math.round() 是最常用也最安全的替代方案，它把 double 四舍五入到最近的 long（Java）或 int（JS），且对负数也符合数学直觉：-2.5 → -2，-2.6 → -3。
注意：Java 中 Math.round(double) 返回 long，不能直接赋给 int 变量（需显式强转，但要确保值在 int 范围内）；JS 中 Math.round() 返回 number，可直接用于整数运算。
- Java 示例：
int x = (int) Math.round(3.6); // 正确，得 4 - Java 风险点：
Math.round(3e10)返回long值远超int最大值，强转会溢出为负数 - JS 示例：
const n = Math.round(-2.5); // -2，不是 -3 —— 注意 JS 的 round 是“四舍五入到偶数”规则，-2.5 和 -1.5 都取偶数侧
需要向负无穷取整？用 Math.floor()，别信 (int)
如果业务逻辑要求“向下取整”（比如计算页码、分组索引），(int)-2.7 得到 -2 是错的，正确结果应是 -3。这时必须用 Math.floor()，它始终朝负无穷方向取整。
对比：Math.floor(-2.1) → -3，Math.floor(2.9) → 2；而 (int)-2.1 → -2，(int)2.9 → 2。两者仅在正数时结果一致。
- Java/C#：
(int)Math.floor(x)可行，但要注意x是double，Math.floor返回double，强转仍可能溢出 - 更稳妥写法（Java）：
long l = Math.floorDiv((long)Math.floor(x), 1);不推荐——太绕；实际建议先判断范围再转 - Python 用户注意：
int()在 Python 中也是向零截断，但math.floor()行为一致，无需额外适配
精度丢失比截断更危险：先检查 double 是否真能精确表示整数
很多问题根本不在“怎么截”，而在“这个 double 本来就不该是整数”。比如 0.1 + 0.2 是 0.30000000000000004，转 int 得 0，而不是预期的 0 或 1。这时候强行 round 或 floor 只会让误差更隐蔽。
- 典型场景：金额计算、坐标像素对齐、数组下标生成
- 防御性做法：若原始值来自小数运算，优先改用整数单位（如“分”代替“元”）或
BigDecimal（Java）、BigInt（JS） - 临时补救：加
epsilon再截断，例如(int)(x + 1e-10)防止2.9999999999999996变成2，但仅适用于已知误差量级的场景
真正难的不是选 round 还是 floor，而是想清楚：这个 double 值，本意是不是整数？如果是，它为什么是 double 类型？
