C++解决浮点数精度丢失问题 _ 比较两个double是否相等技巧【详解】

直接用 == 比较两个 double 几乎总是错的，因为 0.1 等十进制小数在 IEEE 754 double 中无法精确表示，导致计算结果存在微小误差，如 0.1 + 0.2 != 0.3。

先说一个核心判断：直接用 == 比较两个 double，在绝大多数情况下都是错的。这不是你代码写错了，而是 0.1 在内存里根本存不准——它被截断成二进制近似值后，两次计算哪怕路径稍有不同，结果就可能落在相邻的两个可表示浮点数上。

为什么 a == b 在浮点数里不可靠

IEEE 754 double 只有 52 位尾数，能精确表示的十进制小数屈指可数。像 0.1 + 0.2 和 0.3 这两个值，在内存中是两个不同的 bit 模式，== 判断自然为 false。这不是 bug，是标准行为。

• 常见错误现象：0.1 + 0.2 == 0.3 返回 false；循环累加 10 次 0.1 得到 0.99999999999999989 而非 1.0
• 别信打印出来的值：用 std::cout 或 printf("%.17g", x) 才能看到真实存储值
• std::numeric_limits::epsilon() 是 1.0 附近的最小可分辨差，不是通用容差；对 1e10 量级的数，它连最低有效位都覆盖不到

用什么阈值判断“足够接近”

没有万能 eps。选错阈值会导致漏判（该相等的说不等）或误判（该不等的说相等）。关键看数值量级和使用场景：

• 绝对误差适用场景：数值范围已知且集中，比如 UI 坐标、小范围物理模拟参数
  示例：std::abs(a - b) < 1e-6（double 下常用起点）
• 相对误差更稳健：std::abs(a - b) / std::max(std::abs(a), std::abs(b)) < 1e-12，但需先处理零值和 NaN
• 混合策略最实用：std::abs(a - b) < (std::max(std::abs(a), std::abs(b)) * 1e-12 + 1e-12)，兼顾大小数
• 涉及 NaN 时，== 和任何比较都返回 false，必须先调 std::isnan(a) || std::isnan(b)

别把浮点数当 key 或控制循环变量

哈希表用 double 当 key？循环条件写 while (x != 1.0)？这两类操作在工程中基本等于埋雷。

• 哈希冲突或查不到：两个“数学相等”的 double 因舍入路径不同，哈希值可能不同
• 无限循环风险：比如 for (double x = 0.0; x != 1.0; x += 0.1)，最后一步可能跳过 1.0 直接变成 1.0000000000000002
• 正确做法：用整数计数器控制循环，再映射为浮点值；key 改用整数缩放（如价格存“分”）、字符串序列化或自定义比较器
• 输入解析阶段就可能丢精度：JSON 中的 "price": 19.99 经 std::stod 解析后已不是精确的 1999/100，应优先解析为字符串再转整数

输出格式 ≠ 存储精度

std::fixed 和 std::setprecision 只改显示，不改内存里的值。你以为打印出 0.30 就“修复”了，其实参与下一轮计算的还是那个不等于 0.3 的数。

• 真要四舍五入参与后续计算，得显式调 std::round(x * 100.0) / 100.0（注意负数 std::round 向远离零取整）
• 金融等零误差场景，别碰 float/double：用 int64_t 存“分”，或 boost::multiprecision::cpp_dec_float_50
• long double 不跨平台：Linux GCC 下可能是 80 位扩展精度，Windows MSVC 下常退化成 double，CI 环境容易出幺蛾子

真正难的不是写个 abs(a-b) < eps，而是判断这个 eps 该取多大、在哪一层做归一化、要不要提前截断输入、以及团队里所有人都得避开用浮点数做逻辑分支或索引——这些细节一旦漏掉一个，问题就会在某个特定数据组合下突然爆发。