直接用 == 比较两个 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是 1.0 附近的最小可分辨差，不是通用容差；对::epsilon() 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 该取多大、在哪一层做归一化、要不要提前截断输入、以及团队里所有人都得避开用浮点数做逻辑分支或索引——这些细节一旦漏掉一个，问题就会在某个特定数据组合下突然爆发。
