Go unique.Handle 如何复用相同值：句柄相等性、垃圾回收与缓存边界

如果一批请求反复携带相同的字符串标签，直接比较长字符串既要看内容，也容易让业务代码到处维护自己的去重表。Go 1.23 的 unique 包提供了更窄的答案：用 unique.Make 为可比较值生成 Handle，相同值生成的句柄可以直接比较，再通过 Value 取回原值。

unique.Handle 适合做“值的规范化身份”，不适合替代带上限、过期时间和主动淘汰的业务缓存；如果希望内部条目继续存活，必须让对应的 Handle 仍被引用。

先把重复标签变成可比较的身份

这个小例子不做通用缓存，只解决一个明确问题：把请求标签规范化后作为 map 的键。标签是字符串，满足可比较约束；规范化后，业务层保存 Handle[string]，需要展示时才调用 Handle.Value。

package main

import (
    "fmt"
    "unique"
)

func main() {
    hotA := unique.Make("hot")
    hotB := unique.Make("hot")
    cold := unique.Make("cold")

    fmt.Println(hotA == hotB)       // true
    fmt.Println(hotA == cold)       // false
    fmt.Println(hotA.Value())       // hot
}

这里的真实调用链是 unique.Make 生成 Handle，随后由 Handle.Value 回读值；hotA 与 hotB 的相等性来自它们传入的字符串相等，而不是调用时机相同。句柄值本身可以安全地放进 map 或结构体中。

为什么句柄比较更适合长值

字符串相等比较在内容较长或前缀高度相同时，需要继续检查更多字节。Handle 的相等比较则是身份比较，官方文档将它描述为通常比比较原值更高效。这个收益来自“先规范化、后比较”，不是来自把所有业务对象都自动变成指针。

代价也很明确：调用方要保存 Handle。如果只写 unique.Make(label).Value()，拿到的只是一个字符串，无法用这个临时 Handle 表达长期保留意图；内部条目也不应被当作永不回收的全局字典。

垃圾回收决定了缓存边界

可以把 Handle 的生命周期看成一个状态变化：只要某个值对应的 Handle 仍然可达，规范化值就有保留依据；当出现 Handle 失去引用 的情况，内部条目会被标记为可删除，之后进入 GC 可回收内部条目 的状态。这个机制解决的是内存生命周期，不提供业务层的容量控制。

因此，用户标签、协议枚举、地址细节这类“值域有限或重复率高”的场景可以考虑它；用户生成内容、无限增长的请求 ID、需要按最近最少使用淘汰的数据，则应使用带明确策略的缓存或数据库。

验收：把三个边界跑一遍

先用 Go 1.23 或更高版本运行上面的程序，预期输出依次为 true、false、hot。再把标签类型换成切片，编译器会拒绝它，因为切片不是可比较类型；这正是 API 在编译期给出的边界。

// 不能通过编译：[]byte 不是 comparable
// h := unique.Make([]byte("hot"))

如果需要规范化复合值，可以使用只含可比较字段的结构体，例如 struct{Kind, Zone string}。取回结构体时记住 Value 是浅拷贝：若字段未来包含引用型数据，就不要把“句柄相等”误读成深拷贝或不可变保证。

相关问题

unique.Handle 能代替带 TTL 的缓存吗？

不能。它不提供 TTL、容量上限、命中统计或主动删除接口；需要这些能力时仍应使用专门的缓存组件。

Make 可以在多个 goroutine 中调用吗？

可以，官方文档明确说明 Make 可并发使用；业务代码仍需自行保护 Handle 之外的可变状态。

什么时候只保存 Value 就够了？

如果只需要当前字符串、不需要依赖规范化身份，直接保存原值更简单；只有在需要频繁比较或在结构体间传递规范化身份时，才值得保留 Handle。

小结

unique 的核心是把“相同值”映射为稳定、便于比较的 Handle，并让垃圾回收参与内部条目的生命周期管理。使用时抓住三点：类型必须可比较、比较的是 Handle、生命周期由 Handle 是否仍被引用决定。把这三条和业务缓存的容量与过期需求分开，边界就不会混乱。