C++里radix不是“进制”那么简单，epsilon也不是“精度”万金油

写C++时翻标准库文档，常撞见两个词：std::numeric_limits<T>::radix 和 epsilon()。初看像教科书里的概念——“radix是进制，epsilon是浮点最小差值”。但真在嵌入式做定点数转换、或调试金融计算中0.1+0.2≠0.3的bug时，才发现：它们根本不是静态常识，而是运行时行为的底层开关。

先说radix。它确实表示数值表示的基数，但关键在于：它不等于你写的字面量进制，而取决于硬件如何真正存储该类型。比如float在几乎所有现代平台（x86/ARM）上radix == 2，因为IEEE 754用二进制科学计数法存数。但别急着划重点——radix为10的浮点类型真实存在，比如C++23新增的std::decimal32（虽非所有编译器默认支持），它用十进制编码存小数，0.1就能精确表示。这时候radix == 10就不是理论值，而是直接影响operator<<输出是否“看起来对”、std::from_chars解析是否无损的关键参数。

更实际一点：如果你在写一个跨平台日志系统，需要把double转成字符串再传给嵌入式设备解析，而设备固件只接受十进制科学计数法（如1.23e-5），那光靠std::to_string可能出问题——它依赖本地radix和格式化策略。此时必须显式调用std::sprintf或std::to_chars并指定%e，否则在某些老DSP芯片（radix==16的扩展浮点）上，输出可能是十六进制指数形式，直接导致解析失败。

再说epsilon。它常被简化为“浮点类型能表示的最小正数”，这是典型误解。epsilon的准确定义是：1.0与大于1.0的下一个可表示浮点数之间的差值。也就是说，它只在1.0附近有意义；离1越远，相邻浮点数的间隔越大（因为浮点数是指数分布的）。float的epsilon约1.19e-7，但1e6f附近的最小可分辨差值其实是1e6f * epsilon ≈ 0.119——比你预想的大三个数量级。

这直接决定比较逻辑怎么写。写if (a == b)？危险。写if (abs(a - b) < epsilon)？错得更隐蔽——它假设误差恒定，而实际误差随数值尺度线性放大。正确做法是：

bool nearly_equal(float a, float b) {
    if (a == b) return true; // 处理±0、NaN等边界
    float diff = std::abs(a - b);
    float scale = std::max(std::abs(a), std::abs(b));
    return diff <= scale * std::numeric_limits<float>::epsilon();
}

注意这里用scale * epsilon，而非固定阈值。epsilon不是精度标尺，而是相对误差的缩放因子。

还有个常被忽略的细节：epsilon对整型毫无意义。std::numeric_limits<int>::epsilon()返回0，但这不是“整数无限精确”的证明——它只是标准规定未定义行为时的兜底值。若你误用epsilon去判断int运算溢出（比如if (a + b < std::numeric_limits<int>::epsilon())），代码不仅无效，还会掩盖真正的溢出检测逻辑（应改用std::add_overflow或检查符号位）。

回到radix的延伸影响：它和digits共同决定类型的实际表达能力。digits表示radix进制下有效数字位数（如float通常digits==24，即24位二进制有效位）。那么radix==2时，能精确表示的十进制整数上限是2^24 = 16777216；超过这个数，连续整数开始“跳号”。这解释了为什么用float存时间戳毫秒值，在1677万之后每两次加法就丢1ms——不是计算错误，是存储容量到了。

最后给个硬核提醒：不要在模板中无条件依赖epsilon。比如泛型函数template<typename T> T safe_sqrt(T x)里写if (x < std::numeric_limits<T>::epsilon()) return T{0};，当T是long double且平台用x87扩展（radix==2, digits==64）时，epsilon极小（约1e-19），但输入x可能是用户传入的1e-10——逻辑就崩了。此时应结合x的量纲设计阈值，或用std::isnormal(x)替代。

C++的数值极限不是数学常量表，而是硬件契约的快照。radix告诉你机器怎么记数，epsilon告诉你机器在哪儿开始“凑合着算”。理解它们，不是为了背诵标准条款，而是当你看到0.1f + 0.2f == 0.30000001192092896时，能立刻判断：这不是bug，是radix==2下的必然；而修复方案，从来不在加大epsilon容忍度，而在换用std::decimal32，或重构为整数比例运算。

下次调试浮点异常，先查radix和digits，再看epsilon——它们不是答案，但指明了问题真正的坐标系。