Go unique.Make 怎样缓存可比较字符串的唯一值完成一个可复用的最小示例

对字符串调用 unique.Make(text) 可获得 unique.Handle[string]，把这个句柄保存在对象或映射中，就能用句柄比较相同类型的原值，并在需要文本时调用 Value()。它提供值的规范化身份，不提供业务缓存的容量、过期时间或持久化编号。

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

先判断重复标签适不适合句柄化

可以从一个具体信号开始判断：应用长期保存大量对象，每个对象都带有重复出现的队列标签，并且频繁比较这些标签。这里的候选对象是标签字段，而不是整份业务记录。先确认比较语义确实是字符串原值相等，再考虑把内部表示替换成句柄。

如果字符串只是偶尔比较一次，或者每条标签基本不同，转换成本和新的存储管理未必值得。unique.Make 不能凭空减少仍被其他对象保留的原始数据；若转换后还同时长期保存全部原字符串，整体收益需要另算。本篇提供使用写法，不声称已经降低了某个服务的内存。

示例适用于 Go 1.23 及以上标准库。最小改造范围是一个计数索引：输入仍为字符串，索引内部使用 Label 句柄，展示时恢复文本，不涉及网络或数据库迁移。

实现标签句柄与计数索引

package main

import (
    "fmt"
    "unique"
)

type Label = unique.Handle[string]

// BuildCounts 保留字符串原样，以句柄作为进程内的计数键。
func BuildCounts(input []string) map[Label]int {
    counts := make(map[Label]int)
    for _, text := range input {
        h := unique.Make(text)
        counts[h]++
    }
    return counts
}

func main() {
    left := unique.Make("queue/east")
    right := unique.Make(string([]byte("queue/east")))
    other := unique.Make("queue/west")

    // 比较句柄表达相同类型原值的相等关系，不需要取出文本。
    fmt.Println("同内容:", left == right)
    fmt.Println("不同内容:", left == other)

    counts := BuildCounts([]string{"queue/east", "queue/west", "queue/east", ""})
    // 显式指定访问顺序，避免把 map 遍历顺序误当成稳定结果。
    for _, text := range []string{"queue/east", "queue/west", ""} {
        h := unique.Make(text)
        fmt.Printf("%q: %d\n", h.Value(), counts[h])
    }
}

Label 是 Handle[string] 的类型别名。BuildCounts 不主动保留 input 切片，也不建立额外的“字符串到整数”字典；它保存句柄及计数。重复键会累加计数，但计数索引仍是应用自己的 map，其生命周期由应用持有的引用决定。

unique.Make 接收的是 comparable 类型。字符串符合本例要求，因而可直接传入；不需要先生成哈希，也不需要把文本地址拿来当身份。两个内容相同的字符串即使通过不同表达式构造，也应取得相等句柄。

用句柄比较并在出口恢复字符串

按示例语义，left 与 right 相等，left 与 other 不相等。后面三个标签的计数依次应为 2、1、1。这些为代码推导的预期结果，不是实际运行日志。

在内部比较处保留句柄，用 == 表达身份相等；在输出文本的边界使用 Value。不要每次比较前都取回字符串，否则就没有使用句柄比较的必要。Value 返回原值的浅拷贝，本文的 string 不存在可通过该值原地修改字节的接口。

本例的“唯一”不等于“输入去重列表”：输入中出现两次 queue/east，计数仍然要加两次；只是索引中它们归到同一个键。也不等于生成一个可跨进程保存的标签 ID。需要落盘时保存字符串或业务定义的稳定编码，进程启动后再构造句柄。

接入时怎样保留回退路径

接入现有代码时先隔离一个入口，例如只把某个计数器的键改为 Label，让外部调用方继续传字符串。随后把频繁比较标签的字段接到同一类型的句柄。不要一开始就改外部 API、数据文件和日志协议，这些位置需要的往往仍是文本。

这些观察项用于决定上线取舍，不是本篇已经得到的性能结果。测量时要让两种实现处理相同输入，并把转换成本算进去。不能只比较一个现成句柄与一次长字符串比较，就得出整个任务更快的结论。

也不要把应用 map 长期增长归咎于“唯一值缓存没有过期”。只要 counts 还持有句柄键，这些业务条目就仍然存在。需要限量、清空或按时间淘汰时，在业务索引层设计策略；本文没有假设 unique 提供 Delete、TTL 或容量设置。

空字符串、并发和类型有哪些限制

空字符串：本例允许它成为普通标签，所以空字符串计数为 1。若业务禁止空值，应在调用 Make 前显式返回错误，不要把零值 Handle 当成空字符串的替身。只有通过 Make 得到的句柄才用于本例的 Value 调用。

规范化：queue/east、Queue/East 与带空白的文本在本例中不做合并。需要忽略大小写或修剪空白时，先定义业务规则，再统一在入口转换；不要让部分调用方使用原始字符串、部分调用方使用规范化字符串。

并发：官方接口允许并发调用 Make 与 Value，但这不让 BuildCounts 内的 map 变成并发写安全容器。示例只在一个 goroutine 中更新 map；多任务共享索引时，需要应用自己的同步措施。

类型：本例固定为 string，避免把接口动态值、浮点特殊值或复杂结构体的相等语义混在一起。不同的业务标签类型应有明确的转换入口，不要拿泛型的“可比较”约束代替业务身份定义。

相关问题

unique.Make 会排序标签吗？不会。展示顺序由调用方决定，示例为此单独指定字符串列表。

是否可以直接缓存计算结果？句柄可做应用缓存键，但计算结果、过期策略与并发控制仍属于应用缓存。

只想统计一次重复次数也需要句柄吗？通常 map[string]int 更直接。句柄更值得在值被长期复用且反复比较的具体场景中评估。

先保持业务相等语义与输出协议，再在内部表示层引入句柄，改造范围和回退路径都会更清楚。