直接用 == 比较浮点数会出错，因为浮点数在内存中是二进制近似表示，0.1+0.2≠0.3等误差是ieee 754标准下的必然现象，需用 std::abs(a – b)
为什么直接用
==比较两个Float或double会出错浮点数在内存中是二进制近似表示的，很多十进制小数（比如
0.1）根本无法精确存储。哪怕你只是做几次加减乘除，结果也可能和“数学上相等”的值差一个极小的量——这个差值不是bug，是IEEE 754标准下的必然现象。所以
a == b在绝大多数浮点场景下都是危险的：它要求比特位完全一致，而实际计算路径不同、编译器优化级别不同、甚至不同CPU指令集（如x87 vs SSE）都可能导致结果微异。
- 常见错误现象：
0.1 + 0.2 == 0.3返回false- 使用场景：数值迭代收敛判断、单元测试断言、配置阈值比较
- 性能影响：几乎为零；但滥用大
epsilon会掩盖真实误差
std::abs(a - b) 是最常用解法，但 <code>epsilon怎么选固定值
epsilon（比如1e-6）只适用于数量级接近1.0的数。一旦a和b是1e-10或1e6级别，同一epsilon就会失效：太大会误判，太小则永远不触发。更稳妥的做法是用相对误差 + 绝对误差组合判断，覆盖极小值和常规值：
立即学习“C++免费学习笔记（深入）”；
bool nearly_equal(double a, double b, double abs_eps = 1e-12, double rel_eps = 1e-9) { double diff = std::abs(a - b); if (diff < abs_eps) return true; return diff < rel_eps * std::max(std::abs(a), std::abs(b)); }
abs_eps防止除零和极小值下相对误差爆炸（比如两个接近0.0的数）rel_eps控制相对精度，1e-9对double通常够用，float可用1e-5- 不要直接用
std::numeric_limits<double>::epsilon()</double>做比较阈值——它表示的是1.0附近的最小可表示差值，不是通用容差哪些情况不能只靠
epsilon解决当浮点运算本身引入了不可控误差积累，或涉及特殊值时，
epsilon比较就只是第一道防线，后面还得补逻辑。
NaN：任何与NaN的比较（包括==和）都返回 <code>false，必须先用std::isnan()检查- 无穷大：
std::isinf()单独处理，避免abs(inf - inf)得到NaN- 跨平台一致性需求：如果代码要跑在 ARM 和 x86 上，且对中间结果精度敏感，得禁用 FMA（融合乘加）或统一用
-ffp-contract=off编译- 算法层面问题：比如牛顿法求根时，用
epsilon判断收敛，但若导数接近零，迭代可能停滞在错误位置——这时需要额外检查梯度模长单元测试里怎么写安全的浮点断言
Google Test 提供
ASSERT_NEAR和ASSERT_DOUBLE_EQ，但它们内部用的是固定epsilon，对非单位量级数据不鲁棒。自己封装一层更可控。示例（GTest 风格）：
void EXPECT_NEAR_REL(double a, double b, double rel_eps = 1e-9) { ASSERT_FALSE(std::isnan(a) || std::isnan(b)) << "NaN in comparison"; double diff = std::abs(a - b); double scale = std::max({1.0, std::abs(a), std::abs(b)}); EXPECT_LT(diff, rel_eps * scale) << "Expected " << a << " ~ " << b; }
- 测试前主动过滤
NaN，避免断言崩溃或静默失败- 把
scale下界设为1.0，既保留对小数的绝对容差，又不让rel_eps在大数上过度放宽- 别在 CI 脚本里用
std::cout 调试——输出精度高不代表值精确，反而容易误导真正难的从来不是写对一个
epsilon，而是搞清你的误差来源：是舍入？是算法固有？还是输入本身就不确定？后者往往该换数据结构，而不是调epsilon。
