伟大航路服务端反推细化初稿 ¶

文档目的 ¶

本文件用于把当前分散在各个反推文档中的结论收口成一份“可实现、可评审、可继续细化”的初稿。

目标不是重复所有证据，而是回答 4 个问题：

1. 伟大航路这套玩法的骨架到底是什么。
2. 哪些规则已经能直接落到服务端。
3. 客户端实际上依赖了哪些字段和状态。
4. 当前服务端离目标玩法还差哪几层。

配套细节文档可继续参考：

• 玩法流程与证据
• 客户端硬规则补充
• 客户端资格与积分字段
• 客户端与服务端字段差异表
• 黄金天宫客户端反推
• 黄金每周流转表
• 仍未闭合的规则表

一、总判断 ¶

当前仓库反推得到的最稳定结论是：

• S7 起，旧盐场升级为“伟大航路”。
• 伟大航路不是单一地图，而是“5 个岛 + 多阶段战场”的赛季体系。
• 战场内的玩法骨架仍然是盐场据点战。
• 客户端已经完整暴露了：
  • 岛屿顺序
  • 阶段类型
  • 地图类型
  • 基础资格字段
  • 黄金天宫双败结构
• 服务端当前已经具备：
  • 地图和建筑配置
  • 战场内运行时
  • 旧周赛盐场的报名和查战场
• 服务端当前仍缺：
  • 五岛赛程调度
  • 岛屿状态持久化
  • 分阶段资格与锁成员
  • 岛屿积分与排行字段
  • 黄金专项列表和淘汰状态字段

二、赛制总骨架 ¶

1. 赛季切换 ¶

已确认：

• SecondSeasonStart = 7
• 客户端在 currentSeasonNum >= 7 时进入伟大航路赛制

结论：

• S7 是运行时切换条件，不只是文案描述。

2. 岛屿顺序 ¶

当前可以直接确认的顺序为：

1. 灰盐岛
2. 三星堆青铜岛
3. 玛雅秘蓝岛
4. 紫青月宫
5. 黄金天宫

3. 阶段类型 ¶

客户端正式阶段枚举已经固定：

• GREY_WEEK = 15
• GREY_WEEK_HIGH = 16
• GREY_MONTH = 17
• GREEN_WEEK = 18
• GREEN_MONTH = 19
• BLUE_WEEK = 20
• BLUE_MONTH = 21
• PURPLE_WEEK = 22
• PURPLE_MONTH = 23
• GOLDEN_VICTOR = 24
• GOLDEN_LOOSER = 25
• GOLDEN_FINAL = 26

结论：

• 灰盐岛必须拆成周赛、进阶赛、月赛三个阶段。
• 青铜、秘蓝、月宫至少拆成周赛、月赛两个阶段。
• 黄金天宫必须拆成胜者赛、败者赛、总决赛三个阶段。

4. 地图类型 ¶

客户端地图类型枚举已经固定：

• GREY_WEEK_MAP = 13
• GREY_WEEK_HIGH_MAP = 14
• GREY_MONTH_MAP = 15
• GREEN_WEEK_MAP = 16
• GREEN_MONTH_MAP = 17
• BLUE_WEEK_MAP = 18
• BLUE_MONTH_MAP = 19
• PURPLE_WEEK_MAP = 20
• PURPLE_MONTH_MAP = 21
• GOLDEN_VICTOR_MAP = 22
• GOLDEN_LOOSER_MAP = 23
• GOLDEN_FINAL_MAP = 24

结论：

• 服务端不能只告诉客户端“当前在哪个岛”。
• 服务端必须同时下发：
  • legionWarType
  • legionWarMapType
• 否则客户端无法正确加载阶段页面和地图资源。

三、五岛细化规则 ¶

1. 灰盐岛 ¶

当前已确认的硬规则：

• 报名候选按总红色淬炼数、总战力等数据计算排名。
• 前 2000 家俱乐部进入灰盐岛首战场。
• 首战场前 3 周晋级进阶赛名额分别为：
  • 第 1 周：前 8
  • 第 2 周：前 4
  • 第 3 周：前 4
• 第 4 周不再新增进阶赛晋级名额。
• 进入进阶赛后，按小组排名累计岛屿积分。
• 第 4 周进阶赛结束后，小组累计积分前 15 晋级月赛。
• 月赛后总积分前 960 晋级青铜岛。

服务端实现含义：

• 灰盐岛至少要区分三类资格池：
  • 首战场资格池
  • 进阶赛资格池
  • 月赛资格池
• 不能把灰盐岛合并成单一 week 类型。

2. 三星堆青铜岛 ¶

当前已确认的硬规则：

• 参赛来源包括：
  • 灰盐岛晋升俱乐部
  • 秘蓝岛淘汰俱乐部
• 周赛后按小组排名累计岛屿积分。
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回灰盐岛。
• 月赛后，总积分前若干晋级秘蓝岛。

当前已确认的动态晋级档位：

• 500
• 380
• 300

客户端会根据 blueRiseCount / blueRiseRound 动态展示名额。

服务端实现含义：

• 青铜岛升秘蓝岛人数不能简单写死一个值。
• 该阈值必须配置化，且要能回填到排行接口字段。

3. 玛雅秘蓝岛 ¶

当前已确认的硬规则：

• 分组池总量为 500 家俱乐部。
• 来源包括：
  • 青铜岛晋升俱乐部
  • 月宫淘汰俱乐部
  • 黄金天宫归来俱乐部
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回青铜岛。
• 月赛后，小组积分前 10 晋级月宫。

服务端实现含义：

• 秘蓝岛不仅要承接青铜岛晋升，还要承接高岛回流。
• 因此必须存在“来源池合并 + 分组”的调度逻辑。

4. 紫青月宫 ¶

当前已确认的硬规则：

• 月宫总池规模为 200 家俱乐部。
• 来源为秘蓝岛晋升俱乐部。
• 第 4 周周赛结束后，小组累计积分前 16 晋级月赛。
• 其余俱乐部淘汰回秘蓝岛。
• 月赛后，小组积分前 10 晋级黄金天宫。

服务端实现含义：

• 月宫是黄金天宫的唯一直接入口池。
• 月宫月赛结果必须能生成黄金入围名单。

5. 黄金天宫 ¶

当前已确认的硬规则：

• 黄金总池规模为 80 家俱乐部。
• 来源为月宫晋升俱乐部。
• 黄金使用双败淘汰制。
• 失败两场后淘汰。
• 黄金完赛或掉线后回流秘蓝岛。

客户端已明确暴露的结构：

• 胜者线分组数：4 -> 2 -> 1
• 败者线分组数：2 -> 2 -> 1
• 总决赛分组数：1

按周流转可整理为：

第1周
  胜者赛：4组 * 20 = 80
  每组前10 -> 第2周胜者赛
  每组后10 -> 第2周败者赛

第2周
  胜者赛：2组 * 20 = 40
  败者赛：2组 * 20 = 40
  胜者前10 -> 第3周胜者赛
  胜者后10 + 败者前10 -> 第3周败者赛
  败者后10 -> 淘汰

第3周
  胜者赛：1组 * 20 = 20
  败者赛：2组 * 20 = 40
  胜者前10 -> 总决赛
  胜者后10 -> 第4周败者赛
  败者每组前5 -> 第4周败者赛
  其余 -> 淘汰

第4周
  败者赛：1组 * 20 = 20
  前10 -> 总决赛
  后10 -> 淘汰

总决赛
  1组 * 20 = 20
  决出冠军和剩余排名

服务端实现含义：

• 黄金至少要持久化：
  • 当前线别
  • 当前周次
  • 当前组号
  • 已失败次数或等价淘汰状态
  • 是否已进入总决赛
  • 是否已提前结算排名

四、战场内玩法骨架 ¶

虽然外层赛制升级为伟大航路，但每一场战场内部仍然沿用盐场据点战骨架：

• 报名
• 锁定参赛成员
• 查询战场
• 提前进场
• 布阵
• 行军
• 打玩家
• 打建筑
• 占点
• 个人分与俱乐部分结算

结论：

• 当前服务端已有的 saltfield_module_handlers.go 和战场运行时并不是废弃代码。
• 伟大航路新增的重点不在“战场内战斗”，而在“战场外赛程编排与资格结算”。

五、客户端字段契约 ¶

客户端已经显式依赖一套比旧盐场更完整的字段。

1. 战场基础字段 ¶

客户端 GDBattlefieldInfo 至少依赖：

• phase
• type
• subType
• legionWarMapType
• signupStartTime
• signupEndTime
• readyTime
• startTime
• endTime
• battlefieldId
• battlefieldNumber
• canEnterWar
• sid
• domainName

2. 伟大航路入口与阶段字段 ¶

客户端还依赖：

• islandType
• exWeekRiseDate
• isInExWeek
• isInExMonth
• isInExGoldMonth
• mapList

这些字段决定：

• 当前岛屿
• 当前是否处于进阶赛阶段
• 当前是否处于月赛阶段
• 当前是否处于黄金月赛阶段
• 前端该展示哪些入口和提示

3. 排行与资格字段 ¶

客户端排行页和规则页还依赖：

• riseNum
• blueRiseRound
• sRTotalScore
• sRGroupRank
• sRGScoreArr
• sRBScoreArr
• sRKScoreArr
• sRGoldenOut

这些字段对应：

• 当前晋级线
• 青铜岛动态晋级档位
• 小组积分
• 总积分
• 黄金淘汰标记

4. 黄金专项字段 ¶

黄金页面和跳转至少依赖：

• selfBfId
• bfList[]
  • bfId
  • legionWarType

结论：

• 伟大航路服务端不能只提供旧盐场那种“单场战场信息”。
• 必须额外生成“赛程态 + 岛屿态 + 资格态 + 排行态”。

六、当前服务端现状 ¶

1. 已有部分 ¶

当前已明确存在：

• LegionWarMapConf
• LegionWarMapTypeMappingConf
• 地图和建筑配置缓存
• 战场内运行时
• 基础报名记录
• 基础查战场返回结构

这一层说明：

• 不是完全从零开始。
• 地图与战斗运行时底座基本够用。

2. 卡住的关键点 ¶

当前最明显的旧口径代码在：

• info.go

已确认其固定返回：

• type = 10
• legionWarType = 15
• legionWarMapType = 7
• battlefieldId = LW_WEEK-*

这意味着：

• 当前查战场和报名仍然停在旧周赛盐场模式。
• 配置里虽然已经有五岛地图类型，但运行时没有切过去。

3. 当前缺失的层次 ¶

结合客户端契约，当前服务端主要缺这几层：

• 五岛赛程调度层
• 岛屿状态持久化层
• 分阶段资格与锁成员层
• 岛屿积分与排行层
• 黄金专项分组列表层

七、按实现视角拆分的最小模型 ¶

如果按“先做出可运行版本”来设计，服务端最少要补这些状态对象。

1. 俱乐部赛季态 ¶

至少需要：

• 当前赛季号
• 当前岛屿
• 当前阶段
• 当前是否已报名
• 当前是否已淘汰
• 当前是否已完成该阶段结算

2. 阶段资格态 ¶

至少需要：

• 报名锁成员列表
• 月赛资格成员列表
• 黄金登岛成员列表
• 资格快照时间
• 资格失效标记

3. 阶段排行态 ¶

至少需要：

• 当前小组积分
• 当前总积分
• 小组名次
• 总榜名次
• 当前晋级线
• 青铜动态晋级档位

4. 黄金专项态 ¶

至少需要：

• 当前在线别
• 当前轮次
• 当前组号
• 当前失败次数
• 是否淘汰
• 是否已获得最终排名

八、可直接实现的部分 ¶

按当前证据，可以直接落地的内容有：

• S7 切新赛制
• 五岛顺序
• 阶段枚举与地图枚举
• 灰盐岛 8 / 4 / 4 / 15 / 960
• 青铜岛第 4 周前 16 进月赛
• 秘蓝岛第 4 周前 16 进月赛，月赛前 10 升月宫
• 月宫第 4 周前 16 进月赛，月赛前 10 升黄金
• 黄金天宫 80 家双败主线
• 客户端基础战场字段集
• 基础资格限制语义

九、必须参数化的部分 ¶

这些内容建议一开始就做成配置或策略函数，不要写死在业务逻辑里：

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

十、高风险待确认项 ¶

这些细节现在还不能直接写死，否则后续偏差会比较大：

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

这些项目前更适合：

• 先留配置口子
• 先做可替换策略
• 先保证状态机闭环

十一、当前最合理的实现顺序 ¶

第一阶段：赛程调度层 ¶

先替换旧的固定 BuildWarInfo() 逻辑，做到：

• 根据赛季号决定旧盐场还是伟大航路
• 根据当前日期决定当前岛屿和阶段
• 返回正确的：
  • legionWarType
  • legionWarMapType
  • battlefieldId
  • 时间窗

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

补齐：

• 俱乐部当前所在岛屿
• 当前阶段资格
• 锁成员
• 月赛资格成员
• 黄金登岛成员

第三阶段：排行与晋级态 ¶

补齐：

• 小组积分
• 总积分
• 当前晋级线
• 动态晋级档位
• 阶段结束后的升降去向

第四阶段：黄金专项 ¶

补齐：

• 胜者/败者/总决赛状态机
• 黄金组列表
• 淘汰标记
• 提前结算排名

十二、结论 ¶

如果按当前客户端和配置来实现，已经足够做出一版“结构正确、字段对齐、可继续细化”的服务端版本。

当前真正缺的不是地图和战斗，而是：

• 赛程调度
• 岛屿状态
• 成员资格
• 排行结算

因此，这份初稿可以直接作为后续服务端实现的第一版输入：

• 已确认部分直接实现
• 不确定部分做成配置和策略
• 高风险部分显式留口

这样既不会卡在“必须完全反推完再动手”，也不会因为过早写死而导致后续大改。