不能直接用 time.Now().UnixNano() 生成分布式 ID，因其纳秒级时间在高并发下仍会重复，且无机器/进程标识导致跨节点不唯一；加锁串行化则引发性能瓶颈。
为什么不能直接用 time.Now().UnixNano() 生成分布式 ID
因为毫秒级时间戳在高并发下极易重复，UnixNano() 虽然精度高，但同一纳秒内多个协程同时调用仍会撞车；更关键的是，它不带机器/进程标识，跨节点完全无法保证全局唯一。哪怕加锁串行化，也会成为性能瓶颈——实测在单机 10K QPS 场景下，锁竞争会让吞吐掉到 2K 以下。
真正可用的方案必须满足：毫秒级有序、单机高吞吐、跨节点无协调、ID 可反解出时间与来源。Snowflake 是事实标准，但 Go 原生没内置，得自己控节奏。
github.com/bwmarrin/snowflake 的坑和替代思路
这个库封装了 Snowflake，但默认用 nodeID 做机器标识，靠启动时传入——线上多实例部署时容易配错或重复；更严重的是，它内部用 sync.Mutex 保护 sequence，压测发现 4 核机器上 5W QPS 就开始明显延迟抖动。
更稳的做法是：用原子操作代替锁，把 sequence 存进 uint64 的低 12 位，高位存时间戳和 nodeID。这样每次生成只需一次 atomic.AddUint64，无锁且缓存友好。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- nodeID 改为从环境变量或配置文件读取，比如
SF_NODE_ID=12，避免硬编码 - 起始时间戳（epoch）设为服务上线日，而非 Unix 零点，可延长 ID 使用年限
- sequence 溢出时主动 sleep 到下一毫秒，而不是死等或报错——这是生产环境必须处理的边界
如何让 Snowflake ID 在 Go 里真正跑满 CPU 核心
单个 Snowflake 节点本质是单线程瓶颈（sequence 必须递增），但 Go 可以靠“逻辑分片”绕过：启动时按 CPU 核数初始化多个 snowflake.Node 实例，每个绑定不同 nodeID，请求进来用 goroutine ID 或哈希取模路由到对应节点。
示例片段：
// 初始化 8 个 node，对应 8 个逻辑分片
var nodes [8]*snowflake.Node
for i := 0; i < 8; i++ {
nodes[i] = snowflake.NewNode(int64(i))
}
// 生成 ID 时轮询或哈希分配
func nextID() int64 {
idx := atomic.AddUint64(&counter, 1) % 8
return nodes[idx].Generate().Int64()
}
注意：counter 本身也要用 atomic，否则取模前的竞态会导致分片倾斜；实测 8 分片后，单机稳定支撑 20W+ QPS，P99 延迟压在 50μs 内。
HTTP 接口暴露时必须防住的三个点
对外提供 /id 接口看似简单，但线上常因这三点崩：
- 没加限流——恶意刷请求会耗尽 goroutine，用
golang.org/x/time/rate做每秒 10W 请求硬限 - 没设超时——客户端不读响应体，连接会一直占着，必须配
http.Server.ReadTimeout和WriteTimeout - 返回格式裸奔——直接
fmt.Fprintf(w, "%d", id)有安全隐患，应统一 JSON：{"id":"1234567890123456789"}，且id字段用字符串，避免 JS 精度丢失
另外，健康检查接口 /health 要检查本地 node 是否已初始化成功，而不是只 ping HTTP 端口——曾有集群因 etcd 同步延迟导致部分节点 nodeID 未加载，但 HTTP 仍存活，流量打过去就全返回 0。
