Go Humanize 格式化后的容量字符串为什么不适合直接数值排序

我在文件列表里第一次把 humanize.Bytes 的返回值直接拿去排序时，看到的是一串很“像数字”的文本，结果顺序却和文件真实大小对不上。原因并不在排序函数，而在数据职责：Bytes 和 IBytes 的结果是给人看的展示字符串，已经包含小数、单位和舍入信息，不能继续当作原始容量。

为什么展示字符串天然不适合排序

humanize.Bytes(82854982) 会得到类似 83 MB 的 SI 展示，humanize.IBytes(82854982) 则会得到类似 79 MiB 的 IEC 展示。字符串比较器看到的只是首字符、数字位数和单位文本，不知道“1.2 GB”与“900 MB”之间的真实数量关系。

更隐蔽的问题是格式化可能发生舍入。两个不同的原始字节数可能显示成同一个文本，反过来同一列如果混用了 SI 和 IEC，单位基数也已经不同。此时即使字符串排序“看起来有序”，它也不能代表业务上的容量顺序。

先确定单位口径，再决定展示函数

如果产品按十进制容量展示，用 humanize.Bytes；如果界面明确使用二进制容量，用 humanize.IBytes。这两个函数都接收 uint64，所以最稳妥的边界是：进入渲染层前保留原始字节数，渲染时才生成 SizeText。

保留原始字节数，再决定排序入口

下面的结构把可计算字段和展示字段放在同一行，但明确分工。排序只读 RawBytes，输出时再读 SizeText；如果需要切换 SI 与 IEC，也不会破坏排序依据。

type FileRow struct {
	Name     string
	RawBytes uint64 // 保存真实字节数，供排序和分页使用
	SizeText string // 仅用于页面展示，不作为比较键
}

sort.Slice(rows, func(i, j int) bool {
	// 数值排序不受小数位数和 MB、GB 文本影响
	if rows[i].RawBytes == rows[j].RawBytes {
		return rows[i].Name 

这里的关键不是换一个排序函数，而是让排序字段回到没有丢失信息的层。若列表支持服务端分页，也应在数据库或接口层按原始字节数字段排序，不能先格式化再分页。

只有历史容量文本时先反解析

旧接口如果只留下了 83 MB 这样的文本，可以用 Humanize 的 ParseBytes 把它转成 uint64，再排序。反解析必须显式处理错误，因为空字符串、未知单位、被业务前缀污染的文本都不应该静默变成零。

func rawBytesOf(text string) (uint64, error) {
	// 去除首尾空白，避免把展示层的格式噪声带入解析器
	value := strings.TrimSpace(text)
	if value == "" {
		return 0, errors.New("容量文本为空")
	}
	bytes, err := humanize.ParseBytes(value)
	if err != nil {
		// 解析失败要留给调用方决定跳过、报错或回退人工处理
		return 0, fmt.Errorf("解析容量 %q: %w", value, err)
	}
	return bytes, nil
}

反解析适合迁移和兼容，不适合作为新数据的长期存储方案。若历史数据同时含有 SI 与 IEC，先统一产品口径，再把结果写回独立的数值字段；金额、配额或审计场景还要考虑更大的整数范围，可评估 ParseBigBytes。

相关问题

用字符串排序为什么有时看不出错误？

当所有值恰好使用相同整数位数和相同单位时，结果可能暂时接近正确；一旦出现不同单位、小数或舍入，错误就会暴露，所以不能把偶然正确当作规则。

Bytes 和 IBytes 能放在同一列比较吗？

展示上可以通过明确标签告诉用户单位口径，但比较时应回到统一的原始字节数。不要比较两个格式化字符串，也不要让同一列表隐式混用单位。

排序后还需要保留 SizeText 吗？

需要。RawBytes 负责计算、排序和分页，SizeText 负责可读性；两者并存比在每次渲染或排序时互相转换更稳定。