Go unique.Handle 怎样比较唯一句柄而不复制字符串在批处理代码中减少额外分配

已有 unique.Handle[string] 时，直接使用 a == b 比较即可，不必先调用 Value 恢复字符串。要评估批处理收益，应把句柄构造放在哪里、句柄会被比较多少次一起考虑。普通字符串相等比较本身并不要求复制整段字符数据，因此不能把改用句柄描述成必然消除了一次字符串复制或堆分配。

官方地址：https://pkg.go.dev/unique

语言规范：https://go.dev/ref/spec

先分清比较成本与字符串复制

假设一批记录按仓库分组，代码不断判断记录的分组是否等于目标字符串。看到长字符串参与比较，容易先怀疑“每次比较复制了很多字节”。我会先把这个推断拆开：读取字符参与内容比较，与创建一份新字符数据，是不同操作；仅凭代码里出现字符串 ==，不能判断发生了额外分配。

句柄提供的是另一种相等比较表示。官方约定相同类型的原值相等时，对应句柄也相等；句柄比较通常比比较原值简单。但 Make 的查找和规范化工作仍要付出成本，需要复用已有句柄，才可能把这些成本摊到多次比较中。

把待比较字段保留为同类型句柄

下面示例使用 Go 1.23 及以上。Item 在准备阶段保存 Group 句柄，CountGroup 只负责匹配计数，不接收原字符串，也不在循环中重复 Make。

package main

import (
    "fmt"
    "unique"
)

type Item struct {
    Group unique.Handle[string]
}

// CountGroup 只比较已构造句柄，不在热点循环里恢复文本。
func CountGroup(items []Item, target unique.Handle[string]) int {
    total := 0
    for _, item := range items {
        if item.Group == target {
            total++
        }
    }
    return total
}

func main() {
    target := unique.Make("warehouse/north")
    items := []Item{
        {Group: unique.Make("warehouse/north")},
        {Group: unique.Make("warehouse/south")},
        {Group: unique.Make("warehouse/north")},
    }
    fmt.Println("匹配数量:", CountGroup(items, target))
    // 仅在展示边界恢复文本，不影响比较方式。
    fmt.Println("分组:", target.Value())
}

按示例内容推导，匹配数量应为 2，显示的分组文本为 warehouse/north。这里未执行程序，也不以推导结果代替性能测量。空字符串若是合法分组，可以正常通过 Make 构造；如果业务禁止空值，应在创建 Item 之前返回输入错误。

这个改造的判断点很明确：若输入每次都只有字符串、每条记录只比较一次，直接保留字符串可能更省事；若记录长期保留并参与多次筛选，可以将构造成本与后续使用分开评估。不要为了让所有地方都用句柄而改掉外部文本协议。

用三组基准区分复用收益与转换成本

把下面代码单独保存为 compare_test.go，放入独立的基准目录。它不依赖上面的 main 包。三组都只做一次相等判断，但计入的工作范围不同，用于排查收益来自哪里。

package comparebench

import (
    "strings"
    "testing"
    "unique"
)

var matched bool

func BenchmarkCompare(b *testing.B) {
    left := strings.Repeat("segment/", 128) + "north"
    right := strings.Clone(left) // 准备独立但内容相同的字符串。
    hleft, hright := unique.Make(left), unique.Make(right)

    b.Run("StringEqual", func(b *testing.B) {
        b.ReportAllocs()
        for i := 0; i 

基准接口文档：https://pkg.go.dev/testing

# 在已经初始化 Go 模块的基准目录运行，显示分配并重复采样。
go test -run '^$' -bench '^BenchmarkCompare$' -benchmem -count=5

StringEqual 比较原字符串；HandleEqual 只比较准备好的句柄；WarmMakeAndEqual 把每次调用 Make 的工作计入。这第三组是已存在值的复用路径，不是“每次产生全新唯一值”的冷启动成本。父函数的字符串准备和首次 Make 不属于各子基准的计时区间。

matched 用于保留结果，三组采用相同写入方式。示例只覆盖长且相等的字符串；真实任务还应考虑短字符串、长度不同、内容很早不同以及共享同一字符串值的情况。不能把这一组输入的结果外推成所有字符串比较的固定差距。本篇不提供虚构的 ns/op、B/op 或 allocs/op。

批处理怎样避免比较路径上的额外工作

在本例的批处理函数里，额外工作的主要来源应逐项检查：是否每轮重新把字符串转成句柄，是否先 Value 再拼接展示文本，是否为了比较创建临时切片。CountGroup 只累加整数，不需要保存所有命中记录，也不格式化文本。

这些写法把非必要工作移出比较循环，但不等于句柄比较一定比字符串比较少分配。若两条路径本来都没有分配，改造可能只影响耗时。若仍然同时保存完整原字符串和句柄字段，对象总内存也未必变小。

结果如何解释以及何时回退

我会保留一个按字符串比较的旧实现作为决策参照，让它处理与句柄实现相同的完整批次，而不只比较单个表达式。输入构造、记录存储与文本输出都计入总任务后，才决定是否采用句柄。若收益不足，回退字段表示和准备逻辑即可，外部接口仍可保持文本。

Make 与 Value 可并发调用，不表示本例的 Item 切片可以一边改写一边读取。批次准备结束后应保持数据只读，或采用业务已有的同步机制。句柄也不应当作数据库编号或跨进程身份；需要保存或传输时使用业务原值。

只比较同一种 Handle[string]。大小写、前后空格与其他规范化规则应在入口统一定义，不能指望句柄自动识别“业务上差不多”的两个文本。

相关问题

为什么不先 Value 再比较？这样又使用了字符串比较，没有利用现成句柄的比较形式。Value 适合需要文本的出口。

能承诺零分配吗？不能从接口名称作这个承诺。应在具体代码、工具链与输入下测量，且把准备阶段计入整体评估。

每次输入都是新字符串还适合吗？需要同时评估转换与保留成本；低复用时直接比较原字符串通常更容易维护。

把“减少内容比较工作”与“减少分配”分别判断，才能知道句柄改造究竟解决了哪一个问题。