go标准库无uuid包，需用github.com/google/uuid；推荐newstring()提升性能；uuidv4作主键会降低索引性能，应转存binary(16)或改用自增id。
Go 标准库不自带 uuid 包，必须使用第三方实现（如 google/uuid 或 gofrs/uuid），否则会编译失败或行为异常。
为什么 import "uuid" 会报错
Go 没有官方 uuid 包，直接 import "uuid" 会导致 import "uuid": cannot find package。社区主流选择是 github.com/google/uuid，它兼容 RFC 4122，API 稳定，且被大量项目采用。
- 别用已归档的
github.com/satori/go.uuid（已停止维护，存在竞态和熵不足问题） -
github.com/google/uuid默认生成的是 UUID v4（随机），无需外部熵源，适合大多数服务场景 - 若需 UUID v1（时间+MAC），要显式调用
uuid.NewUUID()（v1）或uuid.NewRandom()（v4），二者行为不同
uuid.NewString() 和 uuid.New().String() 有性能差异吗
有。前者是后者封装后的优化版本：它复用内部字节缓冲，避免重复分配字符串头；在高频 ID 生成场景（如 API 请求 ID、日志 trace_id）中，uuid.NewString() 比 uuid.New().String() 快约 15–20%，GC 压力更低。
- 推荐统一用
uuid.NewString()，语义清晰且性能更好 - 如果需要 UUID 类型做比较或结构体字段，再用
uuid.New()得到uuid.UUID实例 - 注意：
uuid.NewString()返回string，不能直接用于sql.Scanner或需要类型安全的 ORM 字段
在数据库主键中用 UUID v4 是否影响查询性能
会影响，尤其在 B-Tree 索引下。UUID v4 是随机值，插入时导致频繁页分裂和索引碎片，比自增整数主键慢 3–5 倍（取决于数据量和写入密度）。
立即学习“go语言免费学习笔记（深入）”；
- 若业务允许，优先用
BIGINT AUTO_INCREMENT或SERIAL（PostgreSQL） - 若必须用 UUID，PostgreSQL 可考虑
gen_random_uuid()+pgcrypto，MySQL 8.0+ 可用UUID_TO_BIN(uuid(), true)存为BINARY(16)减少存储与索引开销 - 避免把 UUID 当作字符串存为
VARCHAR(36)：既浪费空间，又拖慢索引扫描
如何安全地在分布式服务中生成不重复 ID
UUID v4 在单机上靠加密安全伪随机数生成器（CSPRNG）保证唯一性，但在极端高并发（如每秒百万级）或熵池枯竭的容器环境中，仍存在理论碰撞风险（虽然概率低于 1e-30）。更稳妥的做法是组合使用：
- 用
github.com/google/uuid生成基础 UUID v4 - 若需更强保障，拼接时间戳前缀（如
fmt.Sprintf("%d-%s", time.Now().UnixMilli(), uuid.NewString())），但注意这破坏了标准 UUID 格式 - 真正要求全局单调+唯一时，应换用
twitter/snowflake或segmentio/kafka-go的MessageID生成逻辑，而非硬套 UUID
UUID 不是银弹。生成容易，用对很难——特别是当它成为主键、分片键或缓存 key 时，字节序、排序性、存储格式这些细节，比“能不能生成”重要得多。
