round() 返回奇怪值主因是浮点精度误差，如2.5存为2.4999999999999996导致结果为2；应加1e-9偏移或改用整数运算避免精度问题。
为什么 round() 有时返回奇怪的值？
因为 round() 接收 double，传入 int 不会出错但毫无意义；真正容易翻车的是浮点数精度问题——比如 round(2.5) 理论上该是 3，但若 2.5 实际存储为 2.4999999999999996（IEEE 754 表示误差），结果就是 2。
- 必须确保输入是足够精确的浮点值，或先加一个极小偏移（如
1e-9）再round() - 对整数直接四舍五入无需求：它本来就是整数，
round(5)还是 5 - 头文件别漏掉：
#include <cmath></cmath>，否则链接失败或调用到旧 C 版本行为不一致
round() 和 lround() 怎么选？
关键区别在返回类型：round() 返回 double，lround() 直接返回 long。如果你最终要赋给 int 变量，用 lround() 更安全，避免隐式转换溢出或截断。
- 当输入可能超出
int范围（比如大浮点数），lround()会抛FE_INVALID异常（需std::feclearexcept(FE_ALL_EXCEPT)+ 检查） - 日常小范围数值（±10⁵ 内），
static_cast<int>(lround(x))</int>是最简明写法 - 不要用
(int)round(x)：C 风格强转绕过异常检查，溢出时行为未定义
负数四舍五入怎么不是“向零取整”？
C++ 的 round() 遵循 IEEE 754 “round half away from zero”，即 -2.5 → -3，2.5 → 3。这不是 bug，是标准行为。如果你想要“四舍五入到最近整数，.5 时向偶数靠拢”（银行家舍入），得用 std::nearbyint() 或手动实现。
-
round(-2.5)结果是-3.0，不是-2.0 - 需要向零取整（即
trunc()行为）+ .5 偏移：可用(x >= 0 ? round(x) : -round(-x))，但更推荐直接用std::lrint(x)配合舍入模式控制 - 编译器可能对
round()做内联优化，但若开启-ffast-math，行为可能被改变，慎用
int 到 int 的“四舍五入”根本不用 round()
如果原始数据就是 int，所谓“四舍五入”其实是逻辑误解。例如想把 a / b 的整数除法结果四舍五入，正确做法是：(a + b/2) / b（正数场景），或更通用的 (a + (b > 0 ? b/2 : b/2)) / b —— 这比转 float 再 round() 更快、无精度损失、不依赖浮点单元。
立即学习“C++免费学习笔记（深入）”；
- 整数运算全程无浮点，避免了
double表达不了大整数（如int64_t超过 2⁵³）的问题 - 注意
b/2是整除，所以a + b/2要防溢出；安全写法是a / b + ((a % b) * 2 >= b ? 1 : 0) - 现代 CPU 上整数除法代价仍高，但比浮点转换 +
round()+ 回转整数稳定得多
浮点 round() 看似简单，但一旦涉及负数、大数、性能敏感路径或嵌入式环境，整数原生方案往往才是真解。别让“看起来像四舍五入”的函数掩盖了实际数据类型和语义。
