线程安全的 snowflake id 生成器需为每个 workerid 独立维护 sequence 和 lasttimestamp，用 sync/atomic 或 sync.mutex 保护；必须校验时间单调递增，防止时钟回拨导致 id 重复或错误。
Go 里怎么写一个线程安全的 Snowflake ID 生成器
直接用 sync.Mutex 或 sync/atomic 控制时间戳和序列号递增即可，但要注意：单机多实例（比如多个 WorkerID）不能共用同一个计数器。最稳妥的方式是每个 Node 实例持有自己的 sequence 和上一次时间戳。
常见错误是把 sequence 设成全局变量，结果多个 goroutine 并发调用时漏发、重复或跳号；还有人用 time.Now().UnixMilli() 直接算，没做单调递增校验，一遇到系统时间回拨就崩。
- 必须缓存上一次生成的时间戳，每次生成前比对：若新时间
-
sequence溢出（比如达到 4095）后，必须等下一毫秒再重置为 0，不能直接清零 - 推荐用
sync/atomic操作sequence和lastTimestamp，比锁轻量；但要注意读写顺序，建议封装进结构体方法里
type Node struct {
mu sync.Mutex
machineID int64
sequence int64
lastTimestamp int64
}
// 注意：实际中更推荐 atomic.StoreInt64 + atomic.LoadInt64 配合 CompareAndSwap
WorkerID 怎么分配才不冲突
微服务部署时，不同实例必须有唯一 machineID（也叫 workerID），否则 ID 会重复。它不是随便设个数字就行——得在服务启动时动态获取，且在整个生命周期内不变。
常见错误是硬编码 machineID := 1，本地跑没问题，一上 K8s 就炸；或者从环境变量读但没校验范围（machineID 超出 10 位导致位移错乱）。
立即学习“go语言免费学习笔记（深入）”；
- K8s 场景下，可用 Pod 名称哈希后对
1 取模，再加 1（避免为 0） - 如果用 Consul/Etcd 做注册中心，可抢锁写入临时 key，成功者获得自增 ID
-
machineID必须在 [0, 1023] 范围内，超出会导致位截断，ID 不唯一
时间回拨问题怎么扛住
Snowflake 对系统时钟极度敏感。只要 NTP 同步或运维操作导致时间倒退超过 1ms，原生实现就会卡死或 panic。
线上真实场景里，云主机休眠唤醒、容器迁移、K8s 节点时间漂移都可能触发回拨。不能指望“别让系统回拨”，得在代码里兜底。
- 检测到回拨时，优先等待（比如最多 5ms），等时钟追上来；超时则抛错或 fallback 到 UUID
- 不要用
time.Sleep硬等，要用循环轮询time.Now().UnixMilli()，避免 goroutine 长时间挂起 - 某些团队会记录上次持久化时间戳到 Redis，重启时读取并取 max，但这引入了外部依赖，慎用
生成的 ID 为什么高位总是 0x00000000
Go 的 int64 是有符号类型，而 Snowflake 标准 ID 是 64 位无符号整数。直接用 int64 存储、打印或传给前端 JSON，高位会被解释为符号位，显示成负数或高位补 0 —— 实际二进制是对的，只是展示/序列化方式误导了你。
典型现象：日志里打印 fmt.Println(id) 出来是负数；MySQL 插入时报错 “out of range”；前端 JS 接收后变成 9007199254740991 这样的精度丢失值。
- 输出时统一用
fmt.Printf("%d", uint64(id))或转字符串再传 - JSON 序列化前，定义字段为
uint64类型，或用自定义MarshalJSON方法 - 存 MySQL 用
BIGINT UNSIGNED，不是BIGINT；ORM 如 GORM 要显式指定sql:"type:bigint unsigned"
位布局本身没问题，问题永远出在“怎么看”和“怎么传”。这点特别容易被忽略，查半天以为算法错了，其实是类型没对齐。
