github.com/bwmarrin/snowflake 默认不能直接上生产，因其不校验nodeID合法性、不处理时钟回拨、不保证跨Pod唯一性，硬套会导致ID重复或panic；K8s中NewNode(1)必然出问题，因多副本共用静态nodeID=1，节点段相同，时间戳与序列号一旦碰撞即重复。
github.com/bwmarrin/snowflake 默认不能直接上生产，它不校验 nodeID 合法性、不处理时钟回拨、不保证跨 Pod 唯一性，硬套会导致 ID 重复或 panic。
为什么 NewNode(1) 在 K8s 里必然出问题
默认 nodeID=1 是静态值，K8s 多副本启动时所有 Pod 都用这个值，雪花 ID 的 10-bit 节点段完全一样，只要时间戳和序列号撞上，ID 就重复。
- 别从
os.Getpid()算nodeID——容器重启 PID 重置，可能和别的 Pod 冲突 - 推荐用
HOSTNAME或POD_IP做哈希：int64(hash(hostname) & 0x3FF)（确保落在 0–1023） - 必须从环境变量或 Downward API 注入，不能写死在代码里
- 初始化前加校验：如果
nodeID 1023，直接panic或返回 error
time.Now().UnixMilli() 必须包装成单调时钟
系统时钟会被 NTP 调整、VM 休眠、容器迁移导致跳变或回退，而雪花算法要求时间戳严格单调递增。裸用 time.Now().UnixMilli() 在生产环境等于埋雷。
- 定义接口：
type Clock interface { Now() int64 }，实现里缓存上次值，遇到回退就返回缓存值（保可用，牺牲极小唯一性） - 测试时用
gomonkey打桩模拟Now()返回更小值，验证是否 fallback 成功 - K8s 场景下，建议 initContainer 调用
ntpd -q -p pool.ntp.org同步时钟后再启主服务 - 别依赖
time.Sleep(1 * time.Millisecond)来“防重复”——这只是掩盖时钟不稳，不是根治
并发安全的 Node 封装不能省
github.com/bwmarrin/snowflake.Node 内部虽有 sync.Mutex，但老版本存在竞态漏保护；更关键的是，把它当普通 struct 传参或全局变量用，会在 goroutine 里触发未定义行为。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：用
sync.Pool池化*snowflake.Node，或封装成带锁的单例服务 - 千万别在 HTTP handler 里每次
&snowflake.Node{...}—— 初始化开销小，但高频 new 会抬高 GC 压力，压测时 QPS 明显下滑 - 更省心的选择是换
github.com/sony/sonyflake，它默认线程安全，且内置基于 MAC + PID 的 machineID 自发现逻辑 - 如果必须用 bwmarrin 版本，确保所有调用都走同一个指针实例，且全程加锁
MySQL 存 ID 别只看类型，要看 ORM 和索引行为
Go 生成的 ID 是 int64，但 MySQL 的 BIGINT UNSIGNED 和 BIGINT SIGNED 对应行为不同，ORM 映射和 JSON 序列化也容易翻车。
- 选
BIGINT SIGNED更稳妥：雪花 ID 最高位固定为 0，不会溢出，且主流 ORM（如 GORM）默认映射int64到 signed 类型 - 避免用
CHAR(19)：虽然可读，但索引效率低、JOIN 开销大、JSON 输出多一层 string 包裹 - 如果下游有 JS 前端，注意
Number.MAX_SAFE_INTEGER是 2⁵³−1，18 位以上 ID 会丢失精度——这时必须传字符串，字段也得配成TEXT或VARCHAR - 改
epoch会影响 ID 长度：原始 Twitter epoch（1288834974657）生成的 ID 稳定在 18 位；设成 2025 年会缩到 17 位，下游做substr(id, 0, 18)的逻辑就崩了
实际最难缠的不是代码怎么写，而是 nodeID 分配和时钟治理——这两项没法靠库自动解决，必须进 CI/CD 流水线校验、进 K8s Helm Chart 配置、进 SRE 监控大盘盯住 lastTimestamp 跳变。
