Go unique.Make 怎样判断输入是否满足边界

在标签、配置键或内容身份需要被反复比较时，unique.Make 的正确用法不是“把任意输入丢进去再看结果”，而是先把边界分成两层：第一层由 Go 的 comparable 约束在编译期决定，第二层由业务代码在运行时决定。只有两层都通过，规范化后的 Handle 才适合进入共享的身份比较路径。

规模背景：重复比较先成为热点，类型边界却不能后补

假设一个服务要处理大量标签、配置键或规则名称。早期实现通常直接保存字符串，然后在多个模块里重复做相等比较；当同一个值被很多请求反复使用时，比较成本和临时对象管理会散落在调用链上。把值规范化成唯一身份，可以让后续模块主要比较轻量的 Handle。

但这条优化路径有一个前提：规范化的对象必须有稳定的相等语义。unique 包是 Go 1.23 加入标准库的，它解决的是 comparable 值的规范化，也就是通常所说的 interning；它不是输入清洗器、路径校验器或通用序列化器。边界如果没有在入口说清楚，优化反而会把错误输入带进更长的生命周期。

官方资料：https://pkg.go.dev/unique　https://go.dev/doc/go1.23

第一道边界：让 comparable 在编译期先挡住不支持的类型

Make 的签名已经把第一道门写进了类型系统：

func Make[T comparable](value T) Handle[T]

因此，字符串、整数、布尔值、指针，以及所有字段都可比较的结构体可以进入这条路径；切片、映射、函数，以及包含这些字段的结构体则不能直接比较。这个限制不是运行时返回一个错误，而是调用点在编译阶段就无法通过。

package main

import (
	"fmt"
	"unique"
)

// makeTagIdentity 只接收 comparable 类型，让编译器承担第一层筛选。
func makeTagIdentity[T comparable](value T) unique.Handle[T] {
	// Make 按值的相等语义生成可比较的 Handle。
	return unique.Make(value)
}

type Tag struct {
	Name  string
	Level int
}

func main() {
	// string 和所有字段可比较的结构体都满足 comparable。
	a := makeTagIdentity("cache-hit")
	b := makeTagIdentity(Tag{Name: "cache-hit", Level: 1})

	fmt.Println(a.Value())
	fmt.Println(b.Value())

	// 下面的调用不能通过编译：slice、map、func 都没有 == 相等语义。
	// makeTagIdentity([]string{"a", "b"})
	// makeTagIdentity(map[string]int{"a": 1})
	// makeTagIdentity(func() {})
}

这里的好处是边界靠近 API：以后有人把 []byte 或一个带切片字段的结构体传进来，错误会在开发阶段暴露，而不是等到线上某个分支才发现规范化逻辑不成立。代价也很明确：如果输入本来是字节序列，需要先选择一种稳定表示，例如明确字符集后转成 string；这一步会带来转换成本，不能假装不存在。

第二道边界：把业务校验放在 unique.Make 之前

通过 comparable 只说明值“能比较”，并没有说明它“值得被规范化”。例如，空标签是否有意义、名称最大长度是多少、大小写是否应该折叠，都属于业务规则。把这些判断放在 Make 之后，意味着无效值已经进入规范化池，后续再修正会让调用关系变复杂。

package main

import (
	"errors"
	"fmt"
	"math"
	"strings"
	"unique"
)

var (
	ErrEmptyTag = errors.New("tag is empty")
	ErrLongTag  = errors.New("tag is too long")
)

// normalizeTag 把外部字符串变成满足业务规则的稳定身份。
func normalizeTag(raw string) (unique.Handle[string], error) {
	// 先统一首尾空白和大小写，避免同一标签产生多个身份。
	key := strings.ToLower(strings.TrimSpace(raw))
	if key == "" {
		// 空值是否允许属于业务规则，不由 comparable 决定。
		return unique.Handle[string]{}, ErrEmptyTag
	}
	if len(key) > 64 {
		// 长度上限避免把异常输入带入长期存活的规范化路径。
		return unique.Handle[string]{}, ErrLongTag
	}

	// string 满足 comparable，校验完成后再生成规范化 Handle。
	return unique.Make(key), nil
}

// normalizeScore 展示浮点值的额外边界；NaN 不等于自身，不适合直接当身份键。
func normalizeScore(score float64) (unique.Handle[float64], error) {
	if math.IsNaN(score) || math.IsInf(score, 0) {
		return unique.Handle[float64]{}, fmt.Errorf("invalid score: %v", score)
	}
	return unique.Make(score), nil
}

示例里的 len 是按字节计数；如果业务限制的是用户可见字符，应改用明确的 Unicode 规则，而不是照搬这个数字。类似地，大小写折叠、Unicode 归一化、分隔符处理都应在团队约定后集中实现。unique.Make 只负责“相等值共享身份”，不负责替你定义什么叫“同一个业务值”。

统一入口：先转换成稳定的可比较键，再生成 Handle

规模变大后，最容易失控的是“每个调用方都做一点清洗”。一个请求处理器把标签转小写，另一个只做 TrimSpace，最终同一个业务值会出现多个身份。更稳妥的结构是让规范化入口返回一个明确的结果类型，调用方只处理成功或错误。

type TagID = unique.Handle[string]

// TagIDFromInput 是服务边界唯一的标签身份入口。
func TagIDFromInput(raw string) (TagID, error) {
	// 统一转换和校验，避免各个 handler 产生不同的规范化规则。
	return normalizeTag(raw)
}

// sameTag 只比较 Handle，不重新比较原始字符串。
func sameTag(left, right TagID) bool {
	// 相等的输入会产生相等的 Handle，适合做内存中的身份比较。
	return left == right
}

这套入口有两个取舍。收益是规则集中，缓存、路由和内存索引都可以围绕同一个 TagID 工作；代价是转换函数成为基础设施，任何规则调整都可能改变身份分布，需要配合版本化或迁移策略。不要把一个已经用于持久化的 Handle 当成跨进程、跨版本的序列化 ID；文章讨论的是 Go 进程内的值身份。

并发与相等语义：Handle 解决什么，没解决什么

官方文档说明，unique.Make 可以被多个 goroutine 并发使用，Handle.Value 也可并发调用。调用方因此不需要为了“生成同一身份”再包一层全局互斥锁。但并发安全不等于业务状态安全：如果你同时维护一个外部 map、计数器或淘汰表，那些对象仍要按自己的并发模型管理。

还要牢记 Handle 遵守输入类型的相等语义：

• 两个相等字符串得到的 Handle 可以相等，比较 Handle 通常比反复比较长字符串更轻。
• 包含不可比较字段的类型无法进入 Make，不能靠运行时包装绕过类型系统。
• 浮点 NaN 不等于自身；如果它代表“缺失”或“未知”，应在调用前单独建模，而不是直接拿它当身份。
• Value() 返回产生 Handle 的值的浅拷贝；它不是文件句柄，也不负责资源关闭、权限校验或生命周期回收。

落地检查表：判断输入是否满足边界

如果只记一条原则，可以记成：comparable 负责回答“能不能比较”，业务 guard 负责回答“值不值得规范化”，而 unique.Make 负责把通过两层边界的值变成可复用的进程内身份。

常见追问

unique.Make 能不能直接接收 []byte？

不能。切片不可比较。需要先根据编码和规范化规则转换成 string，或者设计一个所有字段都可比较的结构体；转换时要明确复制和内存成本。

只要编译通过，就能说明输入一定有效吗？

不能。编译器只检查类型边界，不检查空值、长度、格式、权限或业务状态。运行时 guard 仍然要放在 unique.Make 之前。

Handle 能不能写入数据库，作为永久主键？

不建议直接这样设计。本文使用的 Handle 是进程内的值身份，持久化主键应由业务明确生成并定义跨版本、跨进程的稳定语义。

多个 goroutine 调用 Make 需要自己加锁吗？

Make 和 Handle.Value 支持并发使用，但外围共享状态不一定安全。只为调用 Make 本身加全局锁通常没有必要，应该分别审查自己的缓存和计数结构。