Go unique.Handle 怎么做值驻留：句柄相等、Value 取回与垃圾回收边界

日志聚合里经常要比较很长的标签、路由名或资源键。每次直接比较字符串，代码当然能工作，但当同一批值反复出现时，可以先把值交给 unique.Make，再用轻量的 unique.Handle[T] 做相等判断。这个句柄不是把数据永久塞进全局缓存，而是让相同值共享规范化表示，并在仍有句柄存活时保留取回原值的能力。

unique.Handle[T] 适合做“相同可比较值的身份化”：用 Make 获得句柄，用句柄直接比较，用 Value() 在需要输出原值时取回；句柄本身不应被当成永久内存保留方案。

从重复标签开始：为什么需要一个句柄

假设一个请求系统要给每条日志附加租户、路由和区域标签。标签值经常重复，业务判断却散落在多个分支里。若只需要判断“是不是同一个标签”，保存字符串副本并不是唯一选择。

unique 包提供的思路很直接：把一个可比较值交给 unique.Make，得到 Handle[T]。同一个值再次调用 Make，得到的句柄可以直接比较；真正需要写日志或返回接口时，再调用 Value()。

旧写法的痛点：比较值和保存值混在一起

最小的旧写法通常是把字符串放在结构体中，然后直接比较：

type Label struct {
    Name string
}

if left.Name == right.Name {
    // 相同标签
}

这没有错，短字符串或低频路径完全可以继续这样写。问题出在同一批较长值反复参与查找、分组和去重时：每个调用点都要关注值本身，代码也不容易表达“这是一个规范化身份”。

还有一种常见误区是自己维护 map[string]string，把首次出现的字符串当作规范值。它需要额外处理并发访问、生命周期和初始化；如果只是想获得可比较的身份，维护一套自建表反而扩大了边界。

新规则：Make、句柄相等与 Value 取回

先看一个可以直接运行的例子：

package main

import (
    "fmt"
    "unique"
)

func main() {
    first := unique.Make("region-east/order")
    second := unique.Make("region-east/order")
    other := unique.Make("region-west/order")

    fmt.Println(first == second) // true
    fmt.Println(first == other)  // false
    fmt.Println(first.Value())   // region-east/order
}

这里的关键不是把字符串改了名字，而是把比较对象从 string 换成了 Handle[string]。相同输入得到的句柄相等，不同输入得到的句柄不相等；Value() 返回的是规范化后的原值。

类型参数不能随便换

unique.Make 接受可比较类型。字符串、整数、指针和字段全部可比较的结构体可以使用；包含切片、映射或函数字段的类型不能直接作为句柄类型。遇到复合业务对象时，更稳妥的方式是先挑出一个稳定的字符串键或整数编号。

type RouteKey struct {
    Method string
    Path   string
}

route := unique.Make(RouteKey{Method: "GET", Path: "/orders"})
fmt.Println(route.Value().Path)

代码对比：把标签去重放进业务结构

例如请求事件只需要按租户标签分组，可以让结构体保存句柄：

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

func sameTenant(a, b Event) bool {
    return a.Tenant == b.Tenant
}

func newEvent(tenant string) Event {
    return Event{Tenant: unique.Make(tenant)}
}

调用方不需要在每次比较时重新处理字符串。输出时再取值：

event := newEvent("tenant-42")
fmt.Println(event.Tenant.Value())

这段代码的收益是边界清楚：Tenant 表示已经身份化的租户键，而不是一段等待清洗的输入。输入校验、大小限制和日志脱敏仍然要在调用 Make 前完成，unique 不替代业务校验。

兼容注意：句柄不是永久缓存，也不是跨进程身份

第一，句柄的相等关系只服务于当前进程中的句柄使用场景。不要把句柄序列化后交给另一个进程，也不要把它当作数据库主键或跨重启稳定编号。

第二，句柄保持的是值的生命周期，不代表业务可以无限接收外部输入。若把每个用户提交的超长字符串都长期保存成句柄，仍然可能造成内存压力。输入长度、租户数量和保留周期要由业务层控制。

第三，Value() 不是“从句柄里复制一份任意对象”的承诺。它返回与句柄对应的规范化值；要让它继续可用，调用方至少要保证当前句柄仍然存活。

最小验收：用测试确认相等与取回语义

func TestTenantHandle(t *testing.T) {
    a := unique.Make("tenant-42")
    b := unique.Make("tenant-42")
    c := unique.Make("tenant-43")

    if a != b {
        t.Fatal("equal values must produce equal handles")
    }
    if a == c {
        t.Fatal("different values must not share a handle")
    }
    if got := a.Value(); got != "tenant-42" {
        t.Fatalf("unexpected value: %q", got)
    }
}

验收时重点看三件事：相同值的句柄是否相等、不同值是否被区分、取回值是否与输入语义一致。若测试还要观察内存变化，应使用稳定的压力模型和运行时工具，不要把一次垃圾回收后的即时曲线当成 API 保证。

常见问题与采用建议

所有字符串都应该改成 Handle 吗？

不应该。短值、低频比较和需要直接序列化的字段继续使用字符串更简单。句柄更适合重复出现、频繁比较、并且可以明确限定生命周期的可比较值。

Handle 能替代 map 做缓存吗？

不能。句柄解决的是值的规范化和身份比较，不提供业务缓存的过期、淘汰、容量上限或持久化策略。

什么时候直接保留原字符串更合适？

当字段要频繁写入 JSON、日志或数据库，且比较成本并不是热点时，直接保留原字符串通常更直观。也可以同时保留句柄和展示字段，但要避免两份数据被不同路径修改。

把采用边界写进代码评审清单

• 类型是否可比较，值是否已经完成长度、格式和敏感信息处理？
• 句柄是否只用于进程内比较，没有被当成外部 ID 或持久化值？
• 长期容器是否有明确上限，是否能释放不再需要的句柄引用？
• 输出、序列化和排障路径是否在需要的位置调用了 Value()？

如果答案都明确，unique.Handle[T] 就可以作为一层小而清晰的值身份化工具使用。它的价值不在于替所有字符串提速，而在于让“重复值应当共享比较身份”这件事有了标准库语义。