直接比较浮点数大概率出错，因其二进制近似表示导致0.1+0.2实际为0.30000000000000004而非精确0.3，故==判断常失败，引发逻辑错误、测试飘红等问题。
为什么 == 直接比较浮点数大概率出错
因为浮点数在内存中是二进制近似表示，像 0.1 + 0.2 实际存的是 0.30000000000000004，不是数学意义上的 0.3。直接用 == 判断相等，几乎总会在看似“应该相等”的地方失败。
常见错误现象：if (a == b) 返回 false，哪怕打印出来都是 0.3；单元测试随机飘红；逻辑分支意外走错。
- 别依赖输出格式（
std::cout 看着一样 ≠ 内存值一样） - 编译器优化（如
-ffast-math）可能让同一段代码在不同构建下表现不一致 -
float和double混用时，隐式转换会放大误差，比如float f = 0.1f; double d = f;已经失真一次
用 std::abs(a - b) 是最常用解法
核心思路：不问“是否完全相等”，而问“差得够不够近”。这个“够近”的阈值叫 epsilon，选对它比写逻辑还关键。
使用场景：判断两个计算结果是否落在同一数值区间，比如几何碰撞检测、数值迭代收敛判定、测试断言。
立即学习“C++免费学习笔记（深入）”；
- 绝对误差适用：当
a和b都在同一个数量级（比如都在[-1, 1]附近），用固定小值如1e-6或1e-9 - 相对误差更鲁棒：当数值可能很大或很小（比如
1e20或1e-20），推荐用std::abs(a - b) ，但要注意 <code>a为0时要单独处理 - C++20 起可直接用
std::is_close（需#include <cmath></cmath>），它内部做了零值保护和相对/绝对混合判断
示例：
double a = 0.1 + 0.2; double b = 0.3; bool equal = std::abs(a - b) < 1e-10; // true
std::numeric_limits<double>::epsilon()</double> 不是万能的
很多人一搜就抄 std::numeric_limits<double>::epsilon()</double>，但它只表示 1.0 附近的最小可分辨差值（约 2.2e-16），**不是通用容差**。
参数差异明显：它随数值变大而变大——2.0 附近的可分辨差是 2 * epsilon，100.0 附近就是 100 * epsilon。直接拿它当全局 epsilon 用，等于在 1e8 级别的数上要求精度达到 1e-8，大概率失败。
- 它不能用于判断
0.0附近是否为零（0.0 + epsilon还是0.0？） - 它不处理次正规数（subnormal numbers）的精度塌缩问题
- 多步运算后误差累积远超单个
epsilon，比如连续加 1000 次0.1，误差可能到1e-13量级
实际项目里怎么选容差值
没有银弹，得看你的数据来源和业务容忍度。传感器读数、用户输入、物理仿真、金融计算，各自能接受的偏差天差地别。
性能影响极小，但选错值会让整个逻辑不可靠。关键是把容差当成一个**有业务含义的配置项**，而不是魔法数字。
- 从输入源头估算：如果原始数据只精确到小数点后 2 位（如温度计显示
25.34°C），容差设成1e-2就够了，再小没意义 - 用测试反推：写一组已知应判为“相等”的样例，从小往上调
epsilon直到全过，再留 1–2 个数量级余量 - 避免硬编码：定义为
constexpr double kFloatTolerance = 1e-6;，并在注释里写清依据（比如“对应 0.001mm 机械公差”）
最常被忽略的一点：**同一个项目里不同模块可能需要不同容差**。坐标比较用 1e-6，时间戳比较用 1e-3，财务金额必须用定点数或整数分——混用一套 epsilon 是很多诡异 bug 的根源。
