开服时间线
为什么需要一条「开服时间线」
开服表是一张快照，时间线则是一段录像。快照只能告诉你某个服务器此刻的状态，而时间线能还原它从首次出现在整理视野，到经历版本调整、开放时段变更、状态升级或降级的完整轨迹。对于真正想选一个长服、而不是玩三天就跑的人来说，这种纵向信息比横向对比更有价值——一个连续公告 386 天的服务器，和一个开服三天就消失、隔月换个名字重新出现的服务器，在开服表上可能并排出现，但只有时间线能把它们区分开。
本站的时间线记录遵循三条原则：只记录可核实的节点（首次收录、开放时间变更、版本更新、状态调整、下架归档），不记录玩家投稿中的未证实传闻；节点必须带批次来源（上午批、午间批、晚间批中的哪一次校订写入）；下架不等于删除，所有移出今日开服表的条目都会在时间线中保留最后一次状态变更的记录，并标注移出原因。
如何读一条时间线节点
看「变更类型」而非「服务器名字」
时间线节点的核心是变更动作：新收录、时间调整、版本升级、状态降级、下架归档。同一个服务器名可能在不同日期出现多次，每次出现的含义完全不同。先判断变更类型，再判断这个变更对你的选服决策意味着什么。
对照「批次时间」判断信息新鲜度
每个节点都标注了写入批次。上午批次（08:30）处理的是昨夜到今晨的信息，午间批次（14:00）处理上午的新投稿，晚间批次（20:30）做当日复盘。如果你在晚上十点看到一条标注「午间批次」的节点，说明它至少已经过了一轮晚间复核。
连续节点比单点更有说服力
一个服务器如果在时间线上连续三个月每周都有例行节点（公告更新、时间微调、状态确认），说明维护者保持着稳定的信息输出习惯。反之，如果上一次节点停留在两个月前，之后没有任何更新，即使在今日开服表里仍然显示「稳定」，实际参考价值也要打折扣。
时间线覆盖的四种变更
新收录节点
服务器首次进入本站观察范围时写入。记录内容包括：服务器名、类型、版本/等级上限、开放时段、信息来源（公告/投稿/观察）。新收录不代表推荐，只代表进入核查队列。
信息变更节点
开放时间调整、版本更新、等级上限变化、运营方公告关键内容变动时写入。变更前后的字段都会保留，方便对比。变更超过三次且方向不稳定的条目，会在晚间批次被降级为「观察中」。
状态确认节点
每满 30 天连续观察无重大异常，写入一次「状态确认」。这是时间线上最安静的节点，但恰恰是它们构成了长服判断的基础。连续 12 次状态确认，对应的是约一年的稳定观察记录。
下架/归档节点
频繁掉线、公告停更超过 60 天、信息无法核实或运营方明确停止开放时写入。下架条目不会从时间线消失，而是带着最后的变更原因沉入归档层，方便回溯。
一条节点如何被写入时间线
时间线不是自动生成的流水账，每一笔记录都要经过至少两轮人工核对。流程并不复杂，但每一步都直接关系到这条时间线是否值得被当作选服依据。
- 来源登记：玩家投稿、公开公告、编辑部观察，三类来源分别登记，不混合处理。投稿类默认标记为「待核实」，不直接写入时间线。
- 字段核对：至少核对开放时间、版本/等级上限、类型三个字段。缺少公示渠道或无法确认的信息，一律暂缓写入，标记为「信息不足」。
- 批次写入：通过核对的节点，在最近的一个校订批次写入时间线，并附上批次标识。同一服务器同一天的多个变更合并为一条节点，不做刷屏式记录。
- 复核留痕：写入后的下一次校订中，对前一批次的新节点做复核。如果发现错误，直接修正并在时间线上保留修正痕迹，不覆盖原记录。
这套流程决定了时间线的更新频率上限：每天最多三个批次，每批次处理的信息量有限，但每一条写入的节点都经过至少两轮检查。代价是速度不会特别快，回报是时间线可以作为一本可以倒回去翻的台账来用。
把时间线用在选服决策里的三个建议
时间线节点字段说明
| 节点时间 | 服务器名称 | 变更类型 | 变更内容 | 批次来源 |
|---|---|---|---|---|
| （示例条目） | 新收录 | 首次进入观察队列，类型：公益服，版本：110级 | 午间批次 | |
| （示例条目） | 信息变更 | 开放时间由「全天」调整为「每日 20:00」 | 晚间批次 | |
| （示例条目） | 状态确认 | 连续观察满 90 天，无重大异常，状态维持「稳定」 | 上午批次 | |
| （示例条目） | 下架归档 | 公告停更超过 60 天，移出今日开服表，保留归档记录 | 晚间批次 |
说明：以上为字段结构演示，实际时间线内容以系统生成的归档数据为准，不包含示例条目中的具体服务器信息。