直接用 bwmarrin/snowflake 会导致订单重复，因其 workerID 硬编码、依赖本地时钟且无时钟回拨容错；应通过 etcd 抢占注册动态分配 workerID，并配置降级策略与混沌验证。
为什么直接用 bwmarrin/snowflake 会出订单重复？
因为它默认把 workerID 写死在代码里，启动时直接用本地时间戳生成 ID。三个 Pod 如果都用 node := snowflake.NewNode(1)，那它们的机器位完全一样——同一毫秒、同一序列号，必然产出相同 ID。
更麻烦的是，它不处理时钟回拨：Node.GetID() 遇到时间倒退 >5ms 就 panic，而云主机 NTP 校准、容器 suspend/resume 都可能触发这个条件。
- 硬编码
workerID→ 多实例部署即冲突 - 依赖本地时钟 → 容器/VM 环境下极易因漂移失败
- 无重试或降级 → 启动卡死或运行中 panic
如何安全获取动态 workerID？
不能靠人工配 YAML 或写死环境变量——滚动发布时旧 Pod 还没退出，新 Pod 就可能拿到同一个 ID；也不能用 IP 哈希，K8s 下 PodIP 频繁变化，哈希结果不稳定。
推荐用 etcd 实现抢占式注册：每个服务启动时尝试申请一个带 TTL 的 key，成功则获得唯一 workerID，失败则轮询重试或降级。
- etcd key 路径建议：
/snowflake/worker_ids/{uuid}，value 存节点标识（如 hostname） - TTL 设为 30 秒，避免节点宕机后 ID 长期被占
- 永远不要在
init()里调用 —— 网络不可达时会阻塞整个进程 - 降级策略必须有：比如用
hash(hostname) % 1024，仅限单机或开发环境
sonyflake 比 bwmarrin/snowflake 强在哪？
它把时钟回拨容忍从 5ms 提升到可配置阈值（默认 10s），且默认返回负 ID 而非 panic，让你有机会做业务层兜底。但要注意：负 ID 不是 bug，是明确告诉你“时间出问题了”，得立刻告警而非忽略。
- 初始化必须用
sonyflake.NewRealClock()，别用NewSystemClock()—— 容器里虚拟化时钟不准 -
NextID()返回负数？立刻记录日志并触发熔断，不要继续发订单 - workerID 范围仍建议控制在 0–1023，留足 41 位时间戳和 12 位序列号空间
订单 ID 冲突真正发生的那一刻，你在哪？
不在代码里，而在运维链路上：etcd 不可用时降级逻辑是否真跑通？时钟跳变后告警是否 5 秒内触达值班人？workerID 被复用是因为 TTL 设置过长，还是清理脚本漏写了？
这些点没法靠单测覆盖，只能靠混沌工程验证：手动停 etcd、date -s "10 seconds ago"、kill -9 模拟节点闪退——看 ID 是否连续、是否重复、服务是否降级存活。
