浮点数比较必须用带精度的断言，裸写==几乎总是错的，因IEEE 754二进制表示存在固有精度损失（如0.1+0.2≠0.3），且编译器优化、平台差异等会放大偏差；iOS应使用XCTAssertEqualWithAccuracy，Pytest用pytest.approx，JUnit需借助AssertJ等第三方库；误差值须为正、匹配数值量级，避免整数隐式转换、单位混淆或未mock随机源。
浮点数比较必须用带精度的断言，裸写 == 几乎总是错的。
为什么 == 不能直接用于浮点数断言
二进制浮点表示存在固有精度损失，比如 0.1 + 0.2 在大多数语言中不等于 0.3，而是 0.30000000000000004。用 == 比较会直接失败，即使业务上完全合理。
- 这不是“四舍五入问题”，是 IEEE 754 表示法的必然结果
- 编译器优化、中间计算顺序、平台差异都可能放大这种偏差
- 测试失败信息里只显示两个“看起来一样”的数字，很难快速定位是真 bug 还是精度陷阱
XCTAssertEqualWithAccuracy 在 iOS 单元测试中的正确用法
iOS 的 XCTest 提供了专为浮点设计的断言，XCTAssertEqualWithAccuracy 是唯一推荐方式，它接受三个参数：实际值、预期值、允许误差（accuracy）。
- 误差值必须是正数，且应与被测数值量级匹配：比如结果在
1e-3级别，就别用1e-10当 accuracy - 不要传
0或负数——这会导致断言逻辑异常，甚至崩溃 - 对
CGFloat、double、float都适用，但不能用于整型或对象 - 示例：
XCTAssertEqualWithAccuracy(result, 3.14159, 0.0001, @"pi approximation");
Pytest 和 JUnit 中的等效替代方案
不同框架语义一致，但函数名和调用方式不同，混用容易出错。
- Pytest：用
assert actual == pytest.approx(expected, abs=tolerance)，abs参数即绝对误差；不加abs默认用相对误差，易误判小数值 - JUnit 5：没有内置近似断言，需引入
org.junit.jupiter.api.Assertions#assertAll+ 手动差值判断，或改用第三方如 AssertJ 的assertThat(actual).isCloseTo(expected, within(tolerance)) - 注意：
assertAlmostEqual（Python unittest）已弃用，Pytest 不支持该函数名
容易被忽略的边界情况
精度断言看似简单，但真实场景常因以下原因失败：
- 误差范围设得比计算过程本身的累积误差还小——比如做了多次乘除后，单次
0.001的 tolerance 可能不够 - 把整数当浮点传入：iOS 中传
5而不是5.0给XCTAssertEqualWithAccuracy，会触发隐式类型转换警告甚至编译错误 - 测试数据本身含随机性（如时间戳参与计算），导致每次运行结果浮动——必须先 mock 时间源，再断言，否则精度断言只是掩盖不确定性
- 单位不一致：预期值是毫秒，实际值是秒，却用同一 tolerance 比较，数值差 1000 倍
