Go snowflake 修改Epoch后旧编号的时间解释为何改变

旧编号的整数值没有变化，变化的是解释它的纪元。在 bwmarrin/snowflake v0.3.0 中，ID.Time() 使用当前包级 Epoch 加上编号里的毫秒偏移。仅把解码时的 Epoch 增加一天，同一旧编号就会被解释成晚一天。编号本身不保存“当初使用哪个 Epoch”的版本标签。

项目官方地址：https://github.com/bwmarrin/snowflake。本文固定讨论 v0.3.0 的实现，避免把特定版本行为泛化到所有 Snowflake 库。对需要长期保存编号的服务，Epoch 应作为数据格式的一部分管理，而不是普通的动态业务配置。

时间变化来自解码约定，不是旧编号被改写

默认节点位10位、序列位12位，低位合计22位。把非负编号右移22位，得到的是从生成纪元起算的毫秒偏移，不是 Unix 时间戳。解码还需要加回原来的纪元。

Unix毫秒时间 = (编号 >> 低位总数) + 生成纪元毫秒值。固定编号和位宽时，新旧解释值之差正好是新旧纪元之差。这是公式推导，不是对某次线上故障的实测记录。

例如，设某编号的时间偏移为5000毫秒，旧格式使用 E，新的解码配置使用 E＋86400000，那么解释结果分别是 E＋5000 和 E＋86405000。差值来自基准变化，重新读取数据库中的相同整数不会消除它。

如果连 NodeBits、StepBits 也一起改变，还可能取错时间字段的起点，不能再用“只差一个固定天数”解释。排查时先确认数字有没有变，再确认低位总数和 Epoch 是否与生成时一致。

同一进程中的旧Node为何更容易混淆

v0.3.0 的 NewNode 会把创建时采用的纪元保存到节点内部，Generate 使用该节点状态；而 ID.Time() 读取的是包级 Epoch。因而在创建节点后继续修改全局 Epoch，会让生成器与时间解释器依赖不同基准。修改全局变量不会把已有 Node 自动重新配置。

这只是说明实现为何可能出现不一致，不能当作推荐的切换方法。项目说明要求在调用任何包函数之前设置自定义纪元和位宽，包括 NewNode。并发运行期间修改这些全局变量，还会引入数据竞争等问题。

此外，该版本把 Time() 标为弃用接口。历史数据服务更适合持有明确的格式参数，而不是反复切换包级 Epoch 来读取不同批次的记录。

保留纪元与切换格式怎样选择

对普通服务迁移，优先考虑保留原纪元。换机器、容器或部署区域通常不需要改变已经确定的数据格式。确实要切换时，可以让应用保存 format_id 与 id，并在独立配置中固定每个格式的纪元、节点位和序列位；这些字段是应用设计，不是库内置能力。

只在数据库里添加 format_id 还不够：如果公开接口、缓存键或业务关联仍把裸整数当作全局唯一键，新旧格式的数字空间可能重叠。应使相应边界也识别格式，或保持原命名空间不变。不能把“新纪元”直接等同于“绝不碰撞的新ID空间”。

用显式格式解码历史编号

下面是应用侧的原创小型解码器，不调用库的全局时间解释方法。它接受非负编号、非负纪元和不超过22的低位总数，显式处理加法溢出。示例只负责取出时间偏移并相加，不验证编号来源或证明业务事件真实发生。

package idtime

import "fmt"

// Format 是应用维护的解码约定，不依赖可变的包级配置。
type Format struct {
    EpochMS int64
    LowBits uint8
}

// UnixMillis 仅适用于本文讨论的非负、最多63位的编号布局。
func (f Format) UnixMillis(id int64) (int64, error) {
    if id  22 {
        return 0, fmt.Errorf("编号或格式参数不符合约定")
    }
    offset := id >> f.LowBits
    const maxInt64 = int64(1 maxInt64-offset {
        return 0, fmt.Errorf("解码时间超出int64范围")
    }
    return f.EpochMS + offset, nil
}

对本文版本的默认布局，可以把旧格式固定为 Format{EpochMS: 1288834974657, LowBits: 22}。自定义历史布局必须使用自己的实际参数，不能因为库的默认值看起来熟悉就套用。调用返回的整数单位是毫秒；转换成日期时也应使用毫秒语义，避免再引入秒与毫秒混用。

此处代码没有执行，也不提供伪造输出。生产读路径可先根据 format_id 选取固定格式，再调用该函数；遇到未知格式应返回明确错误，不应静默使用当前生成器配置。

迁移时保留哪些信息

建议为每一种已使用格式保存纪元的精确毫秒值、节点位与序列位、库版本和格式适用范围。旧数据保留原编号；若业务需要稳定的创建时间字段，应在产生事件时独立记录，而不是把ID解码时间当作所有业务时间的替代品。

切换计划还要覆盖旧消息、延迟消费、缓存数据及回滚部署。只更新写入服务的配置，而遗漏仍在解释旧编号的消费端，会把同一问题带到其他系统。回滚也不应删除已经产生的新格式定义，否则新格式数据会失去正确读法。

能从整数自动识别Epoch吗？这类裸编号没有内置纪元标签；多个基准都可能解释出看似合理的日期。应查生成配置或可信来源，不能靠日期“看起来正常”确定格式。

把Time结果换个时区能修复吗？时区改变日期的显示方式，不能修复纪元加错造成的 Unix 毫秒值偏差。

重新ParseInt64能找回旧纪元吗？该版本的转换只保留整数值，不恢复外部格式约定。持久保存正确的格式信息，才是长期可读的基础。

参考：v0.3.0 实现；自定义纪元与配置说明。