Go unique.Make 怎么复用重复字符串：句柄比较、生命周期与缓存边界

日志标签、租户标识、地区代码这类字符串在一个长生命周期进程里经常重复出现。Go 1.23 的 unique 包提供了一个更明确的表达：把相等的值交给 unique.Make，得到可比较的 Handle，以后比较句柄就不用反复比较字符串内容。不过它解决的是“重复值的身份表达”，不是一座可以无限增长的全局缓存。

unique.Make 解决的是哪一种重复

假设一个进程不断接收日志事件，每条事件都有一个 service 和 region 字段。它们的文本值可能反复出现，但业务代码通常只关心“这两个标签是不是同一个值”。直接写 serviceA == serviceB 已经足够正确；当同一个值会被放进大量对象、并且比较操作很频繁时，才有必要考虑把它转换成可比较的句柄。

unique.Make 的关键不是返回一个整数序号，而是返回带有类型参数的 Handle[T]。同一个输入值产生的句柄可以直接用 == 比较，调用方不需要自己维护字符串到数字的 map，也不会把不同业务类型的整数 ID 混在一起。

先用一个最小程序验证句柄语义

下面的示例把两个来源不同、内容相同的字符串交给 unique.Make。比较结果来自句柄，而不是调用方自己记录的序号：

package main

import (
    "fmt"
    "unique"
)

func main() {
    first := string([]byte("checkout"))
    second := "check" + "out"

    a := unique.Make(first)
    b := unique.Make(second)

    fmt.Println(a == b)       // true
    fmt.Println(a.Value())    // checkout
}

这里真正应该验收的只有两点：a == b 表示两个输入值相等，Value() 可以取回原始值。不要把句柄的内部表示、地址或打印形式当成稳定的业务数据格式，官方 API 并没有把它设计成可序列化的外部编号。

把 Handle 放进事件对象，而不是复制一套全局映射

在事件聚合场景里，句柄最自然的用法是作为结构体字段。这样每条记录保存的是一个类型安全的身份值，聚合 map 的 key 也可以直接使用它：

package main

import (
    "fmt"
    "unique"
)

type Event struct {
    Service unique.Handle[string]
    Count   int
}

func main() {
    totals := map[unique.Handle[string]]int{}
    for _, name := range []string{"api", "worker", "api", "api"} {
        service := unique.Make(name)
        totals[service]++
    }

    for service, count := range totals {
        fmt.Println(service.Value(), count)
    }
}

这段代码里的 map 只保存句柄到计数的关系，服务名仍然可以在输出阶段通过 Value() 取回。实际项目中要注意 map 的遍历顺序不稳定，不能因为某次输出先出现 api 就把它当成排序保证。

它和字符串比较、手写 intern map 有什么不同

三种方式都能表达“值是否相等”，但维护成本和生命周期不同。先把决策点摆在一起，比看到新 API 就替换更稳妥：

如果 ID 要写入数据库、发到消息队列或让另一个进程理解，应该自己定义稳定的编码规则，不能把 Handle 转成字符串后就假设它可跨边界还原。unique 的价值在进程内部，业务 ID 的价值在系统边界，两者不是一回事。

生命周期是最容易被忽略的成本

很多文章讲到“重复值只保留一份”就结束了，但生产问题往往发生在值并不重复的时候。一次导入如果带来数百万个不同的追踪 ID，每个 ID 都只出现一次，unique.Make 不会凭空消除这些字符串。把它用于无界输入，反而可能让运行时需要长期维护更多关联。

建议先问三个问题：

• 值的集合是否有限且会反复出现，例如固定服务名、地区码、协议方法？
• 句柄是否只在当前进程内使用，不会被写入持久化字段或跨服务传输？
• 是否有基准、堆采样或对象计数证据，证明比较和重复存储确实是热点？

只要第三个问题答不上来，先保留普通字符串通常更容易维护。优化的判断依据应该是业务数据的重复率和生命周期，而不是 API 看起来更“底层”。

并发使用时要看业务容器，而不是只看 Make

多个 goroutine 可以各自调用 unique.Make，但这不等于围绕句柄构建的 map 自动变成并发安全。共享计数器仍然需要互斥锁、分片 map 或其他明确的并发方案；句柄只负责值的身份比较，不负责你的聚合写入。

type ServiceStats struct {
    mu     sync.Mutex
    counts map[unique.Handle[string]]int
}

func (s *ServiceStats) Add(name string) {
    h := unique.Make(name)
    s.mu.Lock()
    s.counts[h]++
    s.mu.Unlock()
}

这个片段省略了构造初始化和读取方法，但边界要保留：锁保护的是 counts，不是“让 Handle 变安全”。如果你的写入量很大，再对锁竞争做基准，别只因为用了 unique 就跳过并发验收。

常见问题

unique.Make 返回的 Handle 能不能直接保存到数据库？

不建议。Handle 面向当前 Go 进程内的值身份，数据库字段需要跨重启仍可解释的业务编码。要持久化就保存原始值或自行定义稳定 ID。

Handle.Value() 返回的字符串一定是同一个底层对象吗？

调用方只应该依赖它返回等价的原始值，不要把底层存储地址、分配方式或实现细节写进业务逻辑。是否复用底层存储不是这个 API 的外部契约。

所有重复字符串都应该改成 unique.Handle 吗？

不应该。只有在值重复率高、比较频繁且生命周期适合的场景才值得评估；普通配置、短列表和低频比较直接使用字符串更清楚。

用了 Handle 还需要给 map 加锁吗？

需要。Handle 可比较不代表 map 支持并发写入，多个 goroutine 更新同一个 map 时仍要使用锁、分片或其他并发容器。

把采用结论落成一张检查清单

• 输入值是否来自有限、重复率高的集合，而不是持续增长的随机 ID？
• Handle 是否只在同一进程内比较，没有被当成跨服务协议字段？
• 是否用基准和堆分析对比过字符串方案，而不是只看代码长度？
• 使用 Handle 作为 map key 时，map 的并发保护和遍历顺序约束是否单独写清楚？

unique.Make 值得记住，但不值得滥用。把它放在稳定、重复、进程内的值集合上，才能让句柄比较带来可验证的收益；遇到无界输入或跨系统数据，普通字符串和明确的业务 ID 反而更可靠。