伟大航路反推缺口清单 ¶

文档目的 ¶

本清单用于补足当前“伟大航路服务端反推”中仍未闭合的信息缺口。

现有文档已经基本确认了以下事实：

• S7 起进入新赛制口径。
• 客户端、配置、规则文本已经暴露出“五岛 + 黄金阶段”的玩法骨架。
• 服务端战场内运行时链路大部分存在。
• 服务端赛程调度与阶段状态机仍停留在旧周赛盐场口径。

但要将其真正落地为服务端实现，仅有玩法骨架仍然不够。仍需对赛制细节、资格边界、结算口径、安全约束进行更深一层的反推。本文件列出这些缺口，并按优先级给出建议。

缺口分类 ¶

一、赛程编排缺口 ¶

这一类缺口决定“什么时候打什么比赛”，属于全系统的时间主线。

仍需补齐的信息：

• 每个阶段的精确时间窗。
  • 周赛报名、公示、开战、结束时间是否全岛统一。
  • 进阶赛、高级赛、月赛、黄金赛的开启日历是否复用旧盐场。
• 同一赛季内各阶段的先后顺序。
  • 灰盐岛四场周赛、三场进阶赛、一场月赛的精确排列。
  • 青铜岛、秘蓝岛、月宫的周赛和月赛是否固定在月内第几周。
  • 黄金天宫胜者赛、败者赛、总决赛是否严格按周推进。
• 赛季切换边界。
  • 月末、赛季末、年度黄金联赛锁榜日如何切换。
  • 切换当天未完成的战场如何结算。
• 战场编号规则。
  • battlefieldId 是否要按岛屿、阶段、日期编码。
  • 胜者组、败者组、总决赛是否使用不同前缀。

为什么重要：

• 这是服务端 BuildWarInfo() / BuildBattlefieldQueryPayload() 一类函数的核心输入。
• 时间窗不准，会导致报名、进场、领奖、资格判断全部偏移。

二、晋级与降级缺口 ¶

这一类缺口决定“俱乐部打完后去哪”，属于赛制状态机主轴。

仍需补齐的信息：

• 各岛具体晋级人数和淘汰人数。
  • 灰盐岛进入青铜岛的精确数量。
  • 青铜岛、秘蓝岛、月宫进入下一岛的精确数量。
  • 各岛回落到上一岛的精确数量。
• 进阶赛和月赛的衔接口径。
  • 灰盐岛是按单场排名、累计积分还是混合规则进入进阶赛和月赛。
  • 青铜岛、秘蓝岛、月宫是否也存在阶段内累计积分。
• 黄金阶段双败流转。
  • 胜者赛失败后进入哪一轮败者赛。
  • 败者赛再次失败后是否直接淘汰。
  • 总决赛资格如何确定。
• 同分裁定规则。
  • 俱乐部积分相同如何排序。
  • 是否使用占城积分、总战力、历史成绩、报名顺位等作为后备规则。
• 赛事无法开启时的降级处理。
  • 人数不足导致战区不开启，是否视为未入围、弃赛或自动回落。

为什么重要：

• 这决定了是否需要持久化“俱乐部当前所处岛屿、阶段、赛果来源”。
• 若该处反推错误，整个岛屿状态机会从第二周开始跑偏。

三、成员资格与锁名单缺口 ¶

这一类缺口决定“谁能打”，直接影响权限与安全。

仍需补齐的信息：

• 报名锁定的成员名单是否跨阶段继承。
  • 周赛入围成员是否自动具备进阶赛资格。
  • 月赛是否要求成员在前置阶段个人积分大于零。
  • 黄金阶段是否要求来自秘蓝岛或月宫月赛的历史参赛成员。
• 成员资格锁定时间点。
  • 报名时锁。
  • 周六零点锁。
  • 公示结束锁。
  • 开战前五分钟锁。
• 赛季内跨俱乐部流动限制。
  • 已被锁定的成员能否退出并加入新俱乐部。
  • 跨服成员、临时成员、赛季中转服成员如何处理。
• 团长、副团长权限边界。
  • 仅报名可代理，还是选图、换图、成员锁定、资格确认都可代理。
• 资格继承与失效。
  • 俱乐部获得高级赛资格后，成员后续变动如何处理。
  • 俱乐部解散、被踢、重建后资格是否保留。

为什么重要：

• 这是最容易被越权、混入、替赛利用的区域。
• 这类规则客户端通常只展示“结果”，服务端必须单独定义完整校验链。

四、分组与匹配缺口 ¶

这一类缺口决定“和谁打”，会影响公平性与战区生成。

仍需补齐的信息：

• 每个岛的匹配池范围。
  • 按全服、百服、多赛季区间、同岛池还是同段位池分组。
• 战区生成方式。
  • 固定每组 20 个俱乐部，还是按可参赛俱乐部数动态切割。
  • 小于阈值的战区如何合并。
• 预备战场或候补战场是否仍保留。
  • 若保留，其与五岛赛制的关系如何。
• 选图机制。
  • 哪些阶段允许选图。
  • 选图失败、地图俱乐部数不足时如何重新分配。
• 黄金阶段分组。
  • 胜者组、败者组、总决赛是否使用固定 bracket。
  • 是否存在种子队、保送名额、历史高排名优先。

为什么重要：

• 客户端枚举能证明阶段存在，但无法自然推出完整分组算法。
• 分组算法会影响配置结构、数据库表、战场初始化参数。

五、地图与玩法映射缺口 ¶

这一类缺口决定“不同阶段到底开哪张图、用什么参数打”。

仍需补齐的信息：

• legionWarType -> legionWarMapType -> mapId 的完整映射表。
• 各地图的建筑配置、出生点、初始建筑归属、积分参数。
• 各岛是否允许共用同一运行时逻辑，仅替换地图与奖励。
• 黄金阶段是否仍是盐场据点战，还是部分阶段切成其他战斗规则。
• 特殊建筑规则。
  • 盐场核心、主城、炮塔、资源点在不同岛是否统一。
  • 占城积分、首占奖励是否按地图差异化。

为什么重要：

• 如果类型映射不完整，客户端即使能打开页面，也会拿到错误的战场数据。
• 这是配置解析和战场初始化的连接点。

六、协议与字段缺口 ¶

这一类缺口决定“服务端实际要返回什么”。

仍需补齐的信息：

• 报名、查战场、进战场、查排行、领奖、资格邮件等接口的完整字段集。
• 客户端是否隐式依赖以下信息：
  • 当前岛屿。
  • 当前阶段。
  • 是否晋级。
  • 是否已锁名单。
  • 是否拥有黄金联赛资格。
• 各阶段专属字段。
  • 黄金积分。
  • 岛屿积分。
  • 胜败者组标记。
  • 小组赛排名。
• 错误码口径。
  • 未入围、未报名、资格失效、阶段未开启、成员不在名单等错误是否已有稳定编码。
• 推送与广播。
  • 战场外资格更新是否需要实时推送。
  • 结算后是否推送晋级、淘汰、锁榜结果。

为什么重要：

• 客户端很多时候不靠独立接口名区分玩法，而是靠返回字段决定显示路径。
• 协议字段漏反推，后期会出现“页面能开但状态显示错乱”的问题。

七、持久化与快照缺口 ¶

这一类缺口决定“状态是否可恢复、跨周是否稳定”。

仍需补齐的信息：

• 俱乐部当前岛屿状态。
• 俱乐部当前阶段状态。
• 俱乐部本月累计积分与历史最好成绩。
• 黄金积分累计与锁榜快照。
• 参赛成员锁名单快照。
• 战场赛果来源。
  • 该俱乐部为什么进入当前阶段，是晋级、保级、保送还是回流。
• 胜者组/败者组分支状态。
• 奖励发放状态、邮件去重标记。
• 赛季重置策略。
  • 哪些状态按周清。
  • 哪些按月清。
  • 哪些按年清。

为什么重要：

• 伟大航路不是单场玩法，必须跨周、跨月、跨赛季追踪状态。
• 没有持久化模型，赛程就无法可靠恢复。

八、奖励与结算缺口 ¶

这一类缺口决定“怎么发奖、如何防重发”，也是运营高风险点。

仍需补齐的信息：

• 各阶段俱乐部排行奖励。
• 各阶段个人排行奖励。
• 首占奖励、晋级奖励、淘汰通知、资格邮件。
• 发奖时间点。
  • 比赛结束立即发。
  • 固定 22:00 发。
  • 锁榜后统一发。
• 发奖条件。
  • 个人积分必须大于零。
  • 必须是锁名单成员。
  • 比赛结束前仍在俱乐部内。
• 奖励幂等。
  • 多次结算是否可能重复发奖。
  • 邮件补发是否可能双发。
• 黄金积分与资格的结算关系。
  • 锁榜前积分如何持续累积。
  • 锁榜后是否冻结。

为什么重要：

• 奖励问题最容易形成线上事故。
• 这是服务端必须自己定义、不可能完全由客户端补全的部分。

九、安全与风控缺口 ¶

这一类缺口决定“即使功能做出来，是否会被刷、被绕、被重复执行”。

仍需补齐的信息：

• 重复报名保护。
• 重复进场和重放请求保护。
• 代报名越权保护。
• 非资格成员混入保护。
• 非当前阶段 battlefieldId 伪造进入保护。
• 奖励重复发放保护。
• 黄金积分锁榜后篡改保护。
• 跨服成员、历史成员、退团成员的资格污染保护。
• 配置非法组合保护。
  • 未开启阶段的 warType 与 mapType 被下发时如何拒绝。
• 灰度与部分开服保护。
  • 部分区服尚未到 S7，是否必须回退旧口径。

为什么重要：

• 这类问题不会在客户端文案里显式出现，但是真实实现里一定要补。
• 若不单独反推，最容易漏。

十、异常与恢复缺口 ¶

这一类缺口决定“出问题时系统怎么收敛”。

仍需补齐的信息：

• 战区人数不足时的补偿策略。
• 战场创建失败后的重试策略。
• 战场运行中断后的恢复策略。
• 报名成功但分组失败时的处理。
• 俱乐部解散或合并时的赛制状态迁移。
• 节点切换、跨服服务重启后的资格恢复。
• 赛季切换当天的数据修复脚本口径。

为什么重要：

• 这决定服务端是否能稳定上线，而不是只在理想路径可运行。

优先级建议 ¶

高优先级 ¶

这些缺口不补，无法开始正确实现：

1. 赛程编排缺口。
2. 晋级与降级缺口。
3. 成员资格与锁名单缺口。
4. 持久化与快照缺口。
5. 奖励与结算缺口。
6. 安全与风控缺口。

中优先级 ¶

这些缺口不补，会影响完整度和线上稳定性：

1. 分组与匹配缺口。
2. 地图与玩法映射缺口。
3. 协议与字段缺口。
4. 异常与恢复缺口。

低优先级 ¶

这些缺口可以在核心路径稳定后再继续补：

1. 运营灰度与部分开服细节。
2. 展示层附属邮件、称号、纪念性奖励。
3. 历史赛季数据兼容和追溯查询。

建议的下一步反推顺序 ¶

建议按以下顺序继续补资料：

1. 从规则文本中提取所有“时间、名额、同分、资格”硬规则。
2. 从客户端协议调用中拉齐所有涉及五岛、黄金联赛的接口和字段。
3. 从服务端配置中补全 warType / mapType / building config / reward config 映射。
4. 从服务端现有实现中确认哪些状态已经有存储模型，哪些仍是运行时临时值。
5. 单独产出一份“安全检查清单”，覆盖幂等、越权、伪造、资格污染、锁榜篡改。

与现有文档的关系 ¶

• 玩法流程证据见 gameplay-flow-evidence.md
• 反推总报告见 reverse-engineering-report.md
• 安全分析见 security-review.md
• 覆盖矩阵见 coverage-matrix.md

本文件是上述文档的补充，不替代既有结论，主要用于明确“还有哪些关键问题没有反推干净”。