常见方案对比：UUID——无中心、生成快，但 128 位太长且无序，做数据库主键导致 B+ 树页分裂、插入性能差；数据库自增——单点瓶颈与单点故障，可用多实例步长错开（Flickr 方案）缓解；号段模式——一次批量取 1000 个 ID 到本地缓存分配（Leaf-segment），数据库压力降为 1/1000；Redis INCR——快但引入额外依赖；Snowflake——64 位长整型：1 位符号 + 41 位毫秒时间戳（约 69 年）+ 10 位机器位（1024 节点）+ 12 位序列号（每毫秒每节点 4096 个），本地生成、无网络开销、整体趋势递增。
Snowflake 的考点在边界问题：1）时钟回拨——机器时钟被 NTP 校准回拨会产生重复 ID，处理策略有等待时钟追上、回拨期间用扩展位标记、或直接拒绝服务报警（Leaf/美团与百度 UidGenerator 各有取舍）；2）机器位分配——固定配置不灵活，生产上从 ZK/DB 动态分配 workerId，容器环境要注意实例重启后的回收与复用；3）趋势递增而非严格递增——同一毫秒内的并发靠序列号，跨毫秒靠时间戳，满足索引友好但不保证全序。追问方向：为什么趋势递增的 ID 对 InnoDB 主键插入友好（最右页追加）、业务 ID 是否需要隐藏信息量（订单号暴露日订单量问题）。
（约 460 字）