伟大航路服务端深度反推报告 ¶

一、结论摘要 ¶

基于客户端源码、客户端规则文本、服务端现有代码、服务端配置和测试，当前可以稳定反推出以下事实：

1. 客户端目标形态已经不是“单一周赛盐场”，而是“五岛 + 黄金联赛”的完整玩法外壳。
2. 服务端运行时底座已经具备盐场战场的大部分动作链路，但赛程调度和阶段编排仍停留在固定周赛盐场。
3. 因此后续服务端实现不能再围绕“固定 legionWarType=15 / mapType=7”继续堆补丁，必须抽象成“赛季/阶段/岛屿 -> 场次 -> 地图 -> 资格 -> 运行时”的动态调度。
4. 仅靠客户端可以高覆盖率反推出服务端必做能力，但对分组算法、排行细则、锁榜时点、部分奖励边界不能保证零遗漏，这些必须保留“待业务确认”标签。

二、赛季与阶段反推 ¶

1. 客户端目标赛制 ¶

客户端已经暴露以下阶段：

• 灰盐岛
• 三星堆青铜岛
• 玛雅秘蓝岛
• 紫青月宫
• 黄金天宫

并进一步暴露以下战场类型：

• 灰盐岛周赛、高阶赛
• 青铜岛周赛
• 秘蓝岛周赛
• 月宫周赛
• 黄金天宫胜者赛
• 黄金天宫败者赛
• 黄金天宫决赛

这说明服务端最终至少要支持多 legionWarType 与多 legionWarMapType 的动态组合。

2. 服务端当前状态 ¶

服务端 info.go 仍然固定返回：

• type = 10
• legionWarType = 15
• legionWarMapType = 7
• battlefieldId = LW_WEEK-<日期>

这意味着：

• 当前报名查询默认只认一种周赛场次
• 当前 battlefieldId 结构也没有区分月赛、胜者赛、败者赛、总决赛
• 配置层虽然具备五岛/黄金联赛，但调度层没有接上

3. 必然的服务端实现要求 ¶

服务端必须新增一个真正的“阶段决策层”，输入至少包括：

• 当前赛季号
• 当前自然时间
• 当前比赛周次/周内天数
• 俱乐部所处岛屿
• 是否处于黄金联赛资格锁定后
• 当前阶段是周赛、月赛、胜者赛、败者赛还是总决赛

输出至少包括：

• battlefieldType
• legionWarType
• legionWarMapType
• battlefieldId
• signupStartTime
• signupEndTime
• readyTime
• startTime
• endTime
• 当前阶段名称、规则页、排行口径

三、报名、资格与查询反推 ¶

1. 当前已实现部分 ¶

• legion_signup
• legion_getbattlefield
• TopN 资格检查
• 基础报名成员名单记录

这些说明服务端已经有最简盐场报名模型。

2. 客户端和规则文本要求的扩展能力 ¶

若按伟大航路规则实现，服务端还必须支持：

• 不同岛屿、不同赛段的报名窗口
• 周赛、进阶赛、月赛、胜者赛、败者赛、总决赛的不同锁人时点
• 岛屿登岛成员绑定
• 锁定成员不能跨俱乐部/跨岛屿重复参赛
• 黄金资格锁榜与最终资格冻结
• 查询接口返回“当前可报名的是哪一种场次”，而不是固定单一周赛

3. 当前无法直接证明但必须保留的点 ¶

以下事项在客户端能看到结果，但无法从当前仓库完整反推算法：

• 后续战场分组算法
• 跨赛季分组范围细节
• 候选排名与综合算分逻辑
• 晋升补录的精确执行算法
• 黄金 500 强锁榜细节

这些必须作为“待业务确认”而不是开发时拍脑袋补逻辑。

四、战场运行时反推 ¶

1. 已可复用的底座 ¶

当前服务端已经能处理：

• 进入战场
• 拉取战场信息
• 行军与加速
• 攻击其他玩家
• 攻击与占领建筑
• 设置战斗队伍
• 查询队伍信息
• 重进恢复
• 观战态与玩家态切换
• 消除跨俱乐部脏队伍

这说明伟大航路大多数岛屿如果仍采用盐场据点战骨架，运行时不需要从零重做。

2. 仍需补的阶段差异 ¶

真正缺的是“运行时之前”的编排和“运行时之后”的收束：

• 这场比赛属于哪种阶段
• 参战资格从哪里来
• 本场结束如何晋升、降级或完赛
• 个人与俱乐部积分怎么记到跨周状态里
• 天宫双败如何衔接下一场

五、排行、结算、奖励与持久化反推 ¶

1. 当前可确认的基础设施 ¶

当前服务端已存在：

• 盐场结算锁
• 俱乐部排行奖励与个人排行奖励基础设施
• 建筑积分和占点积分配置体系

2. 伟大航路必须新增或补齐的持久化对象 ¶

如果要完整实现五岛和黄金联赛，至少需要明确持久化以下状态：

• 俱乐部当前岛屿
• 当前赛季内的登岛成员绑定
• 周赛、进阶赛、月赛阶段归属
• 跨周累计积分
• 小组分组结果
• 晋级、淘汰、回落结果
• 天宫胜者/败者赛链路状态
• 黄金积分与锁榜快照
• 奖励已发放标记

3. 当前最明显的缺口 ¶

仓库里没有证据证明以下状态已完整落地：

• 五岛阶段持久化状态机
• 双败赛程状态机
• 黄金积分榜冻结与发资格邮件的完整实现
• 不同岛屿月赛后的晋升/淘汰全链路持久化

六、待确认清单 ¶

以下内容不能只靠当前客户端和现有 Go 代码零风险补齐：

1. 各阶段精确分组算法
2. 进阶赛和月赛的跨赛季分组分桶规则
3. 岛屿积分并列时的完整同分优先级
4. 黄金 500 强锁榜、锁成员、发邮件的完整时点
5. 天宫解散俱乐部镜像回流规则的真实生产口径
6. 未入围/战场不足 20 个俱乐部时的完整补偿规则

七、反推后的服务端最小实施顺序 ¶

1. 重写赛程调度层，替换固定 BuildWarInfo() 口径。
2. 让 legion_getbattlefield 与 legion_signup 依赖动态阶段结果。
3. 增加岛屿/阶段/成员绑定持久化模型。
4. 接通周赛/月赛/胜败者赛/决赛的晋升淘汰状态机。
5. 最后补黄金积分、锁榜、资格与奖励。

这样做的原因是：当前最危险的不是单个接口缺字段，而是整个系统仍把伟大航路“压扁成一场旧盐场周赛”。