round()本身不慢，问题在于浮点数二进制表示导致输入值失真，如0.295实际存为0.29499999999999998，乘100后round得29而非30；解决方法是加极小偏移量（如1e-9）再缩放。
round() 本身不慢，但直接用它做小数位四舍五入常出错——根本问题不在函数，而在输入值因浮点表示失真。比如 0.295 存成 0.29499999999999998，乘 100 后是 29.499999999999996，round() 自然得 29。
为什么 round(x * 100) 有时返回错值？
浮点数二进制无法精确表达多数十进制小数，误差在放大阶段被放大。不是 round() 有问题，而是你传给它的数已经“矮了半截”。常见现象包括：
-
round(0.295 * 100)得29.0，而非预期的30.0 -
round(1.005 * 100)得100.0（实际存储为100.49999999999999） - 用
pow(10, n)缩放时，pow(10, 2)可能返回99.99999999999999，进一步加剧误差
解决思路不是换函数，而是让输入更“结实”：加一个极小偏移量，把那些卡在边界下的值轻轻托上去。
保留 N 位小数的安全写法
固定位数（如 2 位）推荐硬编码倍数，避免 pow()；动态位数则需控制偏移量大小。关键点：
立即学习“C++免费学习笔记（深入）”；
- 用
100.0而非100，防止整数除法截断 - 偏移量选
1e-9适用于 |x| < 1e6 的场景；若处理大数（如传感器原始值 ×1e6），偏移应按比例放大，例如1e-3 - 对
float类型，优先用roundf()+100.0f，避免 float→double→float 的隐式转换损失
示例（保留 2 位）：
double x = 0.295; double rounded = round(x * 100.0 + 1e-9) / 100.0; // → 0.30
lround() vs static_cast<int>(round())
当目标是整数结果时，别用 C 风格强转：(int)round(x) 在溢出时行为未定义，且绕过异常检查。正确选择：
- 用
lround(x)：返回long，输入超范围时抛FE_INVALID异常（可配合std::feclearexcept()+std::fetestexcept()捕获） - 日常小范围数值（±10⁵ 内），
static_cast<int>(lround(x))最简明安全 - 若已知 x 不会溢出且追求极致性能（如内循环），可考虑整数运算替代方案，例如对
a / b四舍五入：a / b + ((a % b) * 2 >= b ? 1 : 0)，全程无浮点、无精度损失
负数与银行家舍入不是默认行为
round() 永远是 “away from zero”：即 round(-2.5) → -3.0，不是 -2.0。这没问题，是 IEEE 754 标准。但如果你需要“四舍六入五成双”（银行家舍入），round() 不适用：
- 改用
std::nearbyint(x, FE_TONEAREST)（需先设舍入模式） - 或手动实现：判断小数部分是否恰好为 0.5，再查整数部分奇偶性
- 注意：所有基于浮点的银行家舍入都受精度误差干扰，真正严谨的金融计算应使用定点数或十进制浮点库
最易被忽略的一点：偏移量不是万能胶——它只在输入值离理想边界足够近时有效；若原始浮点误差超过偏移量（如某些极端平台或编译器开启 -ffast-math），仍可能失败。此时必须回归整数逻辑或专用数值类型。
