雪花ID解码器

雪花算法（Snowflake）把一个 64 位整数拆成五段：1 位符号位（恒为 0）、41 位毫秒时间戳增量、5 位数据中心号、5 位机器号、12 位序列号（Twitter 原始布局）。ID 本身不透明，但只要知道系统的纪元与各段位宽，就能像本工具一样用位移和掩码把生成时刻与机器身份完整还原——排查分布式重复主键、定位问题数据来自哪台节点时尤其有用。

如何使用

1. 如果你的系统改过默认纪元，先在参数区选择框架预设或直接填写毫秒 / 日期形式的纪元；
2. 调整各位段宽度（默认 41 + 5 + 5 + 12），使其与业务代码中的位移常量一致；
3. 每行粘贴一个 ID，表格即逐行给出时间戳、本地时刻、ISO 时间、数据中心、机器号与序列号；
4. 点击某一行可查看该 ID 的位布局视图；异常输入（负数、超长、位数不足）会红色或橙色标注。

位布局与还原公式

• 时间戳增量 = ID 右移（数据中心 + 机器 + 序列 位数之和），生成时刻 = 纪元 + 增量；41 位可表示约 69.7 年。
• 机器段 = 先把低位序列号掩掉再右移；序列号 = ID 与 (2^12 − 1) 按位与，同毫秒内可发 4096 个号。
• 解码使用 BigInt 运算，19 位以上的 ID 也不会因 JS Number 精度丢失而失真；但请确认 ID 在传给前端前未经 JSON number 序列化，否则可能已被四舍五入（本工具会给出超 2^53 提示）。

常见问题

• 为什么雪花 ID 会重复？最常见原因是时钟回拨：机器时间被 NTP 往回调后，同一毫秒段会重新发放相同（机器, 序列）组合；其次是多实例部署时机器号配置撞车（如 K8s 克隆同一份配置、容器未注入独立 workerId）；再次是序列号溢出后若实现未等待下一毫秒而是直接复用旧时间戳，也会撞号。
• 解出来的时间和实际生成时间对不上？先确认纪元是否为目标系统定制值（很多框架改成自己的上线日），再确认位分配是否与代码一致（有的项目把机器号扩到 10 位、序列缩到 10 位）；两者任一不符，时间戳段都会整体错位。
• 红色提示「超过 2^53」是什么意思？该 ID 超出了 JavaScript Number 的安全整数范围。若后端用 JSON number 下发，浏览器解析时已可能失真；本解码器用 BigInt 计算不受影响，但请核对传入前是否已被序列化环节四舍五入。