Go unique.Make 怎样缓存可比较字符串的唯一值处理空输入并保留错误边界

如果一个服务反复处理相同的字符串标签，可以把标签先交给 unique.Make，再把返回的 unique.Handle[string] 作为进程内键。相同内容会得到相等句柄，比较时可以直接使用 ==；需要展示或写日志时，再调用 Value() 取回字符串。

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

这解决的是“重复值的进程内身份比较”问题，不是带过期时间的缓存，也不是跨进程稳定 ID。下面从一个标签计数场景切入，重点处理空字符串、错误边界和回退方式。

先确认句柄化解决的是什么问题

假设消息系统里有大量 queue/east、queue/west 这样的标签，业务对象会长时间持有它们，并且需要频繁判断两个标签是否相同。直接比较字符串当然能工作，但当同一批值被反复转换、保存和比较时，可以评估是否把内部表示改成句柄。

unique 包提供的是值的规范化身份：它接收满足 comparable 约束的值，Make 返回对应的 Handle[T]。两个句柄是否相等，跟创建它们的原值是否相等保持一致。这里的“唯一”不是把输入整理成无重复列表，输入出现两次仍然可以在业务计数中累加两次。

如果标签大多只比较一次，或者几乎没有重复，句柄化未必值得。转换成本、索引结构和生命周期都要算进改造评估，不能只看一次句柄比较的成本。

实现字符串句柄与业务索引

先把句柄限制在一个内部函数中。外部仍接收字符串，内部的计数表使用 unique.Handle[string] 作为键，这样可以在不改变日志和输入协议的情况下试用。

package main

import (
	"errors"
	"fmt"
	"unique"
)

type Label = unique.Handle[string]

// MakeLabel 负责统一入口规则：业务禁止空标签时，在 Make 之前返回错误。
func MakeLabel(text string) (Label, error) {
	if text == "" {
		return Label{}, errors.New("标签不能为空")
	}
	return unique.Make(text), nil
}

// BuildCounts 只把有效标签转换成句柄，并由业务 map 管理计数生命周期。
func BuildCounts(input []string) (map[Label]int, error) {
	counts := make(map[Label]int)
	for _, text := range input {
		label, err := MakeLabel(text)
		if err != nil {
			// 保留原始错误边界：遇到非法输入时让调用方决定跳过还是终止。
			return nil, fmt.Errorf("处理标签 %q: %w", text, err)
		}
		counts[label]++
	}
	return counts, nil
}

func main() {
	counts, err := BuildCounts([]string{"queue/east", "queue/west", "queue/east"})
	if err != nil {
		fmt.Println("构建失败:", err)
		return
	}

	left := unique.Make("queue/east")
	right := unique.Make(string([]byte("queue/east")))
	// 相同原值对应相等句柄，不必先取回字符串再比较。
	fmt.Println("句柄相等:", left == right)

	// 显式规定展示顺序，避免把 map 的遍历顺序当成业务顺序。
	for _, text := range []string{"queue/east", "queue/west"} {
		label := unique.Make(text)
		fmt.Printf("%s: %d\n", label.Value(), counts[label])
	}
}

这个示例把“输入是否合法”和“值怎样取得句柄”放在同一个入口。若业务允许空字符串，只需删除入口的错误分支，空字符串就会像其他字符串一样成为普通值；不要把空字符串、零值 Label{} 和错误状态混为一谈。

把比较留在内部，把文本留在出口

在上面的代码中，两个内容相同的字符串会得到相等句柄，left == right 的结果应为 true。两个 queue/east 输入只占用同一个逻辑键，但计数会累加到 2。这个结果是由代码和接口语义推导出的预期，不应写成已经执行过的日志。

内部对象可以保存 Label，比较时继续使用句柄；需要写日志、展示页面或返回 API 时再调用 Value()。这样可以把身份比较和文本传输分开，避免每次判断都绕回字符串层。

句柄不是数据库主键。需要落盘或跨进程传输时，保存原字符串或业务定义的稳定编码；进程启动后再按当前进程的规则构造句柄。也不要把 Value() 的结果当成可修改的内部缓冲区。

为输入错误保留清晰回退路径

标题中的“处理空输入”不是指 unique.Make 会替业务抛出错误，而是要先定义应用自己的输入规则。对于标签字段，常见选择有两种：

如果输入还需要去空白或忽略大小写，必须在唯一入口完成规范化。例如先决定是否调用 strings.TrimSpace、是否转换大小写，再把规范化后的结果传给 Make。部分调用方传原值、部分调用方传规范化值，会让“相等”失去统一含义。

检查并发、生命周期和适用边界

官方文档说明 Make 和 Value 可以并发使用，但这不代表示例中的 map[Label]int 可以被多个 goroutine 同时写。需要共享计数时，仍然要使用互斥锁、单 goroutine 所有权或其他并发安全的数据结构。

句柄的有效性跟应用仍持有的引用有关。只要计数表、对象或其他结构继续保留句柄，就不能把它理解成“已经自动淘汰的缓存条目”。unique 本身不替业务提供 TTL、删除接口、容量上限或按时间清理；这些策略应放在业务索引层。

类型方面，字符串是本例最清晰的选择。虽然泛型签名允许其他可比较类型，但数组、结构体、浮点值等类型可能有不同的业务相等语义。先定义“什么算同一个标签”，再决定是否使用句柄，不要把 comparable 约束直接当成业务规则。

相关问题

unique.Make 会自动排序标签吗？不会。句柄只表达相等关系，输出顺序由调用方或单独的排序逻辑决定。

能不能把 Handle 当成跨服务 ID？不建议。它适合当前进程内的比较和索引，跨进程协议应使用字符串或业务定义的稳定编码。

只有一次计数任务也要使用 unique.Make 吗？通常不需要。低复用场景直接使用 map[string]int 更直观，句柄化应建立在重复值长期复用、比较频繁且改造收益可测量的场景上。

实际接入时，可以先只替换一个内部索引，保留字符串输入、日志和持久化格式；当空输入、并发访问和回退路径都清楚后，再决定是否扩大范围。