为什么直接用 github.com/bwmarrin/snowflake 会出错？
因为默认生成的 Node 是单机绑定的，没做分布式协调，多实例部署时极易撞 ID。它只适合单进程场景，不是开箱即用的“分布式”方案。
常见错误现象：duplicate key violation（数据库报唯一键冲突）、ID 时间戳倒流、序列号重复归零。
- 必须手动分配唯一
nodeID，不能靠随机或 PID —— 容器重启后 PID 变，nodeID就可能复用 - 推荐从外部配置注入，比如启动时读取环境变量
SNOWFLAKE_NODE_ID=5，而非硬编码或自增 - 如果用 Kubernetes，建议结合
StatefulSet+ordinal index做稳定映射，避免依赖 ConfigMap 热更新（更新不及时会导致临时冲突）
自己实现 Snowflake 时，时间戳和序列号怎么防溢出？
标准 Snowflake 是 64 位：1 位符号 + 41 位毫秒时间戳 + 10 位 nodeID + 12 位序列号。Go 的 int64 能存下，但逻辑上容易越界。
关键陷阱：用 time.Now().UnixMilli() 没问题，但若机器时钟回拨，lastTimestamp 就会比当前小，导致循环等待甚至卡死。
立即学习“go语言免费学习笔记（深入）”；
- 序列号到
4095（0xfff）后必须等下一毫秒，不能清零重来 —— 否则同一毫秒内多个请求会生成相同 ID - 检测时钟回拨要用「严格模式」：发现
currentTs 就 panic 或返回 error，别 sleep 等回拨恢复（生产环境不可靠） - 41 位时间戳撑到 2039 年，但如果业务需要更长生命周期，得压缩 nodeID 或序列号位数 —— 这会直接降低并发吞吐量
在微服务里怎么安全共享 nodeID？
靠人工分配易出错，靠数据库主键又引入强依赖。真正落地时，优先级应该是：配置中心 > 注册中心 > 数据库。
使用场景：一个服务有 3 个 Pod，每个需固定且互斥的 nodeID；滚动发布时新旧 Pod 可能短暂共存。
- Consul / ETCD 可用
atomic counter或lease + key locking实现首次注册抢占，但要注意 lease 过期后自动释放带来的 ID 复用风险 - 更稳的做法是把
nodeID写进服务启动参数，由运维平台统一分配并记录（比如用 GitOps 管理 YAML 中的env.SNOWFLAKE_NODE_ID） - 绝对不要用 IP 哈希（
hash(ip) % 1024）—— 容器网络下 IP 经常变，哈希结果不稳定
要不要用 Redis + Lua 做 ID 生成？
可以，但不是替代 Snowflake，而是补位：当 Snowflake 不适用时（比如 nodeID 分配失控、跨语言调用、无状态函数计算场景）。
性能影响明显：单 Redis 实例 QPS 上限约 10w，而纯内存 Snowflake 在 Go 里轻松跑 50w+ QPS；网络延迟也会让 P99 明显抬高。
- Redis 方案适合低频、强一致性要求的 ID（如支付单号），不适合高频日志 traceID
- 用 Lua 脚本保证原子性没问题，但别在脚本里做复杂逻辑（比如拼接前缀、校验格式），会拖慢 Redis
- 如果已用 Redis，可考虑
INCR+ 时间戳拼接，但注意INCR是全局锁，高并发下会成瓶颈
真正麻烦的是混合部署：一部分服务用 Snowflake，一部分用 Redis，ID 长度、时间精度、可排序性都不一致，下游系统解析成本陡增。选一种，坚持到底。
