Go Humanize Bytes 和 IBytes 为什么显示不同的单位值

我在整理文件大小日志时遇到过一个很容易误判的现象：同一个 uint64 传给 Go Humanize 的 Bytes 和 IBytes，结果里的数字、单位甚至进位位置都可能不同。这不是格式化随机变化，而是两个函数分别采用了十进制 SI 和二进制 IEC 规则。

官方地址：https://pkg.go.dev/github.com/dustin/go-humanize

Bytes 按 1000 进位并使用 kB/MB/GB，IBytes 按 1024 进位并使用 KiB/MiB/GiB。先确定业务表达的是十进制容量还是二进制大小，再决定调用哪个函数。

先看同一个输入为什么会出现两套结果

官方示例使用 82854982 这个字节数：Bytes 会得到约 83 MB，IBytes 会得到约 79 MiB。输入没有变，变化的是单位体系：前者计算 1000^n，后者计算 1024^n。

package main

import (
    "fmt"

    "github.com/dustin/go-humanize"
)

func main() {
    size := uint64(82854982)

    // Bytes 适合用十进制单位表达磁盘、网络或厂商容量。
    fmt.Println("SI:", humanize.Bytes(size))
    // IBytes 适合用二进制单位表达内存、文件系统块等场景。
    fmt.Println("IEC:", humanize.IBytes(size))
}

这段代码的关键不是比较哪一个数字更“正确”，而是给输出补上了准确的语义。把 83 MB 和 79 MiB 都简称成“79/83 MB”会让读者误以为它们可以直接比较。

Bytes 和 IBytes 实际上共享哪些逻辑

两个公开函数最后都调用内部的 humanateBytes。区别集中在三个参数：进位基数、单位字符串切片和最少显示位数。Bytes 传入 1000 与 B、kB、MB...；IBytes 传入 1024 与 B、KiB、MiB...。

它们也不是简单地截断小数。实现会先根据当前单位的整数位数计算保留的小数位，再进行一次舍入；如果舍入后从 9.99 跨成 10，还会重新计算显示精度。接近单位边界时，结果因此可能从上一档自然进位到下一档。

因此，看到末尾是整数并不意味着函数没有做精度处理；它可能是当前单位下整数位已经占满了显示位数，或者舍入后刚好落在整值。

需要固定显示精度时怎样选 N 变体

默认的 Bytes 和 IBytes 追求紧凑展示。如果日志、报表或接口文档需要更明确的有效数字，可以使用 BytesN 与 IBytesN。参数 n 表示总显示位数，包含整数部分和小数部分；当整数位已经达到 n 时，小数会被省略。

package main

import (
    "fmt"

    "github.com/dustin/go-humanize"
)

func main() {
    size := uint64(82854982)

    // n=4 让十进制展示最多保留四个总数字，便于表格对齐。
    fmt.Println(humanize.BytesN(size, 4))
    // 二进制展示必须继续保留 MiB 后缀，不能只替换成 MB。
    fmt.Println(humanize.IBytesN(size, 4))
}

我的经验是：面向用户的容量卡片优先选择一种单位体系并全站统一；面向工程排障的日志则把原始字节数和格式化文本同时保留。这样即使展示规则后来调整，也不会丢掉可重新计算的真实值。

运行手册：把单位约定写进接口和日志

• 触发信号：同一文件在监控、对象存储和本地日志中显示出不同大小。
• 快速判断：检查后缀是否为 kB/MB 或 KiB/MiB，再确认调用的是 Bytes 还是 IBytes。
• 处理动作：在字段说明中写清“字节数”“十进制展示”或“二进制展示”，不要只写模糊的 MB。
• 回滚路径：如果旧接口已经输出无后缀单位，先保留原字段，新增带明确后缀的字段，避免客户端解析突然改变。
• 复盘项：检查边界样本、BytesN/IBytesN 的 n 值，以及从展示文本反向解析时是否仍保留单位。

最终结论很简单：Bytes 与 IBytes 的差异不是库的缺陷，而是十进制和二进制容量定义的差异。只要让后缀、字段文档和业务语义保持一致，两个结果都可以是正确的。

相关问题

文件大小应该默认用 Bytes 还是 IBytes？

没有脱离场景的唯一答案。磁盘厂商容量和网络带宽常用十进制；内存、缓存或需要按 1024 分组的工程指标更适合 IEC 表达。关键是明确后缀和文档约定。

Bytes 和 IBytes 能不能只比较数值部分？

不建议。数值部分依赖不同基数，必须连同单位体系比较；如果要排序，保留原始字节数，用 uint64 比较更可靠。