C++里 fmod 不是“取余”，是“截断式余数”——别再用它算角度或周期了

刚接手一个老项目，发现一段代码用 fmod(x, 360.0) 处理角度归一化，结果在 x = -450.0 时返回 -90.0，而不是预期的 270.0。测试一跑，UI 上指针直接反向打转。这不是 bug，是 fmod 的本性使然——它压根不承诺返回非负结果。

C++ 标准库里的 fmod 常被误当作“浮点版 %”，但 % 是整数取模，而 fmod 是带符号截断的浮点余数函数。它严格遵循 IEEE 754 定义：fmod(a, b) 返回 a - n * b，其中 n 是 a/b 向零取整（truncation）后的整数。关键就在这“向零取整”四个字——它不看数学意义，只看符号对齐。

举个例子：
fmod(7.5, 2.0) → 7.5 / 2.0 = 3.75 → 向零取整得 3 → 7.5 - 3 * 2.0 = 1.5 ✅
fmod(-7.5, 2.0) → -7.5 / 2.0 = -3.75 → 向零取整还是 -3 → -7.5 - (-3) * 2.0 = -1.5 ❌（很多人想要 0.5）

看到这里，你大概明白了：fmod 的符号永远和被除数 a 一致。这在物理建模、信号处理中有时是优势（比如保留相位偏移方向），但在大多数日常场景——角度归一、时间循环、索引映射——它反而成了陷阱。

那什么时候该用 fmod？
✅ 需要保持原始符号语义：比如计算某力矩在轴向的残留分量，负值本身有意义；
✅ 和硬件浮点单元行为对齐（某些嵌入式平台要求严格 IEEE 兼容）；
✅ 已有算法明确依赖其向零截断特性（如某些数值积分器）。

但如果你只是想把 -450° 变成 270°，或者把 -1.7s 映射到 [0, 1.0) 区间做动画插值，fmod 就不是解药，而是引子。

真正管用的是 std::remainder。它用的是就近舍入（round-to-nearest-even）：remainder(a, b) 中的 n 是 a/b 四舍五入到最近整数的结果。于是：
remainder(-7.5, 2.0) → -7.5 / 2.0 = -3.75 → 四舍五入为 -4 → -7.5 - (-4)*2.0 = 0.5 ✅
remainder(7.5, 2.0) → 3.75 → 四舍五入为 4 → 7.5 - 4*2.0 = -0.5 ——注意，它也可能为负，但绝对值更小。

不过，remainder 依然不保证非负。要得到 [0, b) 区间的标准余数？得手动兜底：

double positive_mod(double a, double b) {
    double r = std::fmod(a, b);
    return r >= 0.0 ? r : r + b;
}

这段代码短小，但藏着两个硬经验：
第一，必须用 fmod 而非 remainder 做基础计算——因为 remainder 在 a/b 恰好为半整数时（如 5.0/2.0=2.5）会向偶数舍入，导致 remainder(5.0, 2.0) 返回 1.0 还是 -1.0 取决于实现细节，而 fmod 行为确定；
第二，加 b 时要防 b 为负——实际工程中建议先 b = std::abs(b)，否则逻辑翻车。

还有个隐形坑：fmod 对无穷大和 NaN 的处理。fmod(INFINITY, 1.0) 返回 NaN，而 fmod(1.0, 0.0) 是未定义行为（通常触发 FE_DIVBYZERO）。线上服务若没做输入校验，可能悄无声息崩掉某个线程。任何进 fmod 的变量，都该过一遍 std::isfinite()——这不是过度防御，是吃过亏后的肌肉记忆。

顺带提一句，C++23 引入了 std::modulo（位于 <utility>），它才是正统的“非负余数”函数，语义等价于 a - floor(a/b) * b。但它要求 b > 0，且目前主流编译器支持度有限。现阶段，手写 positive_mod 仍是跨平台最稳的选择。

最后说个真实调试故事：某音频插件用 fmod(time, period) 做波形循环，当 time 因浮点累积误差变成 period * 1e8 + 1e-15 级别时，fmod 返回极小负值（-1e-15），触发了静音逻辑。修复方案不是改算法，而是把 fmod 换成 std::remainder + 符号修正，并在入口加 std::fma 补偿累积误差。工具没有高下，只有是否匹配问题域。

fmod 不是错的函数，它只是太诚实——诚实到照见我们对“余数”的日常直觉有多模糊。下次敲下 #include <cmath> 时，不妨停半秒：我要的，究竟是数学余数、工程余数，还是符号保真的中间值？答案不同，函数就该不同。