直接用time.Now().UnixMilli()不行，因其受系统时钟跳变（NTP校正、虚拟机休眠等）影响，无法保证单调递增，易导致ID重复或panic；Snowflake依赖严格递增时间戳，须封装单调时钟抽象并校验时钟回拨。
为什么直接用 time.Now().UnixMilli() 不行
因为并发下毫秒级时间戳会重复，哪怕加锁也扛不住高吞吐场景。snowflake 的核心是把时间、机器 id、序列号拼成一个 64 位整数，既保证单调递增，又避免中心节点瓶颈。
Go 标准库没有内置 Snowflake 实现，得自己封装，但别从零写——容易错在位移、溢出、时钟回拨处理上。
- 时间戳用的是毫秒，不是秒，
UnixMilli()是 Go 1.17+ 才有，老版本得手写time.Now().Unix()*1000 + int64(time.Now().Nanosecond()/1e6) - worker ID 和 datacenter ID 加起来不能超过 10 位（Snowflake 原版限制），常见做法是只用 10 位 worker ID，省掉 datacenter
- 序列号占 12 位，意味着同一毫秒最多生成 4096 个 ID；一旦超限，必须阻塞等待下一毫秒，不能丢弃或跳号
如何安全初始化 Node 并避免时钟回拨
Go 里一般封装成 Node 结构体，包含 mu sync.Mutex、当前毫秒时间、序列号、worker ID 等字段。初始化时最容易踩的坑是：没校验系统时钟是否被手动调慢。
- 首次启动时记录
lastTimestamp，后续每次生成前比对当前时间；若当前时间 lastTimestamp，直接 panic 或返回 error（取决于业务容忍度） - 不建议自动等待回拨恢复——可能卡死；更稳妥的是记录日志并拒绝服务，由运维介入
- worker ID 推荐从环境变量或配置文件读取，不要硬编码；多个实例必须唯一，否则 ID 必然冲突
- 如果用 Kubernetes，可用 Pod 名称哈希后对 1023 取模生成 worker ID，但要注意扩容时哈希分布是否均匀
Generate() 函数里最关键的三步位运算
最终 ID 是 64 位整数：1 位符号位 + 41 位时间戳 + 10 位 worker ID + 12 位序列号。Go 中用 int64 存，符号位其实不用，但保持兼容性就留着。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 时间戳部分：用
(timestamp - epoch) ，因为 10+12=22，右移空出低位 - worker ID 部分：用
(n.workerID & 0x3FF) ，0x3FF是 10 位全 1，防止传入超范围值 - 序列号直接按位或：
timestampID | workerIDPart | n.sequence，注意不是加法 - 务必在加锁后读时间戳、更新序列号、更新
lastTimestamp，三者必须原子
实测中容易被忽略的边界问题
上线后才发现 ID 重复？大概率不是算法错，而是部署或调用姿势不对。
- 多个 Go 进程共用同一个 worker ID（比如用 PID 当 worker ID，但容器里 PID 总是 1）→ ID 冲突
- 没做健康检查，某实例时钟严重回拨却还在提供 ID → 整个下游数据主键冲突
- 高并发压测时，序列号耗尽导致大量线程阻塞在
for timestamp 循环里 → RT 暴涨 - 用
fmt.Printf("%d", id)打日志没问题，但存进 MySQL 的BIGINT UNSIGNED字段时，Go 的int64最高位为 1 会被当负数 → 改用uint64类型或转字符串存储
位运算本身不难，难的是让每个环节都对齐设计假设：时间不回拨、worker ID 全局唯一、单机序列号不越界。漏掉任意一环，ID 就不可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
