Number.EPSILON不能直接用于所有浮点比较，因其值≈2.22e-16仅表征1附近的最小可表示间隔，对远大于1（如1e10）的数过小、对极小数（如1e-20）又过大，导致相对误差判断失准。
直接用 === 判断浮点数相等几乎总是错的；Number.EPSILON 不是万能阈值，它只在数值接近 1 时合理有效，用错场景反而放大误差。
为什么 Number.EPSILON 不能直接用于所有浮点比较
Number.EPSILON 的值是 2.220446049250313e-16，它本质是「1 与大于 1 的最小可表示双精度数之差」，反映的是 1 附近的相对精度极限。一旦数值远大于 1（如 1e10），这个固定值就比实际可分辨的最小差异小好几个数量级——此时差值可能远超 Number.EPSILON，但数学上仍应视为相等。
反过来，若数值极小（如 1e-20），Number.EPSILON 又会大得离谱，导致本该区分的两个数被误判为相等。
- 错误写法：
Math.abs(a - b) —— 这只对 <code>a和b都在 0.5～2 范围内勉强可用 - 更糟的是混用：比如拿它去比较
1000000.1 + 0.2和1000000.3，结果必错 - 注意：
Number.EPSILON不是“全局最小误差”，也不是“安全比较阈值”，它只是参考基准
什么时候该用绝对误差，什么时候该用相对误差
判断依据不是“想不想精确”，而是你正在处理的数值量级和业务容忍度。
- 绝对误差适用场景：
a或b接近 0，或业务要求固定容差（如 UI 动画位移 ≤ 0.001px 就认为到位）
→ 用类似Math.abs(a - b) 的固定阈值 - 相对误差适用场景：
a和b都显著远离 0（比如 ≥ 0.1），且你关心的是“相对偏差是否在可接受比例内”
→ 推荐公式：Math.abs(a - b) - 混合策略更稳妥：先取绝对差，再与
Number.EPSILON * Math.max(1, Math.abs(a), Math.abs(b))比较，兼顾大小数边界
常见错误现象与对应修复示例
这些不是理论问题，是真实调试中高频出现的坑：
-
0.1 + 0.2 === 0.3返回false→ 改用：Math.abs((0.1 + 0.2) - 0.3) （此处可行，因数值在 1 附近） -
1e12 + 1 === 1e12返回true（JS 自动舍入）→ 此时Number.EPSILON完全失效，必须用更大阈值或换BigInt处理整数部分 -
withinErrorMargin(0, 1e-18)返回true（若只用相对误差）→ 因分母为 0 或极小，导致容差坍缩，必须加Math.max(1e-18, ...)防御 -
Decimal('0.1') + Decimal('0.2') === Decimal('0.3')是对的，但Decimal(0.1)是错的 → 字符串入参是硬性要求，否则 float 先污染精度
真正需要高精度时，别硬扛浮点数
如果你的场景涉及金融计算、单位换算、科学常量比对，或者任何「差一位小数都不能接受」的逻辑，Number.EPSILON 只是补丁，不是解药。
- 显示层用
toFixed()或Intl.NumberFormat，但仅限输出，别拿结果做计算 - 运算层优先考虑
Decimal（Python/JS）、BigDecimal（Java）、或手动缩放为整数：Math.round(x * 100) / 100（注意四舍五入陷阱） - Node.js 中可结合
BigInt做无损整数运算，但需自行管理小数位数，且不兼容Math系列函数
最易被忽略的一点：很多人把 Number.EPSILON 当成“JS 浮点数精度开关”，其实它连开关都不是——它只是告诉你，在 1 附近，误差小到这个程度，就可以停了。
