Go x/text/secure/precis 两个昵称看起来一样为什么规范化后仍不同

我在处理国际化昵称时遇到过一个很容易误判的现象：两个名字肉眼看着一样，调用 precis.Nickname.String 后仍然不相同。原因通常不是规范化失效，而是把“保存时的强制处理”和“比较时的等价判断”当成了同一件事。

官方文档：https://pkg.go.dev/golang.org/x/text/secure/precis

昵称展示值可以保留原样，冲突检测应使用 precis.Nickname.Compare 或 CompareKey。String 负责准备与强制处理，不等于比较阶段的全部规则。

先把展示文本和比较文本分开

precis.Nickname 实现 RFC 8266 的昵称 profile。它会处理非 ASCII 空格、首尾空格、连续空格和 NFKC 规范化；但 RFC 明确把大小写映射放在比较规则中，适合用来判断冲突，而不是强行改写用户看到的昵称。

因此，String("Foo") 与 String("foo") 是否得到相同展示文本，不应该作为昵称冲突的唯一判断。业务要问的是“这两个昵称在 Nickname profile 的比较规则下是否等价”。

用正确 API 处理昵称冲突

下面的写法把展示文本、比较结果和索引键分开。示例只说明 API 关系，不把示例输出冒充本机运行证据。

package main

import (
    "fmt"

    "golang.org/x/text/secure/precis"
)

func main() {
    profile := precis.Nickname
    left, right := "Foo", "foo"

    // String 用于准备并强制处理输入；错误表示昵称不能接受。
    leftDisplay, err := profile.String(left)
    if err != nil {
        panic(err)
    }
    rightDisplay, err := profile.String(right)
    if err != nil {
        panic(err)
    }

    // Compare 使用昵称的比较规则判断冲突，不要只比较展示字符串。
    sameNickname := profile.Compare(left, right)

    // CompareKey 适合放入哈希表或唯一索引，错误不能被忽略。
    key, err := profile.CompareKey(left)
    if err != nil {
        panic(err)
    }
    fmt.Println(leftDisplay, rightDisplay, sameNickname, key)
}

实际项目中可以把 leftDisplay、rightDisplay 作为展示或审计字段，把 CompareKey 作为冲突检测键。若两个输入不能被 profile 接受，Compare 会返回 false；若需要知道拒绝原因，应分别调用 String 或 CompareKey 保存错误。

为什么“看起来一样”仍可能不等价

Unicode 中存在视觉相似但码点不同的字符。Nickname profile 的 NFKC 和比较规则能减少一部分差异，但 RFC 8266 没有替应用完成所有 confusable 字符识别。另一个常见误区是把昵称当成账号身份：昵称只适合显示、搜索和冲突控制，认证、授权、订单归属仍应绑定稳定的用户 ID。

如果业务还要求最大长度、禁止某些脚本或限制混淆字符，应在 PRECIS 之后增加明确的应用规则，并把规则版本记录在数据模型中。不要为了“看起来统一”直接删除字符或自行做不可逆替换。

常见问题

为什么不用 strings.ToLower 直接比较？

它只表达大小写处理，不能覆盖昵称 profile 的空格映射、NFKC 和非法输入检查。冲突检测应交给 Compare，这样规则与 profile 保持一致。

String 返回成功后还需要检查 CompareKey 吗？

需要。展示值合法不代表你已经生成了正确的比较键；写入唯一索引前应调用 CompareKey 并处理错误。

昵称相同就可以视为同一个用户吗？

不可以。昵称是可变的展示标签，用户 ID、URI 或其他稳定身份才应参与认证和授权。