Snowflake生成ID不是调函数就完事，必须正确配置nodeID、处理时钟回拨、保障并发安全，否则上线必重复或panic；K8s中NewNode(1)会导致ID重复，因硬编码1使多Pod共享同一nodeID，应从HOSTNAME等环境变量哈希取模或用StatefulSet序号。
snowflake 生成 ID 不是调个函数就完事，**不配 nodeID、不处理时钟回拨、不封装并发安全，上线必重复或 panic**。Go 生态里没“开箱即用”的分布式 ID，只有“配对了才敢上生产”的配置项。
为什么 snowflake.NewNode(1) 在 K8s 里一跑就重复
因为 1 是硬编码，不是唯一标识——K8s Pod 重启后可能起多个副本，全用 NewNode(1)，等于所有节点共享同一台“虚拟机器”，时间戳+nodeID+sequence 完全重叠。
- 正确做法：从环境变量读取唯一值，比如
HOSTNAME或POD_IP，再哈希取模：hash(hostname) % 1024 - 别用
os.Getpid()：容器里 PID 常为 1，且重启后不变，毫无区分度 - StatefulSet 场景可直接用序号：
atoi(strings.TrimPrefix(os.Getenv("HOSTNAME"), "myapp-")) - 如果用
sony/sonyflake，必须显式传MachineID函数，不能依赖默认逻辑（它会读/dev/urandom，首次启动慢且不稳定）
time.Now().UnixMilli() 为什么不能直接当时间戳用
它返回的是系统墙钟（wall clock），而 snowflake 要求单调递增的逻辑时间戳。NTP 校时、VM 休眠、容器迁移都可能导致 UnixMilli() 突然倒退几毫秒，触发 snowflake.ErrInvalidSystemTime 或直接 panic。
- 生产环境必须包装一层单调时钟抽象，例如缓存上一次值，遇到回拨时返回旧值（牺牲严格单调性保可用）
- 初始化时加校验：
if time.Now().UnixMilli() - 测试时用
gomonkey打桩模拟回拨，别靠time.Sleep—— Go 调度不可控，实际休眠可能远超预期 - K8s 中建议 initContainer 同步宿主机时钟：
ntpd -q -p pool.ntp.org，再启动主服务
并发调用 node.Generate() 为什么会 panic 或性能骤降
bwmarrin/snowflake.Node 内部用 sync.Mutex 保护状态，但锁粒度在方法级；高频调用下，goroutine 会排队阻塞，压测时 QPS 断崖下跌。更糟的是，有人把它当普通 struct 每次 new 一个，导致 GC 压力飙升。
- 必须复用同一个
*snowflake.Node实例，全局单例或注入到 handler 依赖中 - 不要在 HTTP handler 里
defer node.Generate()—— 高频日志或埋点会拖垮吞吐 - 若坚持用
bwmarrin/snowflake，建议包进sync.Pool或用指针 + 外层sync.RWMutex封装 - 更省心选
sony/sonyflake：它默认线程安全，NextID()内部已做原子操作，且 machineID 自发现逻辑更适合容器场景
生成的 ID 存 MySQL 用 BIGINT UNSIGNED 还是 CHAR(19)
别只看“能存下”，要看索引效率、ORM 映射、JSON 序列化三重影响。Go 的 snowflake.ID 是 int64，但标准雪花 ID 最高位是 0，本质是 uint64。
立即学习“go语言免费学习笔记（深入）”；
- MySQL 字段必须是
BIGINT UNSIGNED：用SIGNED会溢出（如 ID > 2^63-1 时变负数），查不到也插不进 - Go 侧接收推荐用
uint64类型，避免隐式转换丢失精度 - JSON 输出务必转字符串：
id.String()，否则前端 JS 解析会因Number.MAX_SAFE_INTEGER（2^53−1）截断 - 如果字段要建联合索引（如
(id, created_at)），BIGINT比CHAR索引体积小、比较快；但若下游有强字符串处理逻辑（如 URL 短链），可双写：主键用BIGINT UNSIGNED，冗余字段存CHAR(19)
panic: clock moved backwards。 
