伟大航路客户端资格与积分字段补充 ¶
文档目的 ¶
本文件专门整理客户端中已经暴露出的“资格、锁名单、岛屿积分、总积分、晋级名额”字段。
目标不是再讲一遍玩法流程，而是回答：
- 服务端至少要下发哪些字段，客户端才能正常显示。
- 哪些字段明显需要落库，而不是临时运行时计算。
一、客户端已经依赖的核心字段 ¶
从客户端数据结构和 UI 逻辑看，伟大航路至少依赖以下几类字段：
- 当前岛屿
- 当前阶段
- 当前阶段是否可进场
- 当前阶段是否已锁成员
- 小组积分
- 总积分
- 小组排名
- 晋级名额
- 青铜岛动态晋级轮次
- 黄金是否已淘汰
这些字段分散在 LegionService.getInfo、战场查询、积分排行、黄金排行等多个接口里。
二、俱乐部基础赛制字段 ¶
来源：
客户端从 LegionService.getInfo 读取到的赛制相关字段至少包括：
islandTypeexWeekRiseDateisInExWeekisInExMonthisInExGoldMonthemLegionWarMapmapList
这些字段会被传给：
exWarData.initData(isOpenExWar, exWeekRiseDate, isInExWeek, isInExMonth, isInExGoldMonth, emLegionWarMap, mapList)exLeagueWarData.initData(n)
结论：
- 服务端并不只是返回“当前 warType”，而是已经向客户端暴露了岛屿和阶段环境字段。
- 其中
islandType是客户端计算当前大阶段的直接依据。
三、当前岛屿字段 ¶
来源：
客户端直接使用 islandType：
- 决定当前处于灰、青铜、秘蓝、月宫、黄金哪个阶段
- 决定读取哪套月赛/周赛提示文案
- 决定晋级名额展示逻辑
结论：
- 服务端必须持久化“俱乐部当前所在岛屿”。
- 这不是 UI 衍生值，而是阶段判断核心输入。
四、战场基础资格字段 ¶
来源：
客户端战场信息 GDBattlefieldInfo 至少包含：
phasetypesubTypelegionWarMapTypesignupStartTimesignupEndTimereadyTimestartTimeendTimebattlefieldIdbattlefieldNumbercanEnterWarsiddomainName
其中最关键的资格字段是：
canEnterWar
客户端会把它保存到 LegionWarModule._canEnterWar，并用于：
- 控制能否进入比赛
- 控制黄金阶段“锁成员”提示
- 控制各类操作按钮显示
结论：
- 服务端必须明确区分“俱乐部在该场次里”与“当前角色可进场”。
canEnterWar显然是按角色粒度生效，而不是俱乐部整体布尔值。
五、锁成员/登岛成员语义 ¶
来源：
黄金阶段 _isLockedMembers 的判断为：
- 当前是比赛日
- 当前杯位
opList[0]存在 opList[0].selfId.length > 0!canEnterWar
对应提示文案：
C_WAR16:赛事限本俱乐部登岛成员参与
这说明客户端实际上区分了三层语义：
- 当前俱乐部是否在这场比赛里
- 当前角色是否属于该场比赛的锁成员/登岛成员
- 当前角色是否有进场权限
结论：
- 服务端至少要有“锁名单快照”或等价资格表。
- 仅靠
battlefieldId和legionId不足以表达资格。
六、小组排名与总积分字段 ¶
来源：
客户端排行对象 GDSaltRoadWarMsg 至少包含：
sRGScoreArrsRBScoreArrsRKScoreArrsRTotalScoresRConfIdsRGroupRanksRGoldenOut
排行响应还包含：
riseNumblueRiseRound
其中：
SaltRoad_GetSaltRoadWarGroupRankResplegionListselfRankInforiseNum
SaltRoad_GetSaltRoadWarTotalRankResplegionListrankCntselfRankInforiseNumblueRiseRound
客户端在积分排行页直接显示：
sRTotalScorerank- 是否晋级 / 淘汰图标
结论：
- 服务端至少要给每个俱乐部保留：
- 小组积分数组
- 总积分
- 小组名次
- 总榜名次
- 当前阶段晋级人数
riseNum
七、积分数组字段的含义 ¶
客户端虽然没有把 sRGScoreArr / sRBScoreArr / sRKScoreArr 注释写清，但结合字段命名和页面用途，可以高可信判断为：
sRGScoreArr- 绿色/周赛阶段积分序列，或分周积分序列之一
sRBScoreArr- 蓝色/阶段积分序列之一
sRKScoreArr- 关键赛段或月赛/黄金赛积分序列之一
sRTotalScore- 当前展示口径下的累计总积分
这部分仍然属于“字段语义待完全确认”，但至少可以确定：
- 客户端预期拿到的不只是一个单值总分。
- 客户端支持展示一组积分历史或分段积分。
结论：
- 服务端设计持久化时，不应只留一个
total_score，还应考虑阶段性积分明细。
八、晋级名额字段 ¶
来源：
客户端不是把晋级人数写死在页面里，而是从接口或配置组合读取：
riseNumblueRiseRoundblueRiseCount
它们分别解决不同问题：
riseNum- 当前这一页或当前这一阶段的直接晋级线
blueRiseRound- 青铜岛升秘蓝岛动态轮次
blueRiseCount- 客户端当前赛程环境中用于切档的值
而 blueRiseCount 来自：
读取赛程配置项的：
thirdLegionWarType_2_count
结论：
- 服务端不能把“晋级线”看成单一常量。
- 至少青铜岛的总榜晋级线，存在“随黄金联赛开启前月赛开展次数而变化”的动态口径。
九、灰盐岛晋升名单字段 ¶
来源：
客户端有单独接口：
saltroad_getgreyriselegions
响应：
SaltRoad_GetGreyRiseLegionsResplegionList
结论：
- 灰盐岛“周赛 -> 进阶赛”的晋升名单不是完全内嵌在通用排行榜里，至少客户端已经为它预留了单独查询能力。
- 服务端后续应考虑独立的晋升名单查询或缓存。
十、阶段资格切换字段 ¶
来源：
客户端会根据这些条件播放“阶段提升”提示：
lastDateLegionWarTypelegionWarTypecheckWarDay()
并识别这些变化：
greyWeek -> greyWeekHighgreyMonthgreenMonthblueMonthpurpleMonthgoldenVictorgoldenFinal
结论：
- 服务端必须持久化上一场比赛类型和当前比赛类型，客户端对“升段动画”和“结果展示”有明确依赖。
十一、客户端能直接证明的资格规则 ¶
从文案和字段联合看，目前能直接证明：
- 周赛报名时锁成员名单。
- 锁定成员不可代表其他俱乐部参赛。
- 月赛成员要求：
- 入围对应前置比赛时有参赛记录
- 且个人积分大于
0 - 且到月赛当天指定时间仍在俱乐部内
- 黄金阶段有限定“登岛成员”的资格控制。
这些证据分布在：
结论：
- 服务端资格模型至少要覆盖：
- 报名锁名单
- 月赛资格成员
- 黄金登岛成员
- 个人积分大于零的资格筛选
十二、服务端最少应落库的字段集合 ¶
如果只按客户端当前依赖，服务端最少应考虑持久化：
-
俱乐部维度
island_typecurrent_war_typelast_war_typegroup_ranktotal_ranktotal_scoregroup_score_breakdownrise_numblue_rise_roundgolden_outbattlefield_idbattlefield_typebattlefield_map_type
-
成员维度
is_locked_memberis_ex_month_qualifiedis_golden_island_membercan_enter_warlast_qualified_war_datelast_qualified_personal_score
-
赛程维度
exWeekRiseDateisInExWeekisInExMonthisInExGoldMonthmapList
十三、仍待确认的字段语义 ¶
客户端虽然暴露了这些字段，但还有几块语义没有 100% 闭合：
sRGScoreArr / sRBScoreArr / sRKScoreArr的精确业务定义blueRiseRound与blueRiseCount的区别和服务端来源关系mapList中是否还承载“选图结果”或阶段地图开放信息isInExGoldMonth在黄金天宫和黄金联赛之间的边界含义
十四、结论 ¶
到这一步，客户端已经足够反推出一套比较明确的服务端字段契约：
- 不仅有阶段和地图
- 还有资格、锁名单、总积分、小组积分、晋级人数、动态轮次、黄金淘汰状态
也就是说，后面服务端真正要补的，不再只是“战场怎么开”，而是“这些资格和积分字段如何生成、如何持久化、如何保持幂等”。
评论
请登录后发表评论。
暂无评论。成为第一个评论者！