先给结论：向零舍入，英文叫 round toward zero，也叫 truncate（截断），简单说就是直接丢掉小数部分。1.7 变成 1，-1.7 变成 -1，1.999 变成 1，-1.999 变成 -1。这个行为和很多人下意识以为的"四舍五入"完全是两码事，尤其放到负数场景里，最容易翻车。

我知道很多人一听说"舍入"，第一反应就是"四舍五入"，再要么就是向上取整、向下取整这些浮点函数。但向零舍入跟它们都不一样，它有自己非常明确的行为定义，而且在不同编程语言里的实现方式、踩坑方式也各不相同。这篇就来把这些点逐个拆清楚，既能当刷题笔记看，也能当工程实践的避坑手册用。

1. 题目拆解：这道题到底在考什么

1.1 向零舍入的数学定义

从数学角度描述，向零舍入指的是：对一个实数 x 取整，结果是一个整数 n，使得 n 与 x 同号，且 n 的绝对值不超过 x 的绝对值。换句话说，就是把小数部分砍掉，不管小数部分是多少，全部丢弃。数学上通常写作trunc(x)或者truncate(x)。

举几个最直观的例子：

注意看负数那一行：-2.7 向零舍入后是 -2，因为它的绝对值 2.7 往零的方向找，得到 2；-2.3 向零舍入后也是 -2，因为绝对值 2.3 往零的方向找，仍然得到 2。也就是说，向零舍入对正数和负数一视同仁，规则只有一个：删掉小数部分，保留整数部分，不做任何"进位"。

1.2 为什么需要向零舍入而不是四舍五入

很多人会问：直接用四舍五入不就行了？为什么程序里还要单独定义一种向零舍入？

这个问题问到点子上了。四舍五入是我们日常记账、考试算分时的习惯，它确实适合处理十进制世界里的"公平"取舍。但在计算机内部，浮点数是用二进制存储的，很多十进制小数根本无法精确表示。比如 0.1，在二进制里是一个无限循环小数，存进 float 或 double 后已经带上了微小的误差。这个时候再按四舍五入规则去处理，结果会出现很多不可预测的偏差。相比之下，向零舍入的定义极其简单粗暴，只做"截断"这一个动作，不依赖对小数部分大小做任何判断，在计算机底层实现起来非常干净、硬件指令也更友好。很多 CPU 在浮点转整型时，默认行为就是向零截断。

另外，工程里有些场景确实"就应该"直接丢掉小数部分。比如把一个时间戳秒数转成分钟，转完本来就是要丢弃余数的；把一个像素坐标从浮点坐标映射到整数像素坐标，多余的小数像素根本不该存在。这种情况下用向零舍入反而是最符合业务直觉的选择。

所以这道题表面在考"你会不会写一行类型转换"，实际上是在考你懂不懂浮点数在计算机里的表示机制，以及不同语言对"取整"这个语义各自是怎么处理的。

2. 浮点数不精确的根源与舍入的必要性

2.1 二进制小数：0.1 怎么就存不精确了

要想彻底理解向零舍入，必须先把浮点数本身搞明白。很多人学编程时有个困惑：为什么0.1 + 0.2在绝大多数语言里都不等于0.3？原因就是二进制表示的问题。

我们平时说的十进制小数，拆成位权来看是这样：0.1 = 1/10，0.01 = 1/100，每一位代表 10 的负多少次方。但计算机内部是二进制，每一位小数代表 2 的负多少次方，也就是 1/2、1/4、1/8、1/16……任何一个二进制小数，都只能写成这些分数的组合。

十进制 0.5 能精确转成二进制 0.1，因为 5/10 正好等于 1/2。0.25 也能，它正好是 1/4。可 0.1 就不行：0.1 换算成二进制是一个无限循环小数，约等于 0.000110011001100110011...，永远写不完。

IEEE 754 标准规定，单精度浮点数 float 用 32 位来存储，其中尾数部分只有 23 位；双精度 double 用 64 位存储，尾数部分 52 位。二进制小数的位一旦有限，尾数放不下的部分就必须舍去，这不就是一次"舍入"吗？

向零舍入只是众多舍入方案中的一种，而浮点数的存储本身也有它自己的舍入规则，两者不要混淆。存储时，系统把你输入的小数按二进制精度要求舍入成最接近的可表示值，这个过程中用到的通常是"就近舍入"；存储完成之后，当你把这个浮点数转成整数时，又触发了一次"截断"型舍入，也就是向零舍入。两次舍入发生在不同阶段，使用的规则也不同。

2.2 IEEE 754 的四种舍入模式

IEEE 754 标准里一共定义了五种舍入模式，但工程中常见的是下面这四种：

其中默认使用的是就近舍入，这也是0.1 + 0.2产生那个著名误差的根源之一。而向零舍入作为其中一种，特点是两个方向上都不偏向，永远把结果拉向 0 的方向。

这里补充一个冷知识：C 语言的浮点环境里有一个fesetround()函数，可以切换当前线程的舍入模式。但日常业务代码里几乎没人去动它，因为改变舍入模式会影响整个程序中所有浮点运算的行为，很容易引发潜在 BUG。真正经常用到向零舍入的场合，还是"显式取整"这个动作本身。

3. 截断、向下取整与四舍五入：先分清这三个概念

3.1 三种取整概念的对比

向零舍入、向下取整（floor）、向上取整（ceil）这三者之间，最容易被混淆的是向下取整和向零舍入。因为对于正数来说，它们的结果完全一样：2.7 不管向零还是向下，都是 2。可一旦遇到负数，立刻分道扬镳：

• floor(-2.7) = -3：向下取整是往负无穷方向走，所以结果更小。
• trunc(-2.7) = -2：向零舍入是往零的方向走，所以结果更大。

差异一句话总结：floor 看方向，trunc 看零点。

四舍五入和它们的区别更明显：四舍五入需要看小数部分是否达到 0.5 这个阈值。向零舍入不关心小数部分是多少，0.1 和 0.9 结果一样，直接丢弃。

这个区分看起来简单，实际写代码时特别容易出问题。我就见过有人用if (x < 0) return (int)x - 1;这种画蛇添足的写法，试图把负数"修正"成向下取整，结果正好把向零舍入改错了方向。所以动手之前，一定要先明确业务要的是哪一种结果，再选择对应函数，千万不要拿"感觉差不多"的语义去猜。

3.2 负数场景的经典误区

负数场景里最经典的错误，是在不知道语言行为的情况下，直接用强制类型转换，然后想当然地认为结果应该是"往更小的方向走"。你可以自己画一条数轴：0 在中间，-3 在 -2 的左边，整数部分 -2 比 -3 更接近 0。向零舍入就是找"更接近 0"那个方向，也就是 -2。

还有人在面试或考试时被问"-1.5 向零舍入是多少"，第一反应写了 -2，然后被指出应该是 -1。这个错误太典型了，因为日常说"四舍五入 -1.5"，按照习惯，小数部分为 5 时通常会进位，得到 -2。但向零舍入不这么玩，-1.5 的小数部分直接丢掉，剩下 -1，它连给你纠结 0.5 这个阈值的机会都没有。

如果想让自己的思维彻底转过来，可以记这样一句话：向零舍入不叫"取整"，叫"截断"。看到"截断"两个字，你脑子里浮现的应该是"剪刀直接剪掉尾巴"，而不是"四舍五入进一位"。剪掉尾巴，负数自然就比原来的数更接近零。

4. 主流语言实现向零舍入的正确姿势

4.1 C/C++ 的实现与陷阱

C 和 C++ 里，最直接的方法是强制类型转换：

#include <stdio.h> int main() { double x = -2.7; int result = (int)x; printf("%d\n", result); // 输出 -2 return 0; }

C 标准里明确规定，浮点型强制转换为整型时，小数部分直接丢弃，也就是向零舍入。这个行为从 C89 一直延续到现在的 C23，相当稳定。所以(int)-2.7得到的永远是 -2。

但这里有一个非常大的坑：如果浮点数超出了 int 的表示范围，行为是未定义的（C/C++ 语境下）。什么意思呢？比如 double 类型的 3e10，强转到 int 之后，结果可能是INT_MAX，可能是INT_MIN，也可能是任意一个随机数，编译器不同结果可能完全不一样。在最近的 C 标准里，这个行为被定义为"未定义行为"，你没有资格假定它一定等于多少个亿。甚至在有些架构上，浮点转整型还会触发硬件异常。

除了强制转换，C 标准库还提供了trunc()函数：

#include <math.h> #include <stdio.h> int main() { double x = -2.7; double t = trunc(x); printf("%.2f\n", t); // 输出 -2.00，注意是浮点类型 return 0; }

trunc()返回的是浮点类型，所以不存在溢出问题，处理超大浮点数时仍然安全。如果想进一步得到整型，还是要自己再转一次。C 语言在 C++11 和 C99 里都引入了trunc，老版本的编译器可能不支持，写跨平台代码时建议用#ifdef做一下版本判断或者写个宏。

#define MY_TRUNC(x) \ (x >= 0 ? (long long)(x) : -(long long)(-(x)))

这个宏本质上就是手动模拟向零舍入：正数直接截断，负数先转成正数再截断，最后加负号。虽然是绕了一圈，但表达力上非常清晰，也避开了trunc函数版本兼容的问题。

4.2 Python：int() 与 math.trunc()

Python 里的行为同样直接：int()就是向零舍入。int(2.7)得到 2，int(-2.7)得到 -2。这一点和 C 的强转保持了一致。

但 Python 里有个非常隐蔽的坑：//运算符是向下取整，不是向零舍入。看下面两行：

7 // 2 # 3 -7 // 2 # -4，因为 -3.5 向下取整是 -4

很多从 C 转 Python 的人第一次写-7 // 2都会懵，下意识觉得结果应该是 -3，实际上是 -4。这就是向下取整和向零舍入的差异。所以如果你要的是向零舍入，千万别用//，要用int()或者math.trunc()。

import math print(int(2.7)) # 2 print(math.trunc(-2.7)) # -2 print(int(-2.7)) # -2

math.trunc()和int()在参数是 float 时行为一致。但有一点值得提醒：math.trunc()接受的对象可以是实现了__trunc__方法的自定义对象，而int()的转换逻辑不同。在日常处理数值的场景里两者可以互换，但如果你在做框架开发、需要面向对象统一约定时，用math.trunc()表达"向零取整"的意图更明确，代码读起来也更有语义感。

4.3 Java 与 JavaScript 的差异

Java 里强转同样向零：

double x = -2.7; int result = (int) x; // -2

但这只是针对基本类型。如果你用Math.floor()或Math.ceil()，那结果是另外一回事。更常见的一个坑是把浮点数传给BigDecimal时选错了舍入模式。BigDecimal.setScale()里有多种舍入策略，常用的RoundingMode.DOWN就是对十进制数的向零舍入，RoundingMode.FLOOR是对十进制数的向下取整，二者在负数场景下同样不同。金融计算里如果用double做中间运算再转 BigDecimal，早就埋下了精度隐患，正确做法是全程用 BigDecimal，最后显式指定RoundingMode.DOWN或业务要求的其他模式。

JavaScript 的情况稍微复杂一点。以前只能用Math.floor、Math.ceil、Math.round凑出一个向零舍入，比如：

function trunc(x) { return x > 0 ? Math.floor(x) : Math.ceil(x); }

后来 ECMAScript 6 直接增加了原生Math.trunc()：

Math.trunc(2.7); // 2 Math.trunc(-2.7); // -2 Math.trunc(0.1); // 0

如果你在浏览器环境里需要兼容老版本，自己实现的截断函数在内存数字合理范围内完全够用。但注意Math.trunc作用于超出 Number 安全整数范围的数时也不会报错，只是结果可能因为浮点精度问题变得不够直观，比如Math.trunc(999999999999999999999.9)这种场景，你需要先搞清楚 Number 本身的精度极限。

还有个旁门左道：用位运算~~x或x | 0也能做到截断取整。因为位运算在 JavaScript 中会把操作数先转成 32 位整数，这个过程中隐含了向零截断。但致命弱点是它只能处理 32 位范围内的数字，超过这个范围就不对了，拿来做小整数倒还方便，千万别当通用方案用。

4.4 手写一个跨语言通用实现

了解了这么多语言差异之后，我们其实可以总结出一个语言无关的通用实现思路。原理非常简单：利用符号分离，把负数的处理转成正数处理。

def truncate_to_zero(x): if x >= 0: return int(x) else: return -int(-x)

步骤拆开看：

1. 判断 x 的符号。
2. 如果 x 是非负数，直接截断小数部分。
3. 如果 x 是负数，先把 x 变成正数-x，截断，再加回负号。

这样写的好处是你不依赖任何一个语言的trunc或Math.trunc函数，只要语言有最基础的类型转换，就一定能实现向零舍入。理解了它，你到任何新语言里都能秒写出正确代码，前提是你知道那个语言的int()是对正数截断的。

需要注意的是，这种写法在遇到x = -0.0这种极端浮点值时会有细微差别：int(-0.0)在大多数语言里得到 0，符号丢失了，但这对纯数值计算几乎没影响。

5. 实战五个坑与排查技巧

5.1 大数溢出引发未定义行为

C/C++ 里把 double 强转成 int，遇到超出 int 范围的高精度浮点数时，程序可能直接给出一个荒诞结果，这我在实际代码里是踩过的。某个项目需要对坐标数据做换算，计算过程中一个中间值膨胀到了十几亿，强转 int 后就变成了一个明显错误的负数。费了不少劲查出来，就是因为没有在前面加溢出判断。

解决办法很简单，转换之前加一道保险：

double x = compute_value(); if (x > (double)INT_MAX || x < (double)INT_MIN) { // 处理溢出分支 } else { int result = (int)x; }

同理，Java 中没有"未定义行为"，但强转超出范围时会把值饱和到Integer.MAX_VALUE或Integer.MIN_VALUE，如果你没有预期到这一点，同样是一个隐蔽 bug。所以不管哪个语言，先判断边界永远不亏。

5.2 精度误差引起的"假小数"

这是第二次误差的典型例子。假设你需要把 0.29 元换算成分，也就是乘 100。直接用浮点运算：

double money = 0.29; double cents = money * 100; // 实际可能是 28.999999999999996 int result = (int)cents; // 28

你看，期望是 29，结果向零舍入成了 28。问题出在 0.29 在二进制里无法精确表示，乘 100 之后没有精确地得到 29，而是一个比 29 小一丝丝的 28.999999999999996。向零舍入直接把它砍成了 28。

这种问题在财务相关的功能里简直是灾难。我的处理原则是：凡是涉及金额、百分比、单位换算这类对精度极其敏感的计算，一律不用 double/float，改用 BigDecimal 或整数的最小单位计数（比如把"元"变成"分"存储）。如果暂时没办法换类型，至少要在截断前做一次四舍五入之类的精度修正，但这类修正本身也要极其克制，因为你不知道后面有没有二次运算。

5.3 金融场景必须避免 float/double

这里多说一句金融计算。有些语言里提供了ROUND_HALF_UP、ROUND_HALF_EVEN等模式，但这些都不是向零舍入。向零舍入在金融中的典型用法就是"抹零"，比如计算佣金、手续费时要求直接舍去零头，这时候RoundingMode.DOWN就是你要的那个选项。

但如果你在一开始就用 double 存储金额，那么无论后面用哪种舍入模式，前面存储阶段引入的二进制误差都已经混进去了。所以金融系统的正确姿势只有一条：从输入到输出全程使用高精度十进制类型，中间不要经手任何一次 float/double。这一点值得一遍又一遍强调。

5.4 性能与编译器优化

有些搞性能优化的同学会关心向零舍入的代价。硬件层面，x86 指令集里的cvttsd2si就是做"带截断的浮点转整型"，这个指令在 C/C++ 的默认强转场景下会被编译器生成。性能上它和普通浮点转整型一样快，甚至因为不需要按当前舍入模式调整，语义上更干脆。

但如果你手动写了一段if (x < 0) ... else ...来模拟向零舍入，编译器未必能识别出你的意图并优化成一条指令。所以我建议：在能直接用强制转换或trunc()的语言里，就用语言原生的行为，不要为了"显得很懂"去手写分支截断，性能反而可能更差。

5.5 一个快速自查清单

为了避免每次写代码前都要翻文档，我给自己整理过一张自查表，现在也分享出来：

这张表能帮你在 30 秒内避开绝大多数舍入陷阱。

6. 完整实现：从题目到可运行代码

6.1 C 语言题解

既然题目叫"1019：浮点数向零舍入"，那我直接用标准输入输出给一份参考实现。C 语言版本直接利用强转语义：

#include <stdio.h> int main() { double x; while (scanf("%lf", &x) != EOF) { int result = (int)x; printf("%d\n", result); } return 0; }

样例输入输出验证：

输入 2.7 输出 2 输入 -2.7 输出 -2 输入 -0.5 输出 0

注意-0.5强转后是 0，这在向零舍入的定义里完全正确，因为 -0.5 的整数部分是 -0，也就是 0。

如果编译器支持 C99 以上标准，还可以用trunc保存浮点精度：

#include <math.h> #include <stdio.h> int main() { double x; scanf("%lf", &x); double result = trunc(x); printf("%.0f\n", result); return 0; }

6.2 Python 题解与测试用例

Python 版本更简洁：

import sys def truncate_to_zero(x: float) -> int: return int(x) for line in sys.stdin: if line.strip() == "": continue num = float(line.strip()) print(truncate_to_zero(num))

配上测试用例：

assert truncate_to_zero(2.7) == 2 assert truncate_to_zero(-2.7) == -2 assert truncate_to_zero(0.0) == 0 assert truncate_to_zero(-0.0) == 0 assert truncate_to_zero(0.99999999) == 0 assert truncate_to_zero(-0.99999999) == 0

6.3 边界测试设计

如果要把它当成正式题目来提交，边界测试是必须过的。我常用的边界用例思路如下：

• 正小数边界：0.1、0.9、1.0、999.999
• 负小数边界：-0.1、-0.9、-1.0、-999.999
• 零：0.0、-0.0
• 整数：123、-456
• 无效输入：空行、非数字字符串

每种用例都有它存在的意义。比如 -0.9 有些人会错写成 -1，0.999999 会错写成 1，都是因为无意识地带入了四舍五入的思维惯性。测试用例应尽量覆盖正负、零、整数、超大浮点这几种分类，这样才有足够的防御力。

我还建议，在刷题或者面试现场，直接在纸上写出测试样例，用你的实现跑一遍，而不是直接拿去提交。这一步能筛掉九成的低级错误。我自己在带新人时也反复强调：代码写得漂亮不如测试过得漂亮。

7. 我的几点体会

这类看似"简单"的取整题，真正写起来其实比想象中陷阱多得多。归根结底，向零舍入不只是"去小数"三个字，它背后是二进制浮点表示、IEEE 754 舍入模式、语言类型转换语义、边界溢出保护等一连串基础知识的交汇点。把这一个点真正吃透，很多和你相关的浮点、精度、类型转换问题都会跟着通。

我个人在实际项目里的习惯是：凡是涉及取整，先花十秒钟确认业务到底要的是哪种语义——向零、向下、向上、四舍五入，绝不靠猜。这十秒钟的确认，经常会帮我省下后来好几小时的排查时间。

最后分享一个小技巧：当你在新语言里写取整代码，拿不准它的int()或强转到底是向下还是向零时，最快的验证方法不是翻文档，而是在本地跑一下int(-1.7)。一秒钟出结果，永远不会骗你。记住这一招，你就能在任何语言里稳稳地把向零舍入写对。