Go x/text/collate Buffer.Reset 后排序键为什么不能继续保存

如果你用 golang.org/x/text/collate 生成排序键，再调用 Buffer.Reset() 后继续保存旧的 []byte，问题不在排序规则，而在切片的生命周期：官方文档明确说明，Key 和 KeyFromString 返回的切片只保证在下一次 Reset 之前有效。Reset 会清空可复用缓冲区，之后同一个 Buffer 可以覆盖原来的字节。

官方地址：https://pkg.go.dev/golang.org/x/text/collate

只在当前批次内使用排序键，可以让它们共享一个未重置的 Buffer；需要跨批次、异步任务或缓存长期保存时，应在 Reset 前复制 key，或者直接使用 Collator 的比较方法。

KeyFromString 返回的不是独立副本

collate.Collator 负责按照语言环境比较 Unicode 字符串。调用 KeyFromString 时，传入的 Buffer 用来承接生成后的排序权重，返回值只是 Buffer 中那一段字节的切片视图。

这样设计的好处是可以减少大量短字符串排序时的分配，但代价是返回值的所有权仍然属于 Buffer。把返回值放进结构体、map 或缓存，并不会自动把底层数组复制出来。

Reset 为什么会让旧排序键失效

从使用者角度看，Reset 并不是把每个字节都擦成零，而是让 Buffer 的下一次写入从头复用已有存储。因此，旧切片仍可能保留原来的长度，却不再享有“内容保持不变”的保证。

下面的示例故意把第一个 key 放过 Reset 再观察它。注释中的“可能变化”是生命周期契约，不应依赖某一次运行恰好打印出的字节：

package main

import (
	"fmt"

	"golang.org/x/text/collate"
	"golang.org/x/text/language"
)

func main() {
	c := collate.New(language.English)
	var buf collate.Buffer

	keyA := c.KeyFromString(&buf, "angstrom")
	// Reset 让下一次生成从可复用缓冲区的起点开始。
	buf.Reset()
	keyB := c.KeyFromString(&buf, "zebra")

	fmt.Printf("keyA=%x keyB=%x\n", keyA, keyB)
	// keyA 已越过文档承诺的有效期，不能再据此判断排序结果。
}

这里最容易误判的是：keyA 这个变量本身没有自动变成 nil，所以程序通常还能打印它。但切片只保存指针、长度和容量，底层数组已经重新交给 Buffer 使用；一旦后续写入覆盖那段空间，keyA 的内容就可能跟着变化。

批量排序时怎样安全复用 Buffer

如果所有排序键只在一次排序过程中使用，可以让它们连续写入同一个 Buffer，并把 Reset 放在整个批次完成之后。不要在每一条记录之间 Reset，否则前面已经保存的 key 会进入失效边界。

package main

import (
	"bytes"
	"fmt"
	"sort"

	"golang.org/x/text/collate"
	"golang.org/x/text/language"
)

type item struct {
	name string
	key  []byte
}

func main() {
	c := collate.New(language.English)
	items := []item{{name: "zebra"}, {name: "angstrom"}, {name: "apple"}}
	var buf collate.Buffer

	for i := range items {
		// 同一批次不 Reset，所有 key 都留在 Buffer 的不同区间内。
		items[i].key = c.KeyFromString(&buf, items[i].name)
	}
	sort.SliceStable(items, func(i, j int) bool {
		// key 只在本次排序中读取，比较结束前 Buffer 仍未 Reset。
		return bytes.Compare(items[i].key, items[j].key) 

这个模式的关键不是“永远不能 Reset”，而是把 Reset 当成一个明确的所有权边界：排序闭包、比较函数和任何延迟读取都必须在边界之前完成。

需要长期保存时先复制排序键

如果排序键要放到跨请求缓存、索引结构或异步任务中，就不能依赖共享 Buffer。复制动作应该紧跟在生成动作之后，使保存的切片拥有自己的底层数组。

package main

import (
	"bytes"
	"fmt"

	"golang.org/x/text/collate"
	"golang.org/x/text/language"
)

type savedKey struct {
	text string
	key  []byte
}

func makeSavedKey(c *collate.Collator, buf *collate.Buffer, text string) savedKey {
	key := c.KeyFromString(buf, text)
	// append 到 nil 切片会分配独立存储，切断与 Buffer 的共享关系。
	owned := append([]byte(nil), key...)
	return savedKey{text: text, key: owned}
}

func main() {
	c := collate.New(language.English)
	var buf collate.Buffer

	first := makeSavedKey(c, &buf, "angstrom")
	buf.Reset()
	second := makeSavedKey(c, &buf, "zebra")
	buf.Reset()

	// 两份 key 已经独立保存，后续 Reset 不会改变它们。
	fmt.Println(bytes.Compare(first.key, second.key) 

复制会增加一次内存和拷贝成本，因此它适合“必须把排序键留到 Buffer 生命周期之外”的场景。若只是比较两个字符串，没有缓存 key 的需要，直接调用 CompareString 通常更简单：

// 只需要比较，不保存排序键时直接让 Collator 完成比较。
if c.CompareString(left, right) 

四个常见误区

排查时按这条生命周期检查

1. 先确认返回值来自 Key 还是 KeyFromString，并找到它使用的 Buffer。
2. 向后查找第一次 Reset、下一次生成 key、对象归还池或异步发送的位置。
3. 如果旧 key 会越过这些边界，检查是否使用了 append([]byte(nil), key...) 之类的深拷贝。
4. 如果程序只是比较字符串，删除不必要的 key 缓存，改用 Compare 或 CompareString。

最终可以把规则压缩成一句话：Buffer 负责复用，返回的排序键负责当前生命周期内读取；一旦要跨过 Reset，就必须由调用方复制所有需要继续保存的字节。

相关问题

Buffer.Reset 会把排序键切片长度变成零吗？

不会自动修改调用方手里的切片头，但它会清空 Buffer 的内部写入长度，并结束官方对旧返回切片内容的有效性承诺。不要用“还能打印”推断“仍然有效”。

同一个 Buffer 可以保存多个排序键吗？

可以，只要这些 key 都在同一次 Reset 之前使用，并且后续写入没有越过它们的容量范围；更稳妥的做法是把它们当作当前批次的临时视图。

复制排序键后还需要保留 Buffer 吗？

不需要。复制完成后，保存的字节已经独立于 Buffer；Buffer 可以在当前调用结束时 Reset 并继续复用。