不能直接用time.Now().UnixNano()生成分布式ID时间戳，因其在多机、高并发下同一纳秒内请求会撞ID，且缺乏全局单调递增保证和时钟回拨容错能力；UUID不适合作为分布式ID，因v4无序导致索引写入放大，v1依赖MAC易重复、精度低、不支持自定义epoch与worker ID；bwmarrin/snowflake需从etcd等配置中心安全获取全局唯一nodeID并校验范围，禁用hostname/IP推导或硬编码。
为什么不能直接用 time.Now().UnixNano() 生成分布式ID
时间戳本身不唯一，尤其在多机、高并发下，同一纳秒内多个请求会撞 ID；即使加随机数或机器 ID，也缺乏全局单调递增保证，且无法避免时钟回拨风险。真正可用的分布式 ID 必须同时满足：唯一性、趋势递增、高吞吐、无中心依赖。
github.com/google/uuid 适合做分布式 ID 吗
不适合。UUID（尤其是 v4）是随机字符串，不具备顺序性，会导致数据库索引写入放大；v1 虽含时间戳和 MAC 地址，但 MAC 可能重复（容器/云环境）、时间精度仅到 100ns、且不支持自定义 epoch 和 worker ID 分配。它本质是标识符，不是 ID 生成器。
用 github.com/bwmarrin/snowflake 时怎么安全分配 nodeID
这个库默认用本地文件持久化 nodeID，但在 Kubernetes 环境下 Pod 重建后文件丢失，可能复用旧 nodeID 导致 ID 冲突。正确做法是：启动时从配置中心（如 etcd 或 Consul）获取唯一 nodeID，失败则 panic —— 宁可服务起不来，也不能冒 ID 冲突风险。另外注意：nodeID 必须在集群内全局唯一，且位宽要与 snowflake 位布局匹配（例如 10 位 nodeID 最多支持 1024 个节点）。
- 不要用 hostname 或 IP 自动推导
nodeID：K8s 中 hostname 不稳定，IP 可能复用 - 避免硬编码
nodeID：不同实例必须隔离配置，不能靠部署脚本拼接 - 检查
nodeID是否越界：传入前用if nodeID >= (1 校验（假设预留 10 位）
自研 snowflake 时哪些参数改动会破坏兼容性
一旦 ID 格式上线，timestampBits、nodeBits、stepBits 三者之和必须恒为 64，且各段偏移量固定。比如把 stepBits 从 12 改成 10，虽然总位数仍够，但旧服务解析新 ID 时会把高位 step 误读为 node，导致 ID 解析错误。更隐蔽的问题是 epoch 时间：如果用 time.Date(2020, 1, 1, 0, 0, 0, 0, time.UTC).UnixMilli() 当 epoch，而另一服务用秒级 epoch，毫秒级时间戳左移后高位就错位了。
立即学习“go语言免费学习笔记（深入）”；
- 所有节点必须使用完全相同的 bit 分配方案和 epoch 值
- 修改任何位宽前，需全量更新所有依赖方并灰度验证 ID 解析逻辑
- 建议用常量定义位宽：
const ( TimestampBits = 41; NodeBits = 10; StepBits = 12 )，避免 magic number
分布式 ID 的坑不在生成逻辑本身，而在节点标识的生命周期管理和位布局的跨服务一致性——这两点漏掉一个，线上就可能出重复 ID，而且很难回溯。
