不能直接 new node(1) 上线，因为硬编码节点 id 在 kubernetes 多副本下必然冲突，且默认以启动时间作 epoch 会导致重启后 id 冲突；必须显式设置固定 epoch、动态分配唯一 node id，并启用时钟回拨防护逻辑。
Go 里直接用 github.com/bwmarrin/snowflake 最省事，但生产环境必须自己控制 epoch、节点 ID 分配和时钟回拨逻辑——否则发号器会重复或卡死。
为什么不能直接 new Node(1) 就上线
默认 node, _ := snowflake.NewNode(1) 使用系统启动时间作为 epoch，会导致不同进程重启后生成 ID 冲突；而且 1 是硬编码节点 ID，在 Kubernetes 多副本下必然重复。
实操建议：
- epoch 必须显式设为一个固定时间点（如
2023-01-01T00:00:00Z），用time.Date(...).UnixMilli()算出毫秒值传给snowflake.NewNodeWithCustomEpoch - 节点 ID 不能写死：从环境变量读（
os.Getenv("SNOWFLAKE_NODE_ID")），或用 Consul/ZooKeeper 分配，失败时 panic 而不是 fallback 到 1 - 检查
node.StartTime是否早于 epoch，否则说明机器时间被手动调前过，应拒绝启动
如何安全处理时钟回拨
原生库遇到 NTP 校正或手动改时间会 panic 或阻塞，但线上不允许停服。
实操建议：
- 启用
node.SetCheckClockDrift(true)，它会在每次发号前比对系统时间与上次记录时间 - 回拨 ≤ 5ms：自动等待（
time.Sleep）到原时间点再发号 - 回拨 > 5ms：记录告警并返回错误（
snowflake.ErrInvalidSystemTime），由上层决定重试或降级（如用 UUID 补位） - 避免用
time.Now().UnixMilli()手动拼 ID，它绕过所有防护逻辑
生成的 ID 怎么解析出时间/节点/序列
别用字符串切分或第三方解析库——直接调 id.Time()、id.Node()、id.Sequence()，它们是内置方法，零分配。
注意点：
-
id.Time()返回的是相对于 epoch 的时间戳，不是 Unix 时间，要转成可读时间得：time.UnixMilli(epoch + id.Time()) -
id.Node()返回的是初始化时传入的节点 ID，不是机器 IP 或 hostname，别指望它能反查物理位置 - 序列号
id.Sequence()是每毫秒内的自增数，最大 4095，超了会阻塞到下一毫秒——这是雪崩前兆信号，需监控node.Metrics().BlockedRequests
最易被忽略的是：K8s Pod 重启后没清掉旧的 StartTime 缓存，导致新实例误判为时钟回拨。解决办法只有两条路——要么把 node 实例生命周期绑定到 Pod 生命周期（init container 分配 ID + main container 启动时校验），要么用外部协调服务持久化每个节点的最后发号时间戳。
