直接使用 github.com/bwmarrin/snowflake 可能出错，因其默认用不稳定 PID 作节点 ID 且不校验时钟回拨，导致 panic 或重复 ID；生产环境须显式设置 Node、替换 time.Now、避免实例共享，并妥善处理 sequence 溢出与时间戳拼接兼容性问题。
为什么直接用 github.com/bwmarrin/snowflake 可能出错
它默认用本地机器时间 + 进程 PID 生成节点 ID，但容器或 Kubernetes 环境下 PID 不稳定，os.Getpid() 可能重复；更关键的是，它不校验系统时钟回拨——一旦 NTP 调整导致时间倒退，NextInt64() 会 panic 报 "time went backwards"。
- 生产环境必须显式设置
Node，别依赖默认值，比如用 Pod IP 的哈希或配置中心下发的固定 ID - 务必调用
node.SetTimeFunc()替换掉原生 time.Now，接入一个带单调性保护的时钟（例如用github.com/sony/sonyflake的StartTime+ 自增 fallback） - 不要在多个 goroutine 里共用同一个
*snowflake.Node实例——它内部有非原子写操作，高并发下可能产生重复 ID
自己实现 snowflake 时，sequence 字段怎么防溢出
12 位 sequence 最大值是 4095，意味着同一毫秒内最多生成 4096 个 ID。如果业务峰值超过这个数，下一毫秒还没到，sequence 就会绕回 0——但若此时时间没推进，就会和上一轮重复。
- 检测
currentMs 后，不能只 sleep 等待，要主动阻塞直到 <code>currentMs > lastTimestamp，否则在低负载下也可能因调度延迟触发绕回 - 推荐把
sequence改成 uint64 并加 CAS 更新，配合sync/atomic，避免锁竞争影响吞吐 - 更稳妥的做法是预留几位作为“分片 ID”，把单节点压力分散到多个逻辑节点（比如用 goroutine ID 或 worker ID），而非硬扛更高
sequence容量
Go 中 time.UnixMilli() 和手动位移拼接 ID 的兼容性坑
Go 1.17+ 才支持 time.UnixMilli()，老版本得用 t.Unix()*1000 + t.Nanosecond()/1e6；但要注意：如果用 time.Now().UnixNano() 直接除 1e6，会因浮点截断导致时间戳少 1ms。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 一律用整数运算：
(t.Unix() * 1e3) + (t.Nanosecond() / 1e6) - 拼接 ID 时，务必确认各字段位宽总和是 64 位：比如 41 位时间戳 + 10 位节点 ID + 12 位 sequence = 63 位，剩 1 位留作符号位（所以最终要转
uint64再返回） - 别用
fmt.Sprintf("%d", id)做字符串化——高频场景下分配太多小对象，改用strconv.AppendUint(nil, id, 10)
如何验证生成的 ID 真的「全局有序」且「不重复」
有序 ≠ 时间戳递增，而是指：对任意两个 ID A 和 B，若 A 在 B 之前生成，则 A 恒成立。这要求时间戳、节点 ID、sequence 三者组合后严格保持字典序。
立即学习“go语言免费学习笔记（深入）”；
- 写个简单测试：启动 2 个
Node，各自连续生成 1000 个 ID，合并后检查是否严格升序：sort.Slice(ids, func(i, j int) bool { return ids[i] ，再遍历比对 - 注意验证边界：在同一毫秒内跨节点生成 ID，应满足
node1_seq4095 （因为 node2 的节点 ID 更大） - 真正难测的是时钟回拨——建议在测试里 mock
time.Now，强制让时间倒退 1ms，看是否 panic 或静默生成重复 ID
最麻烦的不是算法本身，而是时钟精度、节点标识稳定性、以及不同 Go 版本对纳秒级时间处理的细微差异。上线前一定要在目标部署环境（比如某款 ARM 服务器或旧版 Alpine 镜像）实测。
