推荐使用 github.com/google/uuid：默认支持安全的 uuidv1/v4，new() 固定生成 v4，newuuid() 优先 v1（时间序）失败降级 v4；精简 16 字符用 fmt.sprintf("%x", id)[:16]；性能无瓶颈，无需额外优化；禁用 time+rand 拼接，避免重复、不兼容及熵源问题。
github.com/google/uuid 是当前 Go 生态中事实标准的 UUID 库，不推荐用已归档的 satori/go.uuid 或手动拼接。它默认支持 v1（时间+MAC）和 v4（加密安全随机），且底层调用 crypto/rand，满足生产环境唯一性与安全性要求。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
怎么选 uuid.New() 还是 uuid.NewUUID()？
两者都可用，但行为不同：uuid.New() 固定生成 UUIDv4（纯随机）；uuid.NewUUID()（v1.3+）优先尝试 UUIDv1（含时间戳、MAC 地址），失败时自动降级为 v4。
如果你需要时间序倾向（比如日志 ID 排序友好），用 NewUUID()；只要强随机性，用 New() 更明确。
注意：v1 依赖系统单调时钟，Docker 容器或某些云环境可能不支持，此时 NewUUID() 会静默回退 —— 这不是 bug，是设计行为。
怎么生成 16 字符精简版文件名？
直接切 String() 前 16 字符有风险：连字符位置不固定（v1/v4 格式一致，但切片前没去横线会出错）。正确做法是先转无分隔符 hex 字符串：
- 用 fmt.Sprintf("%x", id) 得到 32 字符小写 hex（顺序符合 RFC，无需手动调整字节序）；
- 再取前 16 字符：fmt.Sprintf("%x", id)[:16]。
不要用 strings.ReplaceAll(id.String(), "-", "")[:16] —— 多一次字符串分配，且语义冗余。
示例：
id := uuid.New()
short := fmt.Sprintf("%x", id)[:16] // 如 "a1b2c3d4e5f67890"
高并发下 uuid.New() 会不会性能瓶颈？
不会。现代 github.com/google/uuid（v1.4+）已内置优化：
- uuid.New() 底层复用 crypto/rand.Reader，不每次打开 /dev/urandom；
- 没有锁竞争，goroutine 安全；
- 单次生成耗时约 100–300ns（实测），远低于 HTTP handler 开销。
除非你每秒要生成百万级 ID，否则无需自己套 sync.Pool 或缓存 []byte —— 过早优化反而引入复杂度和潜在 bug。
为什么不能用 time.Now().UnixNano() + rand.Intn() 拼接？
这种“轻量 ID”在单机、低并发下看似可行，但踩坑点密集：
- rand.Intn() 默认用 global math/rand，未 rand.Seed() 时所有 goroutine 共享同一种子 → 大量重复 ID；
- 即使加了 seed，time.Now().UnixNano() 在虚拟机或容器里分辨率可能只有 10ms–15ms，同一毫秒内多协程必然冲突；
- 不满足分布式唯一性，无法横向扩展；
- 无法兼容下游系统对 RFC 4122 UUID 的解析需求（比如数据库 UUID 类型、PostgreSQL 的 gen_random_uuid()）。
用 github.com/google/uuid 是 5 行代码解决的事，别自己造轮子。
真正要注意的是：如果服务部署在无熵环境（如某些嵌入式容器或 chroot），crypto/rand 可能阻塞或 panic。上线前务必验证 /dev/urandom 可读，或通过 go test -run=TestRand 类似方式做熵源探测。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
