为什么直接用 github.com/bwmarrin/snowflake 会出错？
因为它的 Node 实例不是线程安全的，且默认使用系统时间做基准，本地时钟回拨会导致 ID 重复或阻塞。很多新手一上来就 node.Generate()，结果在并发场景下拿到重复 ID 或 panic。
- 必须为每个 goroutine 独立创建
Node，或加锁共享（不推荐） -
time.Now().UnixMilli()在容器或虚拟机里可能跳变，要配合sync/atomic做单调递增兜底 - 默认 epoch 是 2019-01-01，和你业务时间线不一致时，生成的 ID 位数偏小（比如只有 41 位时间戳，实际只够用 69 年）
自己实现最简 snowflake 的三个关键字段怎么算？
核心是把一个 int64 拆成三段：时间差 + 机器 ID + 序列号。别硬背位数，记住「谁变谁占位」就行——时间变化最慢，放高位；序列号每毫秒重置，放最低位。
- 时间戳部分：用
time.Since(epoch).Milliseconds()，确保是单调非负整数 - 机器 ID：别用 IP 自动识别，容易冲突；建议从启动参数或环境变量读取
SNOWFLAKE_NODE_ID - 序列号：用
sync/atomic.AddUint32(&seq, 1) & 0xfff，超了就等下一毫秒（注意这里不是自增后取模，而是先加再掩码）
示例片段：
id := (ms << 22) | (nodeID << 12) | (seq & 0xfff)
Go 标准库里没有原子级 sleep，怎么处理时钟回拨？
标准 time.Sleep 不能中断重试，而 snowflake 要求「宁可等，不可错」。一旦发现当前时间小于上次生成时间，就得卡住直到追平。
立即学习“go语言免费学习笔记（深入）”；
- 不要用
for time.Now().UnixMilli() —— 这是空转耗 CPU - 正确做法：记录
lastTimestamp，检测到回拨后计算差值sleepDur := time.UnixMilli(lastTimestamp).Add(1 * time.Millisecond).Sub(time.Now())，再time.Sleep(sleepDur) - 如果回拨超过 5 秒，直接 panic 或返回 error，避免无限等待（生产环境必须设上限）
生成的 ID 为什么存进 MySQL 后变 0？
因为 Go 的 int64 默认被当成有符号数，而 MySQL 的 BIGINT UNSIGNED 和 Go 的 uint64 类型不自动对齐。用 database/sql 插入时，如果扫描目标是 int64，高位置 1 的 ID（比如大于 9223372036854775807）会被截断成负数，再转无符号就成 0。
- 数据库字段必须定义为
BIGINT UNSIGNED - Go 侧统一用
uint64接收和传参，别混用int64 - 用
sql.NullInt64会掉坑——它底层还是int64，照样溢出
验证方式：fmt.Printf("%b\n", id) 看最高位是不是 1。
分布式 ID 看似简单，真正卡住人的永远是时钟、类型、并发这三点交叉作用的地方。尤其是跨服务部署时，node ID 配置、时钟同步策略、数据库字段定义，少对一环，ID 就开始“悄悄错”。
