Go unique.Make 怎样复用已有缓冲空间

unique.Make 没有接收缓冲区的参数，不能把它当作 bytes.Buffer 或 sync.Pool 来复用一段可写内存。正确组合方式是让读取层复用自己的字节缓冲，在当前数据仍有效时转换成稳定的可比较值，再调用 Make 得到句柄。对文本标签，常见写法是先做普通的 string(value) 转换，再保存 unique.Handle[string]。

我倾向于把这两件事分别命名：扫描缓冲负责临时输入，句柄负责重复值的身份。它们可以配合，但不能把“使用了 unique”直接写成“全程零分配”。下面用一个逐行标签统计程序说明边界，代码和输入规则均为本文独立设计。

官方文档：https://pkg.go.dev/unique#Make

能力介绍：https://go.dev/blog/unique

读取缓冲文档：https://pkg.go.dev/bufio#Scanner.Bytes

1. 能力变化一句话：unique 提供值规范化，不提供缓冲租借

Go 1.23 在标准库中引入 unique 包，用于对可比较值进行规范化，也常称作 interning。Make 返回某个值的句柄，相等的字符串能得到相等的对应句柄。本文介绍的是这项已有能力，并不宣称最新版本增加了缓冲区重用接口。

它的输入是可比较类型的值。字符串可用，普通 []byte 不满足可比较约束，不能直接当作 Make 的类型参数。若改成指针以求“可比较”，比较的又会成为指针身份，而不是所指字节内容；这不是文本去重所需的合同。

2. 为什么分开缓冲复用和重复值去重

Scanner.Bytes 暴露当前 token 的字节视图，后续 Scan 可能覆盖相同底层空间。因此，读取层可以持续利用同一缓冲处理多行，消费者却不能把这个视图直接保存成长期记录。

普通的 []byte 到 string 转换给出稳定的字符串语义，原字节后续改写不应改变它。再把字符串交给 Make，才进入值规范化这一层。这里故意不用 unsafe 构造共享可写内存的字符串，以免破坏字符串不可变的前提。

我会保留明确的字符串转换，再根据真实负载判断是否值得做更多优化。编译器可能优化具体表达式，但“可能优化”不是零分配保证；扫描缓冲、字符串、句柄管理、结果切片和统计 map 都应纳入实际资源评估。

3. 对旧代码的影响：句柄列表仍然保存每条记录

如果原代码保存每行的 []byte 视图，换成 Handle[string] 之前首先要纠正生命周期问题。否则观察到的记录变化，可能来自扫描缓冲覆盖，而不是去重算法本身。

另一个误区是以为 Make 会删除结果列表中的重复项。它规范化的是值身份，不会替你缩短业务列表。四条输入中有三条重复标签，labels 切片仍可保留四个句柄；若想统计不同值，还需要显式建立集合或其他业务索引。

4. 迁移建议：用完整程序固定输入边界

程序要求 Go 1.23 或以上版本，从标准输入接收每行一个 label= 前缀的标签。示例允许空标签，因此 label= 是合法记录；空白行没有前缀，会报错。没有额外的去空格、大小写转换或文本归一化。

package main

import (
    "bufio"
    "bytes"
    "fmt"
    "io"
    "os"
    "unique"
)

func ReadLabels(r io.Reader) ([]unique.Handle[string], error) {
    scanner := bufio.NewScanner(r)
    // 同一个扫描器使用预先提供的缓冲；不把它交给 Make。
    scanner.Buffer(make([]byte, 32*1024), 64*1024)
    var labels []unique.Handle[string]
    total := 0
    for scanner.Scan() {
        line := scanner.Bytes()
        if len(line) > 4096 || len(labels) >= 10000 {
            return nil, fmt.Errorf("单行或记录数量超过限制")
        }
        total += len(line)
        if total > 16*1024*1024 {
            return nil, fmt.Errorf("行文本总量超过限制")
        }
        value, found := bytes.CutPrefix(line, []byte("label="))
        if !found {
            return nil, fmt.Errorf("第%d行缺少label=前缀", len(labels)+1)
        }
        // 普通转换得到稳定字符串，后续 Scan 覆盖缓冲不影响它。
        text := string(value)
        labels = append(labels, unique.Make(text))
    }
    if err := scanner.Err(); err != nil {
        return nil, fmt.Errorf("扫描标签: %w", err)
    }
    return labels, nil
}

func main() {
    labels, err := ReadLabels(os.Stdin)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    seen := make(map[unique.Handle[string]]struct{})
    for _, label := range labels {
        seen[label] = struct{}{}
    }
    if _, err := fmt.Printf("records=%d distinct=%d\n", len(labels), len(seen)); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

32 KiB 是初始扫描缓冲，64 KiB 是扫描器允许的缓冲增长上限；4096字节是应用自定的单行限制，另外还有10000条和16 MiB行文本合计限制。扫描器在完整交付 token 前就可能遇到更长输入，因此必须检查 scanner.Err，而不能只依赖循环体内的长度判断。

这些限制不等于进程内存预算，合计值不含换行、容器和运行时开销。应用不会返回错误前收集的部分结果。空输入则得到零条记录、零个不同标签，属于正常情况。

如果上游本来就有稳定字符串，可直接 Make，不必再绕成 []byte；若只需要简单的一次性不同值计数，直接使用 map[string]struct{} 也可能更合适。引入句柄应服务于后续多处保存和比较的需求，而不是为了看起来用了优化接口。

5. 最小结果推导：先确认语义，再讨论收益

# 将四行输入交给程序；由读者在本地执行
printf 'label=cedar\nlabel=birch\nlabel=cedar\nlabel=\n' | go run main.go

按这组固定输入推导，records 应为4，distinct 应为3，空字符串也占一个不同值。这是预期说明，不是本文实际运行日志。前三行中的两个 cedar 应得到相等句柄，而 cedar 与 birch 的句柄不相等。

准备真实对照时，应固定输入规模、标签长度、重复比例和保留时间，并把字符串集合与句柄集合放在相同任务下比较。全部唯一且很快丢弃的标签，与重复很多且长期保存的标签，不能预设有相同收益。本文未运行基准，也不报告耗时、分配次数或内存下降比例。

Make 可并发调用，Scanner 也能随意并发用吗？

不能据此推论。Make 的并发使用合同不扩展到同一个 Scanner、输入缓冲或业务结果容器。读取层应保持自己的访问规则。

Handle.Value 会返回可写缓冲吗？

不会。此处 Value 的结果类型是 string，不是可写 []byte。不要把取得原值理解为租到原输入缓冲。

句柄有没有 Close 或手动归还操作？

这个接口没有缓冲租借式的归还动作。不要套用对象池的 Put 模式，也不要用手动触发 GC 作为内存立刻回收的保证。长期保存大量不同值的句柄仍需要考虑应用自身的容量和生命周期。

什么时候值得组合这两层？

当读取阶段需要持续扫描文本、后续结构又反复保存或比较大量重复标签时，可以考虑这种拆分。先让临时字节和稳定值各有清楚的归属，再用真实测量决定收益，比把 Make 当成万能缓冲优化更可靠。