Redis INCRBYFLOAT 返回的小数为什么难以直接比较

Redis 的 INCRBYFLOAT 看起来是在“给小数加一个数”，但成功后的返回值本质上是更新值的字符串表示。它会去掉不必要的尾随零，因此 1.0、1.00 和返回的 1 不能靠文本格式判断业务精度；而把解析后的二进制浮点数直接用 == 比较，也可能得到意外结果。

先把 Redis 返回值当成数值语义处理，再决定比较策略：一般比例可以使用明确的容差，金额和固定刻度计量优先换算成最小单位整数。

官方地址：https://redis.io/docs/latest/commands/incrbyfloat/

下面只讨论命令返回格式、Go 侧的比较边界和精度落地方式，不把这个问题扩展成 Redis 事务或分布式计数设计。

INCRBYFLOAT 返回的是字符串结果

INCRBYFLOAT key increment 会读取键中表示浮点数的字符串，加上增量，再把新值写回同一个键。键不存在时，Redis 会先按零处理；如果原值、增量或键类型不符合要求，命令返回错误。

# 用命令行观察返回值的文本形态；这里的输出是示意，不代表固定终端截图
redis-cli SET quota 10.50
redis-cli INCRBYFLOAT quota 0.1
redis-cli GET quota

# 负增量表示递减，返回值仍然是字符串形式
redis-cli INCRBYFLOAT quota -5

官方文档规定，成功结果以 bulk string 返回；计算后的数字会采用稳定的十进制格式，并移除尾随零。也就是说，调用方收到的是类似 10.6 的文本，而不是携带“原来保留两位小数”元数据的金额对象。

为什么看起来相同的小数不能直接按文本比较

第一类误判来自文本格式。1、1.0 和 1.00 对数值比较可能相等，对字符串比较却不相等；反过来，10.60 经过 Redis 处理后可能变成 10.6，这不代表精度丢失，只代表显示格式被规范化。

第二类误判来自二进制浮点。许多十进制小数不能被二进制浮点精确表示，两个本应相同的计算结果在内存中的近似值可能相差一个很小的量。因此下面这种写法只适合已经确认结果是可精确表示的简单场景：

// 直接比较浮点数可能把表示误差误认为业务差异。
if left == right {
    fmt.Println("相等")
}

第三类问题是输入错误：键里存了普通文本、增量不是合法浮点数、键实际是 List 或 Hash，都会让命令失败。错误和“结果不相等”是两条不同路径，不能只把所有返回内容当作数字继续解析。

用 Go 解析并按容差比较

如果数据确实是比例、温度或其他允许小误差的测量值，可以先把 Redis 的字符串结果解析为 float64，再用绝对误差与容差比较。容差不能凭感觉写成一个通用常数，应由业务允许的最小差异决定。

package main

import (
    "fmt"
    "math"
    "strconv"
)

// nearlyEqual 把容差显式放在调用处，避免用 == 放大浮点表示误差。
func nearlyEqual(leftText, rightText string, tolerance float64) (bool, error) {
    // Redis 成功返回的是字符串，先校验解析错误再参与数值计算。
    left, err := strconv.ParseFloat(leftText, 64)
    if err != nil {
        return false, fmt.Errorf("parse left value: %w", err)
    }
    right, err := strconv.ParseFloat(rightText, 64)
    if err != nil {
        return false, fmt.Errorf("parse right value: %w", err)
    }
    if math.IsNaN(left) || math.IsNaN(right) || math.IsInf(left, 0) || math.IsInf(right, 0) {
        // NaN 和无穷值不应混入普通测量值的相等判断。
        return false, fmt.Errorf("non-finite value")
    }
    if tolerance 

这段代码只展示应用侧判断，不改变 Redis 的存储规则。若两次读到的文本来源不同，还应先明确是否允许不同格式代表同一数值；对计费、库存或结算类数据，容差比较通常不是最稳妥的模型。

金额和固定刻度数据怎样避免直接比较

金额最常见的做法是约定最小单位，例如把 12.34 元保存为 1234 分，让 INCRBY 处理整数增量。温度、比例或计量值也可以选定固定刻度，例如千分之一作为一个整数单位。这样比较时是整数比较，展示时再除以刻度格式化。

# 金额按分保存，增量也必须使用分；这样比较不依赖浮点格式
redis-cli SET balance_cents 1234
redis-cli INCRBY balance_cents 25
redis-cli GET balance_cents

# 读取到 1259 后，在应用层格式化为 12.59 元

固定刻度方案的关键不是“把数字乘一个 100”这么简单，而是把单位写进字段命名和接口约定：balance_cents 比 balance 更不容易被误用；增量、上限、比较和展示都必须采用同一单位。

把错误类型和数据边界记录下来

使用 INCRBYFLOAT 时，至少要把“命令失败”和“比较不相等”分开。Redis 返回的错误可能来自错误键类型、无法解析为双精度浮点数，或数值超出可接受范围。应用日志可以记录命令用途、键名的脱敏标识、增量单位和错误类别，但不要把密码或完整敏感值写入日志。

还要注意，成功更新后的字符串并不携带业务单位。Redis 只知道这是一个浮点字符串，不知道它代表元、百分比还是摄氏度。单位、刻度和允许误差必须在应用协议中定义，并在字段名、代码类型或文档中固定下来。

如果业务要求“每次增加都不能超过上限”，单独使用 INCRBYFLOAT 后再读取检查，可能让检查与更新之间出现竞态。那已经是原子条件更新问题，应另行设计脚本或事务；本文不把它和浮点格式问题混为一谈。

常见问题

Redis 返回 1 而不是 1.00，是不是小数精度丢了？ 不一定。成功结果会移除尾随零，显示格式变化不等于业务精度被截断；是否需要两位小数应由应用展示层决定。

把 Redis 返回值转成 float64 后可以直接用 == 吗？ 只有在你能证明值来自可精确表示的范围时才适合。一般浮点计算应使用由业务定义的容差，金额类数据优先使用整数最小单位。

为什么不把所有数据都乘以 100 再存？ 乘数必须匹配真实单位和允许精度。百分比、汇率和不同计量对象可能需要 1000 或更高刻度，盲目乘 100 反而会造成溢出或精度不足。

命令报错后还能继续比较旧值吗？ 应先处理错误。命令失败不等于得到一个“没有变化的新数值”，继续使用旧结果可能把一次更新失败误判成业务上的相等。