订单 request_id 用 UUID 怎么设计：解析入口与数据库字段边界

服务升级到 Go 1.27 后，团队最容易把“能生成 UUID”误解成“数据库字段也应该直接存一段字符串”。更稳妥的做法是先把职责拆开：uuid 负责生成和解析，接口层决定传输形态，持久化层再根据查询与兼容约束选择文本或二进制。这样换存储方案时，不会把 API 合同一起拖进迁移。

Go 1.27 的 uuid 标准库解决的是 UUID 的生成与解析，不替你决定 JSON 字段、数据库类型或主键策略；这三个选择应分别验证。

先把 UUID 的三种职责分开

一个订单请求通常会经历“创建标识—通过 HTTP 传输—写入数据库—再次读取”四个边界。Go 1.27 官方发布说明把 uuid 描述为用于生成和解析 UUID 的新标准库包，这意味着它提供的是基础能力，而不是完整的订单 ID 方案。可以把这段职责关系抽象成 uuid 生成器、HTTP request_id 字符串和 uuid.Parse 解析器三个节点。

把这三个角色分开后，排错会简单很多：生成失败属于创建路径问题；解析失败属于输入合同问题；数据库写入失败则是存储映射问题。不要用数据库报错去反推 HTTP 参数是否正确。

接口层为什么仍建议使用字符串

UUID 在 HTTP、JSON、日志和人工排查场景中通常以字符串出现。字符串可读、可复制，也能直接作为路径参数或 JSON 字段。接口收到值后，第一件事是解析，而不是在业务函数里手工判断连字符位置。

type CreateOrderRequest struct {
    RequestID string `json:"request_id"`
}

func parseRequestID(v string) (uuid.UUID, error) {
    if v == "" {
        return uuid.Nil, errors.New("request_id is required")
    }
    return uuid.Parse(v)
}

这里的关键不是把错误文案写得多复杂，而是让非法输入停留在入口层。业务层拿到的应该是已经验证过的 UUID 值，避免出现“同一个请求在不同函数里被不同规则解析”的情况。

生成策略要服从数据边界

新建对象时生成 UUID，读取外部对象时解析 UUID，这是最小而清晰的分界。不要为了复用一个函数，把“生成一个新值”和“检查一个已有值”合并成遇到空字符串就自动生成的逻辑；那会掩盖调用方漏传 ID 的问题。

文本列与二进制列：别只比较长度

文本列的优势是日志、SQL 排查和跨系统交换直观；二进制列则更紧凑，但需要明确驱动映射、查询工具展示方式和历史数据转换策略。已有系统如果大量按字符串拼接 SQL、导出 CSV 或依赖人工检索，直接改成二进制通常会把运维成本转移到别处。图中的 HTTP 字符串先对应领域 UUID 值，再按约束落到文本列或二进制列。

相反，如果表规模、索引空间或跨服务写入约束已经成为明确问题，可以评估二进制存储。但这应该由现有查询、索引和迁移窗口驱动，而不是因为 Go 1.27 新增了包就同步改表。

最容易踩中的三个反例

把空值自动当成新 UUID

这会让缺失参数变成一个看似合法的新请求，问题直到落库或审计时才暴露。创建和解析应使用两个语义明确的入口。

在数据库层重新格式化 UUID

如果 API、领域层和数据库各自改变大小写、连字符或字节序，回读时就可能出现“同值不同形”。固定一种映射，并在迁移脚本中明确记录转换规则。

只测生成，不测坏输入

正常生成只能证明 happy path。至少补测空字符串、非法字符、长度不对、带连字符和无连字符输入，以及旧数据回读。

上线前的判断清单

• Go 版本和构建环境确实使用 Go 1.27，且依赖声明与团队工具链一致。
• 接口层只接收并验证字符串，领域层不重复解析。
• 数据库映射在文档、迁移脚本和回读代码中保持同一规则。
• 日志中保留可检索的请求标识，但不把未验证输入当作可信主键。
• 灰度期间同时验证新写入、旧数据读取、索引查询和导出任务。

相关问题

Go 1.27 的 uuid 包会替代所有第三方 UUID 库吗？

不会。它提供标准库级的生成与解析能力；项目仍需按版本兼容、额外格式和已有数据合同判断是否迁移。

接口里可以直接传 UUID 的二进制值吗？

通常不值得这样做。HTTP 和 JSON 以字符串表达更容易调试，二进制优势更适合在明确的存储边界评估。

迁移 UUID 字段前最先检查什么？

先盘点读写代码、索引、导出任务和历史数据格式，再决定是否改列类型；不要只修改 ORM 字段。

小结

Go 1.27 的 uuid 包让生成和解析有了更统一的标准库入口，但工程上的正确答案仍是分层：字符串服务于接口，解析后的值服务于领域逻辑，文本或二进制服务于存储约束。把边界写进代码和回归清单，升级才不会演变成一次无准备的数据库迁移。