round()按“远离零”规则四舍五入，但浮点误差导致如0.295×100实际为29.499…，故round得29；安全做法是round(x×10ⁿ+1e-9)/10ⁿ。
为什么 round() 有时不按预期四舍五入？
C++ 标准库的 round() 确实做四舍五入，但它遵循“舍入到最近的整数，平局时向远离零的方向舍入”规则。这意味着 round(2.5) 得 3，round(-2.5) 得 -3 —— 这和数学课上教的“四舍六入五成双”不同，也和部分人默认的“五总向上”不一样。
常见错误现象：
- 用
round(1.5f)期望得 2（没错），但round(2.5f)得 3（也没错），可一旦涉及浮点误差，比如round(0.295 * 100)，结果可能是 29 而非 30 - 在金融或显示场景下，用户期待“五入”，但实际输入值因二进制表示不精确，变成略小于 2.5 的数（如 2.4999999），
round()就向下取了
关键原因：
- 浮点数无法精确表示大多数十进制小数，
0.295存入double后实际是约0.29499999999999998 -
round()对这个“假 0.295”乘 100 后得到 29.499…，再round()就是 29
所以别怪 round()，要怪输入本身就不够“干净”。
立即学习“C++免费学习笔记（深入）”；
如何安全地对小数位做四舍五入（比如保留两位）？
核心思路不是靠 round() 单打独斗，而是先放大、再舍入、再缩回，并在放大前加一个极小偏移来对抗浮点误差。
使用场景：格式化输出、价格计算、传感器数据修约
实操建议：
- 对
double x保留n位小数，用round(x * pow(10, n) + 1e-9) / pow(10, n) - 更稳妥写法（避免
pow开销和精度问题）：手动构造倍数，如保留 2 位就乘 100.0 - 加
1e-9是为了把那些因浮点误差“卡在边界下”的值轻轻托上去，比如把 2.999999999999999 变成 3.000000000000000，让round()正确触发
示例：
double x = 0.295; double rounded = round(x * 100.0 + 1e-9) / 100.0; // 得 0.3注意：
1e-9 不是万能的，它只适用于绝对值不太大的数（|x| 左右）。如果处理极大数，偏移量要相应调整，否则可能被舍入淹没。
<h3>
<code>floor() 和 ceil() 在四舍五入里怎么配合？
它们本身不做四舍五入，但可以组合出“向上取整到某一位”或“向下截断”，常用于实现“进一法”或“去尾法”，而不是标准四舍五入。
参数差异与陷阱：
-
floor(2.9)→ 2，floor(-2.1)→ -3（向下，即更小方向） -
ceil(2.1)→ 3，ceil(-2.9)→ -2（向上，即更大方向） - 它们返回
double，不是整数类型，别直接当int用，尤其大数时会溢出或丢失精度
常见误用：
- 用
floor(x + 0.5)代替round(x)：对正数看似可行，但floor(-2.5 + 0.5) == floor(-2.0) == -2，而round(-2.5)是 -3，行为不一致 - 想“保留一位小数后向上进位”，写成
ceil(x * 10) / 10，但没加偏移，遇到x == 0.025（存为 0.024999…）就会错成 0.0
所以除非明确需要“无条件向上/向下”，否则别用 floor/ceil 替代 round；真要用，也要加偏移防浮点坑。
编译器和标准库版本会影响 round() 行为吗？
不会改变语义，但会影响底层实现细节和极端值处理。
性能影响：
-
round()在支持 SSE4.1 的 x86_64 上通常编译为单条roundsd指令，很快 - 旧平台或嵌入式（如 ARM Cortex-M0）可能走软件实现，慢一个数量级
兼容性注意点：
- C++11 起才保证
std::round可用；C++98/03 需用roundf/round/roundl或宏 - 某些老 libc（如 uClibc）可能没实现
round()，链接时报undefined reference to 'round' - Windows MSVC 2015+ 支持完整 C++11 数学函数，但早期版本需定义
_USE_MATH_DEFINES并包含<cmath></cmath>
最易被忽略的一点：round() 对 NaN、无穷大会返回原值，不抛异常。如果你的输入可能来自文件解析或网络，没做校验就直接 round(nan_value)，后续逻辑可能静默出错——这点比四舍五入规则本身更值得盯紧。
