推荐使用 github.com/google/uuid 的 uuid.Parse 进行 UUID 校验，它严格检查格式、分隔符、字符范围及长度（36 字符），失败即非法；不可用 uuid.MustParse 校验，会 panic。
用 uuid.Parse 判断是否为合法 UUID（推荐）
Go 标准库不直接提供校验函数，但 github.com/google/uuid 的 uuid.Parse 是最可靠的方式：它既解析又校验，失败即说明格式非法。
注意不要只看长度或正则匹配——UUID v1/v2/v3/v4/v5 有不同生成逻辑，但字符串表示都遵循 8-4-4-4-12 十六进制格式；uuid.Parse 会严格检查分隔符、字符范围和大小写（默认接受小写，也兼容大写）。
- 必须导入
github.com/google/uuid，标准库crypto/rand或encoding/hex无法替代 - 空字符串、含空格、多连字符、非十六进制字符（如
'g'）都会返回 error - 长度不是 36 字符（含 4 个短横线）会直接失败，比如
"123e4567-e89b-12d3-a456-42661417400"（少一位） - 示例：
u, err := uuid.Parse("123e4567-e89b-12d3-a456-426614174000")成功；uuid.Parse("123e4567-e89b-12d3-a456-42661417400")返回invalid UUID length: 35
不用第三方库时的最小化校验（仅限简单场景）
如果项目禁止引入外部依赖，且只要粗略过滤（例如前端传参预检），可用正则 + 长度组合，但必须清楚它的局限性：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 正则
^[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}$只检查结构，不验证语义（如 v4 要求第 13 位是4，v1 要求第 19 位是8|9|a|b） - 不处理 Unicode 空格、全角短横线等隐形非法字符
- 性能略高（无内存分配），但可靠性远低于
uuid.Parse，仅建议用于日志过滤或客户端缓存校验 - 别用
strings.ReplaceAll(s, "-", "")再判断长度为 32 —— 这会漏掉"----"这类非法输入
区分 UUID 版本（v4 最常用）
很多业务只要 v4（随机生成），这时需额外校验版本位。用 uuid.Parse 解析后，调用 u.Version()：
立即学习“go语言免费学习笔记（深入）”；
-
u.Version() == uuid.Version4表示是标准 v4 UUID - v1 的时间戳部分可能暴露生成时间，v3/v5 是哈希结果，v2 已基本弃用
- 注意：某些旧工具生成的 UUID 可能缺失版本位（如全零），
uuid.Parse仍会成功，但Version()返回0 - 示例：
u, _ := uuid.Parse("f47ac10b-58cc-4372-a567-0e02b2c3d471")→u.Version()是4；而"00000000-0000-0000-0000-000000000000"的版本是0
常见错误：用 uuid.MustParse 做校验
uuid.MustParse 是为已知合法 UUID 设计的 panic 版本，**不能用于校验**：
- 遇到非法输入会直接 panic，无法 recover（除非包层加 defer/recover，得不偿失）
- 它不返回 error，无法区分“合法但不存在”和“格式错误”
- 线上服务若把用户输入喂给
MustParse，一次恶意请求就能导致 goroutine crash - 正确姿势永远是先
uuid.Parse，再判断err != nil
"{123e4567-e89b-12d3-a456-426614174000}"），这些都需要在 Parse 前 trim 和 strip。 
