伟大航路安全复核 ¶

一、结论 ¶

这次反推里，最大的安全风险不是传统意义上的越权接口单点，而是“配置层与赛程层不一致导致客户端可见功能超前于服务端真实状态”。这类风险会让未完整实现的阶段被错误暴露、错误报名、错误进场、错误结算。

二、权限与身份绑定 ¶

1. 已观察到的安全正向证据 ¶

• 报名和进场已有资格校验
• 进场会重新解析角色与军团身份
• 重进时会清理跨军团残留队伍
• 观战态、玩家态和已淘汰态存在明确区分

2. 后续必须保留的要求 ¶

• 客户端上传的 roleId、legionId、battlefieldId 不能直接信任
• 任何需要“团长/副团长”的报名动作都必须重新做权限检查
• 任何“登岛成员”资格都必须由服务端判定，不能信任客户端本地缓存
• 队伍关系必须持续校验同军团与同阶段参赛资格

3. 高风险点 ¶

• 若未来为了赶功能，把部分资格判断只放客户端，会直接出现跨军团、跨岛屿、跨阶段参赛风险
• 若黄金资格锁榜时仍以实时俱乐部成员为准，而非锁榜快照，容易出现赛后换人

三、时间窗安全 ¶

1. 当前正向证据 ¶

当前进场逻辑已经会检查：

• 开放时间
• 准备时间
• 结束时间

2. 后续必须扩展的点 ¶

伟大航路需要的不只是“比赛是否开始”，还包括：

• 报名期
• 公示期
• 可提前进场期
• 战斗进行期
• 结算保护期
• 锁榜冻结期

如果继续只使用单一周赛时间窗模型，将导致：

• 月赛、总决赛错误开放
• 已结束场次仍可补操作
• 锁榜后还能影响资格或积分

四、重放、并发与幂等 ¶

1. 已观察到的正向证据 ¶

• 结算存在加锁意识
• 行军、战斗、攻建筑均有 runtime 广播与完成路径

2. 必须明确的幂等点 ¶

后续实现必须显式保证这些操作幂等：

• 报名
• 进入战场
• 发起行军
• 完成行军
• 发起 PVP
• 发起攻建筑
• 结算
• 发排行奖励
• 发俱乐部奖励
• 发黄金资格奖励/邮件

3. 高风险点 ¶

• 多连接重放导致重复报名
• 多 worker 重复结算导致重复发奖
• 网络重试导致重复占点或重复积分

五、排行、结算与奖励完整性 ¶

1. 服务端必须独立计算 ¶

这些值不能依赖客户端上传：

• 个人积分
• 俱乐部积分
• 排名结果
• 晋升/淘汰结果
• 黄金积分
• 是否有领奖资格

2. 需要特别防护的场景 ¶

• 个人积分为 0 的成员是否发奖
• 本赛季已绑定其他俱乐部的成员是否发奖
• 天宫总排行奖励是否只发一次
• 锁榜后是否还能通过换成员影响黄金资格

六、配置安全 ¶

1. 当前已暴露风险 ¶

配置中存在：

• 多个 legionWarType
• 多个 legionWarMapType
• 第二赛季起点

但调度层仍固定输出单一旧值。

2. 这意味着什么 ¶

若客户端已能展示某阶段，而服务端没有完整运行时支持，会出现：

• 能看到规则页但不能安全报名
• 配置切图了但结算仍按旧阶段
• 建筑配置切换了但赛程和奖励没有切换

3. 必须增加的保护 ¶

• 服务端必须有“阶段是否真正开放”的硬开关
• 未完成的阶段即使有配置，也必须拒绝进入和报名
• 不支持的 legionWarType + legionWarMapType 组合必须明确报错

七、部分开服与灰度风险 ¶

伟大航路是天然的多阶段系统，最怕“只开一半”：

• 只上地图，不上资格与结算
• 只上黄金积分，不上资格锁榜
• 只上规则页，不上赛程
• 只上月宫地图，不上月宫月赛晋升

因此后续实现必须支持：

• 阶段级关闭
• 地图级关闭
• 奖励级关闭
• 安全兜底拒绝返回

不能因为客户端已有入口，就默认服务端必须接受请求。