不能直接用go.uuid生成分布式唯一序号，因其v4 uuid无时间戳不可排序、128位过长、高并发下熵池阻塞，v1版本又依赖mac和时钟易在云环境冲突或回拨失效。
Go-uuid 库早已停止维护，github.com/satori/go.uuid 在 Go 1.12+ 中会因缺少 unsafe.Slice 兼容性而编译失败，且其生成的 UUID 不满足分布式系统对「单调递增」或「时间可排序」的需求。真正在生产环境用 Go 做分布式唯一序号，不该用它。
为什么不能直接用 go.uuid 生成「分布式唯一序号」
「唯一序号」在分布式场景下通常指：全局唯一、无冲突、可排序（便于分页/索引）、低延迟生成。而 go.uuid 默认生成的是 v4 随机 UUID，它：
- 不带时间戳，无法按生成时间排序
- 128 位太长（36 字符），不适合作为数据库主键或 URL ID
- 依赖 crypto/rand，高并发下可能有熵池阻塞风险
- v1 版本虽含时间戳，但依赖 MAC 地址和时钟，多容器/云环境易冲突或回拨失效
替代方案：使用 github.com/google/uuid 或 github.com/oklog/ulid
推荐两个更现代、更可控的选项：
-
github.com/google/uuid：官方维护的 UUID 库，兼容 v4/v1/v5，性能好，但仍是标准 UUID，长度和排序性没改善 -
github.com/oklog/ulid：生成 128 位 ULID（Universally Unique Lexicographically Sortable Identifier），前 48 位是毫秒级时间戳，后 80 位是随机熵，字符串长度 26，天然可排序、无状态、无需中心节点
示例（ULID）：
import "github.com/oklog/ulid"
func genID() string {
t := time.Now()
entropy := ulid.Monotonic(ulid.Timestamp(t), 0)
return ulid.MustNew(ulid.Timestamp(t), entropy).String()
}
注意：ulid.Monotonic 能避免同一毫秒内重复，适合高并发；若用 ulid.DefaultEntropy，则需自己处理碰撞重试。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
真正需要「序号」而非「ID」时，考虑 snowflake 变种
如果业务要求是「纯数字、自增倾向、支持分片」（比如订单号、支付流水号），UUID/ULID 都不合适，应选 snowflake 类方案：
-
github.com/bwmarrin/snowflake：最常用，需传入 node ID（如机器 ID 或配置的 shard ID） -
github.com/sony/sonyflake：支持自定义起始时间、更紧凑（39 位时间 + 8 位 ID + 12 位序列）
关键点：
- node ID 必须全局唯一，K8s 环境建议从
POD_NAME或 ConfigMap 注入，别硬编码 - 时间回拨会导致阻塞或错误，
sonyflake提供SetTimeFunc可接入 NTP 校准逻辑 - 生成的
int64数字 ID 直接存 DB 效率高，但要注意 MySQL 的BIGINT UNSIGNED映射问题
Go 微服务中 ID 生成的部署注意事项
无论选 ULID 还是 Snowflake，都得考虑实际部署约束：
- 无状态服务里，不要把 ID 生成器做成单例全局共享——它内部可能含时钟/计数器状态，跨 goroutine 并发调用需加锁或用 sync.Pool 缓存实例
- 在 Istio/Service Mesh 下，Pod 重启可能导致 node ID 冲突，建议用
hostname+pod UID拼接作为 snowflake node ID - 测试阶段务必模拟时钟回拨（如用
gockmock 时间函数或本地改系统时间），验证降级行为是否符合预期
最常被忽略的是：ID 的语义边界。ULID 和 Snowflake 都不保证「绝对连续」，如果你的下游系统（比如某老 ERP）硬性要求「整数自增无跳号」，那只能走数据库 INSERT ... RETURNING id 或单独的号段服务——这时候 Go-uuid 就彻底不该出现在架构图里了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
