ID冲突源于状态管理缺失而非算法错误：Snowflake是有状态协议，NodeID需全局唯一且不可硬编码，时间戳须单调，序列号溢出属正常保护机制，跨服务必须统一epoch和位分配。
直接上结论：ID冲突不是算法选错，而是状态管理没到位——snowflake 本质是个有状态的协议，不是无状态函数，硬套 NextID() 必踩坑。
NodeID 必须全局唯一，且不能靠硬编码
常见错误现象：snowflake.NewNode(1) 在多个 Pod 或容器里反复用，结果生成大量重复 ID。
- K8s 环境下推荐从
POD_IP或HOSTNAME哈希派生，例如int64(hash(mustGetEnv("POD_IP")) & 0x3FF)（保证落在 10-bit 范围内） - 别用进程 PID——容器重启后 PID 重置，但 NodeID 不能变
- 开发/测试/生产环境必须隔离 NodeID 段，比如开发段用 0–63，测试段用 64–127，避免本地联调污染线上 ID 空间
时间戳必须单调，time.Now().UnixMilli() 不能直接用
常见错误现象：容器迁移、NTP 同步、虚拟机休眠后，UnixMilli() 回退，触发 panic 或 ID 重复。
- 必须封装一层
Clock接口，缓存上一次合法时间戳，遇到回拨时返回旧值（保可用）或阻塞等待（保唯一） - Go 1.17+ 才支持
UnixMilli()；老版本得用time.Now().UnixNano() / 1e6，但依然要过单调时钟包装 - 本地调试时用
gomonkey打桩模拟时钟回拨，验证你的处理逻辑是否生效
序列号溢出和时钟未推进是设计行为，不是 bug
常见错误现象：高并发压测时 NextID() 卡住几毫秒，误以为是死锁。
立即学习“go语言免费学习笔记（深入）”；
-
sequence是 uint16（默认 12-bit），每毫秒最多生成 4096 个 ID；超了就等下一毫秒——这是雪崩保护，不是缺陷 - 若 QPS 持续 > 4000，需提前评估：要么调大
StepBits（注意总位宽不能超 22），要么横向扩节点 - 别在单个 Node 上扛全部流量；微服务应按业务域分组分配不同 NodeID，而非共用一个
跨服务 ID 格式不统一，比冲突更危险
常见错误现象：订单服务用默认 epoch，用户服务用自定义 epoch，两个 ID 看似不重复，但排序错乱、范围查询失效。
- 所有服务必须共用同一
epoch时间点（如2020-01-01T00:00:00Z），写死在 config 或常量里 - 避免混用不同 Snowflake 实现：
bwmarrin/snowflake和go.uber.org/zap内部变种的位分配可能不同 - ID 存储类型必须一致——
BIGINT SIGNED或string，别用uint64变量在 Go 里传，MySQLBIGINT UNSIGNED易截断
真正难的不是生成 ID，而是让每个服务实例在任意时刻、任意网络条件下，都维持住自己那一小块 ID 空间的“主权”——NodeID 不重、时间不跳、序列不爆、格式不偏。漏掉任何一环，冲突就会在凌晨三点悄悄发生。
