Skip to main content

英雄携带阵容与战斗名额

本页管理局外选择哪些英雄进入候选池，以及它与战斗中英雄名额的关系。当前前端实现了 8 个携带槽位；战斗场上英雄上限仍是 5。飞书提出的“选择卡牌即占用名额”是另一个行为变更，不能因为 8 槽界面存在就推定整套选卡方案已完成。

槽位、解锁与有效阵容​

携带上限 RosterSlotCapacity=8，初始数量从 init_hero_num 读取（当前方案为 3），第 4—8 槽按 Function_open 对应的首通条件依次永久解锁。前端映射配置 ID 为 1002—1006，关卡条件来自配置，不硬编码关卡号。按连续前缀计算已解锁数；缺项视为锁定并记录告警，不能跳过缺项开放后槽。历史最高通关进度可恢复已解锁槽位，功能入口的 OpenMode 不代替槽位条件。

只允许放入已拥有且不重复的英雄，锁定槽不得放人。实际要求人数为 min(已解锁槽数, 已拥有英雄数)：拥有足够英雄时填满已解锁槽，拥有不足时全部携带；不能故意空位缩小候选池。校验先处理重复、未拥有、锁槽，再处理人数不足。提示使用已解锁数，不使用常量 8 或战斗上限 5。

携带槽顺序不指定战场站位，也不规定首波发卡顺序。阵容页展示已携带数/已解锁数，锁定格展示对应通关要求；模型与 UI 分别映射 8 槽，战场出生点仍只有 5 个。

编辑、保存和自动补位​

编辑草稿与已提交阵容分离。进入编辑后调整草稿；保存通过完整合法性检查后发 HeroBattle 请求，成功才写入提交态并退出，失败保留草稿。取消编辑丢弃草稿。当前响应为 NullResponse，客户端成功后复制所提交的 8 项列表，后续登录/重新加入用服务端数据覆盖；不应依靠未约定的服务端静默改写。

最新前端方案 §14 已采用自动补位，覆盖早期“解锁或获得英雄不自动补人”：登录发现新槽、胜利解锁、获得新英雄推送、手动激活英雄、取消编队编辑等时机，先保持已提交英雄与顺序，从未上阵的已拥有英雄中按品质降序、HeroId 升序填充已解锁空槽。拥有不足时填到全员；不替换已有英雄，不填锁定槽。编辑期间跳过，避免异步覆盖玩家草稿；无变更不发保存请求，有变更异步保存，失败回滚原快照。

升级或品质变化本身不重排已经保存的阵容。自动补位也不等同于“自动选最优阵容”。新手引导期间这些触发点与引导强制选人的交互尚需实际观察。

当前文档记录过编辑态返回问题：有修改但不合法的草稿可能无法经返回操作离开，F-B 未见本次运行证据。不要把“取消应丢弃”当作这个问题已解决。

玩法消费​

前端 BattlefieldHeroLimit=5。主线和材料关从携带英雄的卡牌召唤，战斗会话初始英雄集合为空，携带候选可以有 8 人但最终最多召唤 5 人。BOSS/竞技场现有开局铺人路径通过 BattlefieldRosterService 压缩取前 5 个非空携带英雄；独立保存的 BOSS/竞技场阵容 UI 和数据在所读方案中只是未来预留，不应称已上线。竞技场设计仍是开场固定 5 人，不套用主线首波选卡流程。

MainBattleEntryFlow 当前在非续战、非自动开始且已有非空阵容的条件下拦截编队不合法；没有自动跳转回编队页。阵容展示的“战力”部分调用实际上是主角攻击值，与换阵不必联动；完整数值口径见玩家等级、体力与战力。

选卡占名额方案（设计，尚不能确认为已实现）​

飞书《英雄上阵优化》要求第一波 5 张专属卡选 3 张，只从本局携带英雄生成。携带至少 5 人时五张不同；不足时均衡重复：1 人发 5 张，2 人为 3+2，3 人为 2+2+1，4 人为 2+1+1+1，多的一张随机分配。重复卡有各自实例 ID，不能被元素卡的去重规则删去。

玩家确认选卡即把对应英雄加入已承诺名单，不等拖拽召唤；重复选同英雄只占一次名额。有效上限为 min(5, 实际携带人数)，召唤物、陷阱和士兵不占英雄名额。已承诺但未召唤的卡拖到场上召唤 1 级英雄；英雄已存在则升级 1 级；两者均消费该卡。达到上限后名单永久锁定，本局不换人。

第二波起使用英雄专属与 12 张元素卡的权重池；轮转优先让尚未出现的携带英雄获得曝光。一次提供的未承诺英雄种数不得超过剩余名额。名额满后从未来候选池排除未承诺英雄；已持有的卡必然属于已承诺名单，因此不会出现“因名额满而丢弃手牌/退款”的补丁流程。

这一设计需要区分携带列表、已承诺集合、场上实体、剩余名额和卡牌实例五种状态，不能只拿场上数量过滤候选。8 槽实现阶段明确没有同时完成该锁定/发卡重构。

实现证据、差异与测试入口​

审计基线：前端 origin/develop@7f0636c9 的 Docs/Spec/hero-formation-8-slots-plan.md（完整方案及 §14）、HeroModel、槽位映射和战场阵容服务。后端 origin/master@88b24abe 的 model/hero/interface.go 已将 battleHeroNum 设为 8，handler/hero/hero.go 保存后返回 NullResponse。旧文档 §13 的服务端 5 位限制已不代表现状。

当前服务端检查请求列表长度不超过 8、非零 HeroId 已拥有且不重复；handler 拒绝零长度列表。所读两层没有检查进度解锁槽数或“必须填满/全部携带”，这些约束目前在前端与产品设计层更强。列表长度非零也不等于英雄非零数量大于零。需要区分服务端当前接受范围与界面允许范围，不能声称全部约束双端一致。

已存在 HeroModelTests、HeroFormationSlotMapperTests、ComHeroSpellSkillHandlerTests 和 Docs/HeroFormationGmCountCheck.md。本次仅整合已读证据，未执行这些入口，未新增或扩写测试，也未声明 GUI 通过。需要独立确认的边界包括：服务端保存 8 位、解锁后自动补位持久化、失败回滚、编辑取消、新手引导与选卡占名额设计。

来源依据​

  • 飞书 OAxdduMaGo7UkFxUdKjcOaG0nPe《英雄上阵优化》全部规则及状态设计；Fwq7sKHqghLqGOtk64qcpgednJd 的 3→5 历史布局已被 8 槽方案替代。
  • 旧 character-hero 编队规则迁入本页；不保留旧 5 携带槽作为另一运行模式。
  • 前端同一提交的 8 槽方案：采用后续 §14 自动补位结论；保留 §13 历史失败的证据性质，避免当作当前状态。