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