雪花 ID

两种都支持。工具页面提供选项切换「Twitter 风格」和「Sonyflake 风格」。Twitter 风格（Snowflake）使用 41 位时间戳 + 10 位机器 ID + 12 位序列号，适合高并发分布式场景；Sonyflake 使用 39 位时间戳 + 8 位机器 ID + 16 位序列号，序列空间更大但时间跨度更短（约 174 年 vs 69 年）。选择时主要看你的部署规模和期望的时间可用年限。

雪花 ID 是 64 位整数，通常表现为 18-19 位十进制数，但它的前几位是时间戳的偏移量编码，不是直接的时间数字。你可以把数字粘贴到本工具的「解析」输入框，工具会自动按 Snowflake/Sonyflake 两种格式尝试解码，并显示提取出的时间戳、机器 ID 和序列号。如果解码出的时间戳落在 2010 年之后且序列号规律递增，基本可以确认是雪花 ID。普通 Unix 时间戳（10 位秒级或 13 位毫秒级）位数不同，解码结果不会出现机器 ID 字段。

大概率是机器 ID 或起始时间（epoch）不同。雪花 ID 的生成依赖三个参数：自定义 epoch（起始时间戳）、机器 ID（worker ID）和序列号。不同系统可能设置不同的 epoch（Twitter 默认 2010-11-04，Sonyflake 默认 2014-09-01），或者分配了不同的机器 ID，导致同一时刻生成的 ID 完全不同。本工具在解析时允许你手动输入 epoch 和机器 ID 来匹配目标系统的配置；生成时也提供这些参数的自定义，确保和你的生产环境一致。

雪花 ID 内部的时间戳是 UTC 毫秒数（从 epoch 开始的偏移量），工具默认显示的是 UTC 时间。如果你看到的时间比你的本地时间晚了 8 小时，说明你的时区是东八区（UTC+8），工具显示的是 UTC 零时区时间。页面结果区同时标注了「UTC 时间」和「本地时间」两行，直接看本地时间行即可，不需要手动换算。如果你需要批量验证数据库里的 ID，建议统一用 UTC 行对比，避免时区转换错误。

同一毫秒内序列号溢出时，生成策略有区别。Snowflake 风格中，当 12 位序列号（0-4095）在同一毫秒内用完，生成器会等待下一毫秒再生成，所以不会重复。Sonyflake 风格序列号 16 位（0-65535），空间更大，但时间戳粒度是 10 毫秒，等待策略类似。本工具生成时完全模拟这两种行为，如果勾选了「强制等待」，会模拟生产环境中的阻塞等待；不勾选则序列号溢出时报错，方便测试边界情况。实际部署时，只要机器 ID 不冲突，ID 全局唯一。

完全在浏览器本地完成，不上传任何数据。工具实现方式标注为 FE（前端），所有雪花 ID 的生成和解析逻辑都用 JavaScript 在浏览器端执行，不经过任何后端服务器。你可以断网测试：关闭网络后刷新页面，工具依然可以正常生成和解析 ID。输入框里的数字、自定义参数（epoch、机器 ID）都不会离开你的浏览器。如果你需要处理敏感数据（如生产环境的真实 ID），可以放心使用。

可能原因有三个：1）数字位数不对——雪花 ID 是 64 位整数，十进制表示通常 18-19 位，少于 15 位或超过 20 位的数字大概率不是雪花 ID；2）数字超出了雪花 ID 的时间范围——如果解析出的时间戳早于 epoch（默认 2010 年）或晚于未来 100 年，工具会标记无效；3）你选了错误的风格——比如输入的是 Sonyflake 格式的 ID 却选了 Twitter 解析模式，两者时间戳位数和机器 ID 位数不同。建议先切换风格试试，或者检查原 ID 的生成系统文档确认风格类型。

当前版本不支持批量上传文件或粘贴多行批量解析，每次只能解析一个 ID。如果你需要批量处理，可以借助浏览器开发者工具（F12）的 Console 功能：本工具的核心解析函数暴露在全局 window 对象上，你可以在 Console 里写循环调用。或者将 ID 列表导出为 CSV，用其他脚本工具（如 Python 的 snowflake-id 库）批量处理。工具定位是单次快速验证和调试，大批量场景建议用编程方式处理。