用 github.com/google/uuid 生成标准 v4 UUID 最省心，直接调 uuid.New() 即可，它基于 crypto/rand.Read() 和系统熵源，严格符合 RFC 4122 v4 规范，无需手动处理版本位、变体位或字节序。
用 github.com/google/uuid 生成标准 v4 UUID 最省心
绝大多数场景下，直接用 google/uuid 库的 uuid.New() 就够了——它底层调用 crypto/rand.Read()，熵源来自操作系统（Linux 读 /dev/urandom，Windows 调 BCryptGenRandom），符合 RFC 4122 v4 规范，无需你操心版本位、变体位或字节序。
- 不用自己拼
fmt.Sprintf或手写位运算：手动实现容易漏掉u[6]和u[8]的版本/变体修正，导致生成的字符串“长得像 UUID”但不合规 - 别再用已归档的
satori/go.uuid：该库已停止维护，且旧版NewV4()在某些 Go 版本下有竞态风险 - 初始化开销可忽略：
uuid.New()单次耗时约 50 纳秒，比一次 map 查找还快
高并发下性能瓶颈？别锁，用 sync.Pool 复用字节切片
当你每秒生成数万以上 UUID（比如网关日志 ID、WebSocket 连接 ID 批量创建），google/uuid 默认行为会频繁分配 16 字节临时内存，GC 压力明显。这时不是加 sync.Mutex，而是复用底层字节数组。
-
google/uuid本身不暴露内部字节池，所以需自行封装：用sync.Pool缓存[]byte，再调rand.Read()填充，最后按规范设u[6]和u[8] - 避免在
New()后立刻.String()：字符串格式化占耗时大头，若后续要存 DB 或传 JSON，优先保留uuid.UUID类型（16 字节）而非字符串（36 字节） - 预生成 + channel 仅适用于固定峰值场景：比如秒杀预热，后台 goroutine 提前生成 10k UUID 塞进带缓冲
chan string（容量建议 2048），但要注意内存水位监控，防止堆积
存数据库别用 VARCHAR(36)，否则索引效率直接砍半
UUID 字符串是 36 字节，但本质是 128 位整数。MySQL/PostgreSQL 都支持 BINARY(16) 存储，查询和排序性能远超文本类型。
git-staged-commit-message
下载
仅从仓库的暂存文件生成 Git 提交消息。当用户要求 Codex 根据暂存更改、缓存差异、Git 索引或已通过 `git add` 添加的文件来编写、起草、创建或建议提交消息时使用；切勿代表用户执行提交操作。
- Go 写入时：用
id.Bytes()得到 16 字节切片，直接绑定到BINARY(16)字段；读取时用uuid.FromBytes()还原 - 别用
uuid.String()存进VARCHAR：不仅多占 130% 存储空间，B+ 树索引比较开销也大得多（字符串逐字符比 vs 整数一次比） - 如果业务需要排序友好（如按创建时间大致有序），考虑
github.com/segmentio/ksuid或自定义 time-based prefix，但注意这会牺牲部分随机性
v4 够用就别碰 v1/v5，除非你真需要语义化或可追溯性
v4 是密码学安全随机数，碰撞概率低于 1e-15（生成十亿个也不太可能重复），适合绝大多数 ID 场景。v1 和 v5 的“优势”其实是双刃剑。
立即学习“go语言免费学习笔记（深入）”；
- v1 暴露 MAC 地址和时间戳：内网可能无所谓，一旦日志外泄或 API 返回给前端，等于主动交出服务器硬件指纹和精确时间
- v5 要求稳定命名空间：比如用
uuid.NameSpaceDNS+ 服务域名哈希作为 namespace，data 部分仍得用rand；千万别用runtime.GoroutineId()（Go 不提供稳定 ID）或os.Getpid()（容器里常为 1）当 namespace - v3/v5 的 SHA-1 计算开销极小（几十纳秒），但哈希过程不可逆，调试时无法从 UUID 反推原始 data，这点必须提前对齐团队认知
真正容易被忽略的是：UUID 不是银弹。高频写入场景（如 IoT 设备心跳）若只靠 v4，DB 主键索引页分裂会更剧烈；此时应结合业务看是否需要 Snowflake 或 KSUID 这类时间有序 ID —— 但那是另一个权衡了。
