Go strconv.FormatFloat 与 AppendFloat 怎样选择

结果需要直接存进字符串字段、传给 string 参数时，选 strconv.FormatFloat；已经在构建 []byte 文本、需要保留前缀并复用缓冲区时，选 strconv.AppendFloat。两者遵循同样的数值格式规则，AppendFloat 返回扩展后的切片，必须接回；它不是“更精确”的版本，也不保证零分配。

官方文档地址：https://pkg.go.dev/strconv

先看结果交给字符串接口还是字节接口

考虑一个读数导出任务：界面模型需要一个格式化后的字段，而文本导出器要把字段名、数字和换行组装成一行。它们的数值一样，下一位消费者却不同。如果为了统一写法先把所有内容转成字符串，再转回字节，往往只是把类型转换藏进公共函数。

这个场景里，浮点输入接受格式参数约束；字符串接口接收字符串结果，字节接口接收目标缓冲中的扩展切片。判断依据是结果消费者，而不是函数名称看起来谁更底层。

本文只比较结果形态、追加行为和复用责任，不展开浮点舍入算法，也不声称进行了基准测试。把 API 选对能让代码职责清楚，但不能凭一行替换就给出吞吐或内存收益百分比。

两条写法使用同一份格式约定

先用固定三位小数构造可比较的例子。FormatFloat 直接返回数字文本，AppendFloat 则把同样的数字文本放到已有前缀后面。

package main

import (
    "fmt"
    "strconv"
)

func main() {
    value := 18.625
    // 结果直接交给字符串字段，不先构造 []byte。
    text := strconv.FormatFloat(value, 'f', 3, 64)

    // 已有一行字节数据时，保留前缀并把数字追加到末尾。
    line := make([]byte, 0, 48)
    line = append(line, "reading="...)
    line = strconv.AppendFloat(line, value, 'f', 3, 64)
    line = append(line, '\n')
    fmt.Println(text)
    fmt.Print(string(line)) // 此处转换仅用于展示，字节消费者可直接使用 line。
}

按代码语义推演，text 应为 18.625，line 应包含前缀 reading=、相同数字和换行。这是示例说明，不是已执行输出。将两处 fmt、prec 或 bitSize 改成不同值后，文本可能不同，不能再把差异归因于返回类型。

如果原值来自 float32，可先转成 float64 传参，再按 float32 的语义使用 bitSize 32。bitSize 不是输出文本的位数，也不是把结果压成 32 字节。常见通用读数表示可以使用 'g', -1, 64；它追求可还原该精度数值的简短表示，不承诺固定小数位。

另一个小但重要的区别是接回返回值。AppendFloat 可能复用当前数组，也可能需要扩容；buf = strconv.AppendFloat(...) 才把更新后的长度和存储引用保留下来。不能认为“传入了切片，所以调用者变量会自动变长”。

缓冲区复用必须有清楚的交付时点

将文本生命周期说完整，比只谈 make 的容量更重要。当前任务拥有可变缓冲，其他切片可能是它的共享视图。结果若交给同步消费者且对方已完成使用，才轮到复用入口重置长度；若交给异步消费者长期保存，应转移所有权或准备独立副本。

package reading

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

var ErrNonFinite = errors.New("non-finite reading")

// AppendReading 不重置 dst；调用者决定保留前缀还是从空长度开始。
func AppendReading(dst []byte, value float64) ([]byte, error) {
    // 拒绝策略属于本业务，不是 AppendFloat 的错误返回机制。
    if math.IsNaN(value) || math.IsInf(value, 0) {
        return dst, ErrNonFinite
    }
    dst = append(dst, "reading="...)
    dst = strconv.AppendFloat(dst, value, 'g', -1, 64)
    dst = append(dst, '\n')
    return dst, nil
}

这个封装不偷偷重置 dst。想追加到现有文本就传 buf，想开始下一行可以在确认旧数据不再被使用后传 buf[:0]，然后接回函数返回的切片及错误。nil 切片也能作为追加起点，只是没有现成容量可复用。

buf[:0] 改变的是长度，不会抹除底层数组的旧字节。它不是敏感数据擦除，也不会让另一个已经保存的切片自动拥有副本。之后追加可能覆盖共享数组，旧视图便可能看到新内容。

异步队列若只保存切片描述并稍后读取，提交后立即复用原 buf 会破坏交付约定。可以明确让队列接管缓冲并在使用完后归还，也可以在提交前复制需要保留的字节。将切片通过 channel 发送，本身不复制它的底层数组；并发复用还可能形成数据竞争。

若最后必须返回 string，直接使用 FormatFloat 通常更符合接口。普通 string(buf) 转换具有字符串值语义，不能把它理解为允许随缓冲区修改的视图；但编译器在特定上下文如何优化，不应写成固定分配次数的保证。不要为了所谓零拷贝引入不受控的 unsafe 别名。

格式化不是数据有效性判断

示例业务只允许有限读数，所以在追加任何字节前拒绝 NaN 和无穷大；检查失败返回原 dst，便于调用者保持已有前缀。这是我们自己的规则。两个格式化 API 都不返回 error，不能用“调用没报错”代表数值满足业务或下游协议。

如果后续输出属于 JSON、CSV 或某个专用协议，还要遵循该格式的编码规则。AppendFloat 只生成数值文本，不负责把整条记录变成合法序列化文档。这里的 reading= 行只是自定义示例文本，不冒充某种标准协议。

fmt、prec 和 bitSize 应当由程序定义，而不是任由外部请求控制。尤其大 prec 可能生成很长的文本；它不是输出长度上限，预留的 48 字节也不是硬上限，追加可以扩容。需要输出预算时，在格式策略层制定限制，不要把初始容量误当防护。

保留三位小数只是显示约定，不会把原始浮点值本身改成三位精确小数。涉及金额或精确十进制业务时，需要另行选择合适的数据表示；换成 AppendFloat 不会解决表示层问题。

用调用边界做最后选择

比较性能时也应比较同一份工作：同样数值、格式参数、输出长度和消费者类型，分别观察所需转换、分配与总耗时。把“每次新建缓冲”与“循环复用大缓冲”直接相比，测到的不只是格式化函数差别。本文不提供未经执行的性能结论。

相关问题

AppendFloat 会替换已有内容吗？不会，它从当前长度之后追加。需要从头写一条新记录时由调用方决定何时安全重置。

AppendFloat 总是无分配吗？不是接口保证；容量和调用上下文都会影响实际成本。不要依靠函数名推断固定分配次数。

两者的舍入规则不同吗？相同输入和格式参数下，AppendFloat 追加的数字形式遵循 FormatFloat 的约定，主要差别在结果交付方式。

想固定两位小数应当怎样设参数？使用 f 格式及 prec 2；这是一项显示选择，不代表原数值是精确十进制，也不代表文本总长为两位。

这个选择最后落在数据的去向上：需要字符串就直接得到字符串，已经在组装字节就继续追加。对需要复用的路径，把旧数据何时失效、失败时是否改变前缀、异步交付怎样保留内容一并写清，才能避免优化一行代码却引入生命周期错误。

参考：FormatFloat 参数约定；AppendFloat 追加行为；Go 切片追加与复制规范。