Solana预热纪元怎么换算？

getEpochSchedule 的 warmup、firstNormalEpoch 与 firstNormalSlot 经常被误读。本文用时间线拆解预热纪元、正常纪元和当前进度的不同口径，并给出跨网络复核步骤。

很多脚本只读取 slotsPerEpoch，然后用“当前 Slot ÷ 固定长度”估算 Epoch。这个方法在正常阶段也可能因为起点处理错误而偏移，在启用 warmup 的网络早期则会直接算错。更稳妥的做法是先识别时间线处于哪一段，再决定使用固定长度还是预热规则。

先把五个字段放到同一条时间线上

getEpochSchedule返回firstNormalEpoch、firstNormalSlot、leaderScheduleSlotOffset、slotsPerEpoch和warmup五类纪元计划字段。

字段	它回答的问题	不应被解释成
warmup	是否存在预热纪元阶段	当前节点正在预热
firstNormalEpoch	第一个正常纪元编号	当前纪元编号
firstNormalSlot	正常纪元开始的 Slot	最新 Slot
slotsPerEpoch	正常阶段纪元长度	所有历史纪元都一样长
leaderScheduleSlotOffset	Leader 排班相对偏移	纪元长度修正值

这里最重要的区别是“网络计划”和“节点当前状态”。getEpochSchedule 返回计划参数，不带当前 Epoch、区块高度或完成比例。

warmup 为 true 时怎样判断边界

warmup用于标识早期纪元是否采用逐步扩大的预热计划；firstNormalEpoch和firstNormalSlot标出进入正常固定计划的边界。

先比较目标 Epoch 与 firstNormalEpoch：当 Epoch >= firstNormalEpoch（包含边界点）时，可按正常阶段的固定 slotsPerEpoch 理解；目标在边界之前，则不能把正常长度向前平铺。再比较目标 Slot 与 firstNormalSlot，可以发现脚本是否把预热阶段误算成普通阶段。

网络计划：warmup=true
预热区间：epoch < firstNormalEpoch
正常区间：slot >= firstNormalSlot
当前进度：另查 getEpochInfo

样例值只说明结构。mainnet、devnet、本地测试网可以返回不同参数，禁止把文档示例数字写死进生产代码。

当前进度要交给 getEpochInfo

计划字段本身不提供当前epoch与slot进度；实际监控应同时读取getEpochInfo，不能只用slotsPerEpoch反推当前状态。

一次可靠采样至少保存 endpoint、采样时间、getEpochSchedule 原始响应，以及同一节点紧邻调用的 getEpochInfo。后者提供当前 epoch、slotIndex、slotsInEpoch 等进度信息。两次请求之间仍可能推进若干 Slot，所以仪表盘应保留原始值，不伪装成原子快照。

三个容易制造假结论的算法

第一种是始终使用固定长度从 Slot 0 倒推；它忽略预热阶段。第二种是看到 warmup=true 就断言“现在仍在预热”；它混淆配置与当前位置。第三种是把 leaderScheduleSlotOffset 当作 Epoch 长度补偿；该字段描述排班偏移，不是进度百分比。

如果两个 RPC 后端给出不同结果，先核对网络 genesis、endpoint 和软件版本，再比较原始响应。不要先平均数值，因为网络连错和缓存落后都不是统计误差。

可交给第二位操作者的复核卡

固定网络与 RPC endpoint，保存请求时间。
原样记录五个计划字段，不先转换单位。
同步调用 getEpochInfo，标出 epoch、slotIndex 与 slotsInEpoch。
分别选取预热边界前、边界点和正常阶段样本复算。
任何无法解释的跨节点差异都标为未知，不延用旧缓存。

当前仍需保留的未知项是：不同网络的返回值可能不同，文章示例只能作为字段说明，不能把devnet样例数值当成主网固定参数。

一级资料和延伸阅读

Solana getEpochSchedule：用于核对接口字段、返回语义和适用边界；访问于 2026 年 7 月 25 日。
Solana getEpochInfo：用于核对接口字段、返回语义和适用边界；访问于 2026 年 7 月 25 日。

配套阅读可参考 getEpochInfo纪元进度、Slot、Block与Epoch区别、当前Slot Leader核对。本文解释数据口径，不提供收益预测或投资建议。