Go UUID NewSHA1 使用不同命名空间为什么产生不同标识

我第一次把业务名称映射成 UUID 时，最容易误判的一点是：NewSHA1 不是“只对名称做 SHA-1”。它会把命名空间 UUID 和名称字节一起作为输入，再按 UUID v5 的规则设置版本与变体位。因此，同一个名称换了命名空间，得到不同标识是预期行为；只有命名空间和名称字节都相同，结果才稳定一致。

官方地址：https://pkg.go.dev/github.com/google/uuid

NewSHA1 为什么会把命名空间算进去

官方文档将 NewSHA1 定义为基于给定命名空间和名称数据生成 SHA-1（版本 5）UUID，底层等价于调用 NewHash(sha1.New(), space, data, 5)。命名空间不是备注字段，而是哈希输入的一部分。可以把它理解成给同一个名称划分了不同的命名域："order-1001" 在 DNS 域和 URL 域里并不是同一个输入。

换命名空间，为什么同名也会换结果

github.com/google/uuid 提供了 NameSpaceDNS、NameSpaceURL、NameSpaceOID 和 NameSpaceX500 等公开命名空间常量。这些常量的 UUID 值不同，所以对同一段名称调用 NewSHA1 时，哈希输入的前半部分不同，最终标识自然不同。

package main

import (
    "fmt"

    "github.com/google/uuid"
)

func main() {
    name := []byte("order-1001")

    // 同一名称放进 DNS 命名域，结果在相同输入下可复现。
    dnsID := uuid.NewSHA1(uuid.NameSpaceDNS, name)
    // 切换到 URL 命名域后，哈希输入变化，结果也会变化。
    urlID := uuid.NewSHA1(uuid.NameSpaceURL, name)

    fmt.Println("DNS:", dnsID, "version:", dnsID.Version())
    fmt.Println("URL:", urlID, "version:", urlID.Version())
}

这里不应把两个结果当成“算法不稳定”。对同一个命名空间重复传入同样的字节，NewSHA1 是确定性的；变化来自命名域本身。图中的两个命名空间面板表达的是输入边界不同，不是某次运行的截图或固定输出。

怎样保证跨服务生成的 ID 一直一致

稳定性要求的不只是“都调用 NewSHA1”，还包括输入字节完全一致。建议把命名空间、名称规范化和编码写进协议，而不是让每个服务自行决定：

如果名称来自多个字段，可以先定义一个明确的规范字符串，再转换为字节。例如把租户和订单号用固定分隔符拼接，并禁止调用方自行改变字段顺序。规范化规则是业务协议的一部分，不能依赖某个服务当前的字符串实现细节。

NewSHA1 适合什么场景，不适合什么场景

它适合“同一业务名称在不同时间、不同实例中都要得到同一 UUID”的场景，例如导入外部对象、建立幂等键或生成跨系统映射标识。若目标是每次都要新的随机 ID，应选择随机 UUID，而不是把时间或随机数偷偷拼到名称里。

同时，确定性 UUID 不是加密、密码存储或安全签名方案。不要因为结果使用 SHA-1 就把它当作防篡改摘要；这里更重要的是稳定的命名映射和可复现性。需要安全哈希、密码派生或签名时，应使用对应的密码学方案。

常见问题

同一个名称换大小写，结果会一样吗？

不会自动一样。名称最终以字节参与计算，Order-1001 与 order-1001 是不同输入；是否统一大小写要由业务协议先规定。

把 NameSpaceDNS 换成 NameSpaceURL 是不是升级了算法？

不是。算法仍然是 UUID v5 的 SHA-1 名称 UUID，变化的是命名空间，也就是输入域。它会产生另一组稳定结果。

项目迁移时能直接换一个命名空间吗？

不建议直接替换。新命名空间会让同一业务名称映射到新 UUID，应保留旧域并通过映射、双写或版本化策略完成迁移。