Go strconv.ParseFloat 的范围与精度处理

strconv.ParseFloat 的 bitSize 选择32位或64位浮点精度，不控制保留几位小数。处理输入时，应同时接收数值和错误，再根据业务要求排除 NaN、无穷大及业务范围外的结果。返回类型是 float64，并不意味着按32位解析时已经丢失的信息能够恢复。

官方文档：https://pkg.go.dev/strconv#ParseFloat

设想一个设备采集入口：字段原来接收32位读数，接口改造后改用 float64 变量。此时先决定是否继续遵守原来的精度约定，再决定如何处理错误，比单纯修改变量类型更重要。下面按这个原创场景逐项说明；代码没有作为本机实测结果展示。

bitSize 是小数位数吗

不是。选择32时，解析结果按 float32 精度舍入，再以 float64 返回；选择64时则按 float64 精度处理。普通舍入不等于范围错误。传入较长的十进制小数，完全可能得到非原样的数值且没有错误。

在设备协议仍要求32位精度时，保留32这个配置；如果已经确定整个数据链路迁移到64位，应同步接收端、存储字段和序列化约定。只把返回值放进更大的变量，不能补回解析时没有保留的有效信息。

哪些输入应归入解析错误

应区分 ErrSyntax 与 ErrRange：前者说明格式不符合解析要求，后者说明有效数字文本产生了超范围结果。上溢可能同时返回无穷大与范围错误，因此不能只读取数值。解析器也认识十六进制浮点形式，这不等同于业务一定允许该格式。

例如给温度字段输入 12.3C，业务需要的是明确的数值字段与单位字段，而不是悄悄截去尾部字符。对失败输入返回可定位的字段错误；若系统记录原始文本，另按自身数据保留约定处理。不要把失败结果替换成零后继续写入，否则合法的零读数和失败记录将难以区分。

解析成功为什么还要检查有限值

NaN 和无穷大是解析器认可的特殊浮点值，可能在没有解析错误时出现。只用 err == nil 判断是否能参与业务计算不够。math.IsNaN 判断非数值，math.IsInf(v, 0) 同时识别正负无穷。

有限值检查与业务上下限是两项约定。例如本文入口拒绝低于-80或高于180的读数，是示例产品规则；不能把这两个数字描述成 Go 浮点范围。先排除特殊值，再做普通上下限比较，可以让这些限制的职责更清楚。

怎样给传感器字段写一个完整入口

下面的完整程序只依赖标准库。封装入口检查配置、保留错误链、拒绝非有限值，再施加示例业务范围。调用端根据错误类别给出不同反馈。

package main

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

// ParseReading 只接收可用于业务计算的有限数值。
func ParseReading(s string, bits int) (float64, error) {
    // 明确限制接口配置，不把任意整数作为精度约定。
    if bits != 32 && bits != 64 {
        return 0, errors.New("精度配置只允许32或64")
    }
    v, err := strconv.ParseFloat(s, bits)
    if err != nil {
        // 保留原始错误链，让调用方能分类语法和范围错误。
        return 0, fmt.Errorf("读数转换失败: %w", err)
    }
    if math.IsNaN(v) || math.IsInf(v, 0) {
        return 0, errors.New("读数必须是有限数值")
    }

    // 这是示例业务范围，不是浮点类型自身的数值范围。
    if v  180 {
        return 0, errors.New("读数不在允许的业务范围内")
    }
    return v, nil
}

func main() {
    // 用不同类别的输入说明调用方法；不忽略任何错误。
    inputs := []string{"23.123456789", "1e1000", "NaN", "12.3C", "250"}
    for _, s := range inputs {
        v, err := ParseReading(s, 32)
        switch {
        case errors.Is(err, strconv.ErrSyntax):
            fmt.Printf("%q: 数字语法不符合要求\n", s)
        case errors.Is(err, strconv.ErrRange):
            fmt.Printf("%q: 超出目标浮点范围\n", s)
        case err != nil:
            fmt.Printf("%q: %v\n", s, err)
        default:
            // 以足够位数观察结果，显示格式不改变存储精度。
            fmt.Printf("%q: %.9g\n", s, v)
        }
    }
}

代码中的 %w 保留了被包装的转换错误，调用端可用 errors.Is 分类。这里参数错误、特殊值和业务范围错误直接作为业务反馈；若它们也需要稳定分类，可在项目中改用命名错误或结构化错误类型，而不是比较中文报错字符串。

按这个接口的定义，长小数走正常舍入路径；极大指数、非法尾缀、特殊值与业务越界分别对应不同处理。它没有把“舍入后是否等于原始十进制文本”作为成功条件，也没有承诺保留原文本的小数位数。

落库和显示时还应保留什么约定

为什么按32位解析后改成 float64 仍有偏差？

32位目标精度已经参与了舍入。扩大容器能容纳这个结果，却无法知道原输入的更多细节。需要重新依据原始文本按目标精度解析，并确认协议允许这种变化。

能否把 bitSize 设为2来保留两位小数？

本文入口明确只允许32或64。两位小数属于格式或业务舍入规则，应在对应层单独定义；不要通过改变 ParseFloat 的位宽参数表达。

输入有单位或空白，要不要自动清理？

应由输入协议决定。采集协议明确分离字段时，拒绝带单位的文本通常更容易发现上游问题；表单允许用户输入空白时，可以在表单层规范化。无论选择哪种方式，都应让同一入口保持一致。

API依据：strconv.ParseFloat、math.IsNaN、math.IsInf。业务入口及采集场景为本文原创示例。