开服时间线
时间线如何读
三条原则，避免被单条记录误导先看状态变化，再看当前状态
一个服务器从「稳定」变为「观察中」，远比它一直挂着「稳定」更有信息量。时间线记录的是变化本身：开放时间调整、公告断更、维护异常、批次降级，都会被留痕。只看当前快照，等于把观察过程全部丢掉。
区分「开服事件」与「校订事件」
时间线上既有服务器自身的开放、停机、改版事件，也有本站的校订动作。前者是服务器运营方的行为，后者是本站对信息可信度的调整。两者混在一起读，会误判服务器本身的活跃程度。
回看旧记录，判断长期行为
单次开服说明不了什么。把同一服务器的历史时间线拉出来看：它的开放时间是否反复修改？公告是否周期性断更？是否曾经被下架后又重新上架？长期行为才是一个服务器是否值得投入时间的核心依据。
每日批次与时间线节点
三个固定校订点，对应时间线上的三类事件昨夜公告与玩家投稿归集
把前一晚到次日清晨的服务器公告、玩家反馈、停机说明逐条比对。重点核对服务器是否按公示时间开放，临时变更是否已在原渠道说明。任何「公示时间与实际不符」的条目，会在时间线上记为一条校准事件。
新服务器资料补齐与字段校订
处理新提交的服务器资料，补齐版本号、开放时间、运营方公示渠道。缺少公示渠道或字段严重缺失的，不会进入正式时间线，只保留为「信息不足」的待核条目，直到第 3 次核实通过后才转正。
当日反馈复盘与条目升降级
把当日频繁掉线、公告长期不更新、开放时间反复修改的服务器做降级处理；对连续观察期内无异常且公告稳定的服务器做升级确认。每一条升降级都会在时间线上留痕，标注具体原因与观察天数。
时间线记录的主要事件类型
同一口径，便于跨服务器对比| 事件类型 | 含义 | 时间线记录方式 |
|---|---|---|
| 首次收录 | 服务器第一次通过字段核实，进入正式表格 | 标记为「首录」，附来源批次 |
| 状态升级 | 从「观察中」升为「稳定」，需满足连续公告与无异常 | 记录升级时点与累计观察天数 |
| 状态降级 | 从「稳定」降为「观察中」或直接下架 | 记录具体原因，如掉线、断更、公告失效 |
| 开放时间调整 | 服务器公示的开放时段发生变化 | 保留调整前与调整后对照 |
| 版本变更 | 服务器从某一版本迁移到另一版本 | 关联版本百科对应条目 |
| 下架/归档 | 无法核实或运营终止，移出活跃表格 | 保留最后一条有效记录与下架原因 |
时间线回溯方法
从当下往过去翻，找到变化拐点锁定一个服务器，沿时间线反向翻阅
从当前状态开始，往前逐条看它的状态变更与校订事件。重点不是它「现在是什么」，而是它「什么时候变的、因为什么变的」。拐点密集的服务器，稳定性判断要更保守。
横向对比同版本、同类型条目
把时间线当作筛选工具：同类型服务器中，谁的状态变更更少、公告续期更长、开放时间更稳定，谁就更值得优先观察。横向对比比单独看一个条目更接近真实情况。
结合版本百科与开服表交叉验证
时间线上的版本变更事件，应跳转到版本百科查看对应版本说明；状态变更事件，应回到今日开服表确认当前状态是否一致。三者互相印证，才能减少误判。