直接用 github.com/bwmarrin/snowflake 最省心，因它由 Discord 维护、稳定多年，支持节点动态分配、时间回拨降级、序列溢出保护，并封装位运算逻辑；需注意并发调用、唯一 nodeID 及时间回拨处理。
为什么直接用 github.com/bwmarrin/snowflake 最省心
绝大多数 Go 项目不需要自己造轮子。这个库由 Discord 团队维护，已稳定运行多年，支持节点 ID 动态分配、时间回拨自动降级、序列号溢出保护，并内置 Node 对象封装了全部位运算逻辑。它默认使用 10 位节点 ID（最多 1024 个节点）和 12 位序列号（每毫秒最多 4096 个 ID），符合标准雪花结构。
常见踩坑点：不显式调用 node.Generate() 而直接用 node.Generate().Int64() 可能因并发调用导致序列号错乱；必须确保每个节点初始化时传入唯一 nodeID，否则 ID 冲突；时间回拨超过 5 秒会 panic，需提前注册 node.SetTimeFunc 或捕获 snowflake.ErrInvalidSystemTime 错误。
手写位运算实现：可控但易出错
手动拼接时间戳、机器 ID、序列号时，核心是按位左移 + 按位或：timestamp。问题在于位宽定义容易错——比如把机器 ID 当成 10 位却用了 16 位变量，或未对 sequence 做 & 0xfff 截断导致高位污染。
关键细节：
- 时间戳必须用自定义纪元（如 2020-01-01），不能直接用
time.Now().UnixMilli()，否则低 41 位不够存 - 每次生成前要检查当前毫秒是否等于上一次，相等才递增
sequence，否则重置为 0 - 必须加
sync.Mutex或atomic控制并发，裸写int64在多 goroutine 下会丢序列号 - 没有内建时间回拨检测，一旦系统时间向后跳再向前跳，
sequence不重置就直接重复 ID
用 google/uuid + 时间戳模拟：不是真雪花，慎用于分布式主键
有人用 uuid.New().ID() 截取前 8 字节转 int64，或拼接 time.Now().UnixMilli() 和随机数——这类方案看起来“带时间信息”，但完全不具备雪花算法的有序性、可预测长度、无锁高性能等特性。
典型问题：
- ID 无单调递增性，数据库 B+ 树索引插入性能暴跌
- 无法从 ID 反解出生成时间或节点信息，排查问题时失去关键线索
- 随机部分碰撞概率随量级上升，百万级后冲突率不可忽略
- 和真正雪花 ID 混用会导致分库分表路由错乱（比如按 ID 取模）
节点 ID 分配和时钟同步才是真正的难点
所有实现方式都绕不开这两个现实问题：节点 ID 怎么在容器或 K8s 环境里自动、唯一分配；系统时钟是否可能被 NTP 调整或虚拟机休眠导致回拨。前者建议用 etcd/ZooKeeper 注册临时节点获取序号，后者必须搭配 clock_gettime(CLOCK_MONOTONIC) 类接口（Go 中可用 runtime.LockOSThread() + syscall.Syscall 调用，或直接依赖 github.com/sony/sonyflake 的单调时钟封装）。纯靠配置文件写死 nodeID 在云环境几乎不可维。
