Go UUID Validate 和 Parse 的用途有什么区别

Go 的 google/uuid 包中，Validate(s) 用来判断文本是否符合库支持的 UUID 格式，只返回 error；Parse(s) 用来解码文本，返回 UUID 值和 error。后续要比较、存储或规范化 UUID 时通常直接 Parse；只需要报告格式是否有效时可以 Validate。但两者都不能替你定义“接口只允许36位小写格式”等业务约束。

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

接口设计的关键不是先规定所有入口都调用 Validate，而是先明确调用方需要什么：保留输入文本、取得 UUID 值，还是强制一种唯一文本形式。

先按调用方需要的结果选择函数

如果一段代码先 Validate，再 Parse，只是为了获得 UUID 值，往往是在重复处理同一份输入。先明确格式要求，再选择一次解码路径更容易解释错误来源。不过，需要额外约束时不能仅因 Parse 成功就省略策略判断。

Validate 并不只接受36位标准文本

官方 Validate 支持带连字符文本、URN、32位连续十六进制文本，以及花括号包裹的形式。Parse 也支持这些常见输入。因此“Validate 成功”等价于“必须使用小写36位文本”的推断不成立。十六进制字母大小写也不应被误当成这两个函数自动实施的统一小写规则。

还有一个需要注意的细节：官方 Parse 的38字节兼容分支只检查中间的 UUID 内容，而 Validate 会检查外侧是否为花括号。不要把 Parse 当成任意场景下都严格等价的格式校验器。这个差别服务于兼容解码和格式判断的不同用途，不应据此依赖不规范的包裹输入。

设计新接口时，最好直接说明允许哪几种写法。若旧接口接受多种形式，可以在入口解码后统一生成规范文本；若签名、缓存键或唯一性比较依赖原始字符串，则应先统一表示策略，避免同一 UUID 的多个文本形式被当成不同标识。

把严格接口格式写成独立契约

下面给出一个明确约定：只接受36字节小写带连字符形式，并拒绝零 UUID。这里的长度、大小写和零值策略均由应用决定；示例未要求 UUID 必须属于某个版本。

package main

import (
    "fmt"

    "github.com/google/uuid"
)

func parseCanonicalID(raw string) (uuid.UUID, error) {
    // 本接口只接受 36 字节、小写、带连字符的规范表示。
    if len(raw) != 36 {
        return uuid.Nil, fmt.Errorf("标识符必须采用36位规范格式")
    }
    id, err := uuid.Parse(raw)
    if err != nil {
        return uuid.Nil, fmt.Errorf("标识符格式无效: %w", err)
    }
    // String 生成规范表示；比较原文可以拒绝大写等不同写法。
    if raw != id.String() {
        return uuid.Nil, fmt.Errorf("标识符必须使用小写规范格式")
    }
    // 零值禁用属于本接口策略，不是 Parse 的通用格式定义。
    if id == uuid.Nil {
        return uuid.Nil, fmt.Errorf("本接口不接受零UUID")
    }
    return id, nil
}

func main() {
    raw := "ab763252-3fd7-4fa0-a28d-97f0efce68b2"
    id, err := parseCanonicalID(raw)
    if err != nil {
        fmt.Println("输入不符合接口要求:", err)
        return
    }
    // 成功后继续传递UUID值，无需重复解析字符串。
    fmt.Println(id.String())
}

代码中的原文比较很重要。若先 Parse 再调用 String，然后拿规范化后的文本重新检查，原始大小写和格式差异已经被消除，无法判断用户最初是否遵守了接口要求。对“宽松接收并规范化”来说这没有问题，但对“必须提交规范格式”来说就是两种不同策略。

示例用于读者自行集成，未作为实际运行记录。它没有查数据库，也没有由一个可解析的标识推断资源存在或用户有权访问资源。

错误、版本和业务资源分别处理

Parse 返回错误时，调用方不能继续使用同时返回的 UUID 当作已成功解析的标识。示例通过返回 error 停止后续处理；返回的 uuid.Nil 只是失败路径中的占位值。若忽略错误再比较零值，很容易混淆“解析失败”和“成功解析了全零 UUID”。

是否允许某个版本、某个 variant 或全零值，要依据接口契约额外判断。格式判断与解码不承担资源存在性检查，更不承担访问控制。即使字符串完全规范，仍要按应用逻辑检查资源及调用者权限。

对用户输入优先保留普通 error 处理。MustParse 的用途偏向已知常量的便捷初始化；把它直接用在未受信任的输入上，会把输入错误变成 panic，不利于给调用方返回清楚的失败原因。

选择宽松兼容还是严格拒绝

对于新设计的公开参数，采用唯一表示通常便于文档、日志和缓存对齐；对于历史数据导入，兼容多种格式可能更实用。二者都可以建立在库的解码能力上，但应在接口文档里说明是否做规范化，以及原始文本是否保留。

• 只看格式：使用 Validate，但说明支持的文本范围。
• 需要 UUID 值：调用 Parse 并处理错误。
• 严格36位小写：独立实施原文格式约束。
• 版本与零值：作为领域规则单独判断。
• 资源及权限：交给业务层处理，不能从格式成功中推导。

Parse 成功后还要 Validate 吗？如果只是需要已解码的 UUID 值，通常没有必要再做同类判断；若要求某种特定输入形式，应检查那个具体契约，而不是仅添加一次宽范围 Validate。

Validate 会判断 UUID 是否真实存在吗？不会。它判断文本格式，与资源记录是否存在无关。

String 可以还原原始文本吗？它生成 UUID 的规范文本，不是原始文本存档。需要保留来源写法时应另存原文。

参考：google/uuid 官方 Parse、Validate 与 String 实现。