伟大航路服务端实现输入总览 ¶

文档目的 ¶

本文件不再继续补新规则，而是把当前已经产出的所有反推文档整理成一套“可直接作为服务端实现输入”的资料包。

它回答 5 个问题：

1. 现在这批文档里，哪些是实现前必须先看的。
2. 不同实现阶段分别应该看哪些文档。
3. 哪些规则已经可以直接写代码。
4. 哪些地方必须配置化，不能写死。
5. 哪些问题当前还没闭合，实现时必须留口。

一、使用方式 ¶

建议不要从头到尾顺序阅读全部文档。

更高效的方式是按下面三层使用：

1. 先看总装层 ¶

用于建立全局理解：

• 反推细化初稿
• 客户端协议清单
• 客户端与服务端字段差异表

读完这 3 份，应能回答：

• 伟大航路整体赛制是什么
• 客户端要哪些字段
• 当前服务端缺哪些层

2. 再看规则层 ¶

用于决定哪些逻辑可以直接实现：

• 客户端硬规则补充
• 灰盐岛客户端反推
• 青铜岛客户端反推
• 秘蓝岛客户端反推
• 紫青月宫客户端反推
• 黄金天宫客户端反推
• 黄金每周流转表

读完这组，应能回答：

• 五岛分别怎么流转
• 哪些名额和人数是硬规则
• 黄金天宫双败状态机如何落地

3. 最后看风险层 ¶

用于决定哪些地方必须做成配置或策略：

• 仍未闭合的规则表
• 反推缺口清单
• 安全复核
• 覆盖矩阵

读完这组，应能回答：

• 哪些细则不能写死
• 哪些安全点必须提前设计
• 哪些能力当前缺失最多

二、按实现阶段的阅读顺序 ¶

第一阶段：重做赛程调度层 ¶

目标：

• 从旧周赛盐场切到五岛阶段调度
• 让 legion_getinfo、legion_getbattlefield、saltroad_getwartype 说同一种语言

必看文档：

1. 反推细化初稿
2. 客户端协议清单
3. 客户端与服务端字段差异表
4. 玩法流程与证据

实现重点：

• 赛季号到赛制切换
• 岛屿到阶段类型切换
• legionWarType
• legionWarMapType
• battlefieldId
• 时间窗

第二阶段：补岛屿态与资格态 ¶

目标：

• 能正确记录军团当前在哪个岛
• 能正确锁成员、升月赛、升黄金

必看文档：

1. 客户端资格与积分字段
2. 客户端协议清单
3. 客户端与服务端字段差异表
4. 仍未闭合的规则表

实现重点：

• islandType
• isInExWeek / isInExMonth / isInExGoldMonth
• exWeekRiseDate
• 锁成员快照
• 月赛资格成员
• 黄金登岛成员

第三阶段：补排行与积分态 ¶

目标：

• 正确支撑排行页
• 正确给出晋级线和总榜

必看文档：

1. 客户端协议清单
2. 客户端资格与积分字段
3. 客户端硬规则补充
4. 仍未闭合的规则表

实现重点：

• riseNum
• blueRiseRound
• sRTotalScore
• sRGroupRank
• sRGScoreArr / sRBScoreArr / sRKScoreArr
• 总榜与小组榜

第四阶段：补黄金天宫专项 ¶

目标：

• 跑通黄金胜者赛、败者赛、总决赛
• 跑通黄金列表、淘汰状态和总决赛资格

必看文档：

1. 黄金天宫客户端反推
2. 黄金每周流转表
3. 客户端协议清单
4. 安全复核

实现重点：

• saltroad_getgoldenbflist
• saltroad_getwarrank
• sRGoldenOut
• 胜者 / 败者 / 总决赛状态机
• 提前淘汰与提前结算排名

三、文档职责表 ¶

四、已经可以直接实现的内容 ¶

这批内容当前证据最硬，可以直接进入服务端实现：

• S7 起切换伟大航路
• 五岛顺序
• 正式阶段枚举
• 正式地图枚举
• 灰盐岛：
  • 前 2000 入首战场
  • 8 / 4 / 4 升进阶赛
  • 前 15 进月赛
  • 前 960 升青铜岛
• 青铜岛：
  • 第 4 周前 16 进月赛
• 秘蓝岛：
  • 第 4 周前 16 进月赛
  • 月赛前 10 升月宫
• 月宫：
  • 第 4 周前 16 进月赛
  • 月赛前 10 升黄金
• 黄金天宫：
  • 总池 80
  • 双败结构
  • 胜者 4 -> 2 -> 1
  • 败者 2 -> 2 -> 1
  • 总决赛 1
• 客户端关键协议与字段主结构

五、必须配置化的内容 ¶

这些内容虽然能做，但不应该直接写死在业务逻辑里：

• 青铜岛升秘蓝岛 500 / 380 / 300
• 各岛总池规模
• 分组数量
• 并组阈值
• 每阶段时间窗
• 回流来源集合
• 晋级线和淘汰线

建议做法：

• 统一抽成赛季配置
• 逻辑层只消费配置结果
• 对外响应始终走统一字段

六、高风险待确认项 ¶

这些问题在当前文档里都已被标记，但实现时容易被忽略：

• 前四岛精确分组算法
• 岛屿积分表
• 小组同分规则
• 总榜同分规则
• 月赛资格成员继承链
• 黄金淘汰后的名次段
• 奖励矩阵
• 异常分支处理

建议做法：

• 状态机先闭环
• 细则做成策略口
• 避免先写死再大改

七、服务端实现时的最小输入集合 ¶

如果目标是“先做出一版结构正确、字段对齐的实现”，那最小输入集合只有 6 份：

1. 反推细化初稿
2. 客户端协议清单
3. 客户端与服务端字段差异表
4. 客户端硬规则补充
5. 黄金每周流转表
6. 仍未闭合的规则表

这 6 份已经足够支撑：

• 赛程调度
• 协议对齐
• 字段落地
• 黄金状态机
• 参数化边界设计

八、推荐交付顺序 ¶

后续真正开始做服务端时，建议按下面顺序交付，而不是按岛屿逐个做：

1. 赛程调度 ¶

交付目标：

• legion_getinfo
• legion_getbattlefield
• saltroad_getwartype

2. 资格与岛屿状态 ¶

交付目标：

• 当前岛屿
• 当前阶段
• 锁成员
• 月赛资格
• 黄金资格

3. 排行与积分 ¶

交付目标：

• 小组榜
• 总榜
• 晋级线
• 动态晋级档位

4. 黄金专项 ¶

交付目标：

• 黄金分组列表
• 黄金分组排行
• 黄金淘汰状态
• 总决赛资格与结算

九、最终结论 ¶

现有这批文档已经不再只是“调研记录”，而是一套能直接喂给服务端实现的输入包。

如果要避免后续实现反复推翻，实际使用时应遵循三条原则：

• 已确认规则直接实现
• 未闭合规则统一配置化
• 高风险边界统一留策略口

这样后续即使补到更完整证据，也不需要推翻整体结构。