round() 对 .5 采用远离零取整（如 round(-2.5)→-3），且 float/double 混用易出错；浮点数本身精度缺陷（如 0.1+0.2≠0.3）导致结果偏差；应包含、显式调用roundf()/round()、优先整数运算。
为什么
有时不按预期四舍五入？
因为
对“恰好落在 .5”的情况采用「远离零取整」规则（如
→ 3，
→ -3），而非传统数学中偶数优先的「银行家舍入」。更关键的是：它对
参数调用的是
，而
才是标准
；若混用类型又没包含
，可能隐式转换出错或链接失败。
实操建议：
务必
，且区分
/
类型——显式写
或
避免重载歧义
避免直接对浮点计算结果调用
，比如
可能返回 0 而非 1（因
实际是
）
若需精确控制（如金融场景），先乘以 10ⁿ 转整数再处理，例如保留 1 位小数四舍五入：
不是四舍五入，但能配合实现向下取整式舍入
永远向负无穷取整：
→ 2，
→ -3。它本身不四舍五入，但可用来构造「截断小数」或「向下舍入到指定位数」。
常见误用场景：
立即学习
“
C++免费学习笔记（深入）
”；
C知道
CSDN推出的一款AI技术问答工具
下载
想把
变成
却写了
—— 这确实等效于四舍五入正数，但
得 -4，而
是 -4，表面一样；但
=
= -2，而
= -3，行为已不同
用于整数除法模拟时，
在
和
同号时 ≈
（C++ 整除向零），但异号时结果不同（如
：C++
得 -2，
得 -3）
需要整数结果时，别忘了类型转换和溢出风险
和
返回值都是浮点类型（
或
），直接赋给
可能截断或触发未定义行为（超出
表示范围时）。
安全做法：
用
替代
，尤其当
可能很大
检查范围：若
可能 >
或
，应在调用
前做边界判断
对小数位数固定场景（如金额），优先用整数运算：把元换算成分，全程用
计算，彻底避开浮点舍入问题
跨平台与编译器差异：MSVC、GCC、Clang 的
行为一致吗？
标准 C++11 起，
行为在所有主流编译器上是一致的（IEEE 754 要求），但有两点实际差异需注意：
MSVC 在较老版本（如 VS2013）中对
参数的
可能调用不正确的内部函数，建议强制用
某些嵌入式平台或 freestanding 环境可能未实现
，需自行实现（如
）
（GCC/Clang）可能将
优化为不合规近似，生产环境禁用该选项
真正容易被忽略的，是浮点输入本身的精度缺陷——不是函数错了，而是你传进去的数，从一开始就没精确等于你想的那个小数。
round()round()round(2.5)round(-2.5)floatroundf()doubleround()#include floatdoubleroundf(x)round(x)round()round(0.1 + 0.2)0.1+0.20.30000000000000004static_cast(round(x * 10)) / 10.0 floor()floor()floor(2.9)floor(-2.1)3.74floor(3.7 + 0.5)floor(-3.7 + 0.5)round(-3.7)floor(-2.5 + 0.5)floor(-2.0)round(-2.5)floor(a / b)aba / ba=-7, b=3/floor(-7.0/3.0)round()floor()doublefloatintintstatic_cast(round(x)) (int)round(x)xxLLONG_MAX< LLONG_MINround()long longround()std::roundfloatround()roundf()round()x >= 0 ? floor(x + 0.5) : ceil(x - 0.5)-ffast-mathround()