上一篇：开放世界玩家载具驾驶 P9：碰撞、损伤与失控恢复——车辆如何在受损后继续保持可恢复性
P8 讨论驾驶命令如何进入物理世界，P9 讨论碰撞与损伤如何返回运行时。本篇继续处理另一个经常被简化的问题：当车辆仍然承担路线执行、转向和速度控制时，车内乘员如何同时瞄准、射击、操纵炮塔或完成其他交互？
引言：车辆运动与车内交互不共享同一条任务生命周期
在开放世界中，车辆行驶时的车内交互通常不会暂停驾驶。驾驶者需要保持车辆沿道路前进，乘员可能同时观察目标、调整武器方向、进行射击、切换武器，或者在任务脚本的约束下完成特定动作。玩家看到的是一个连续场景：车辆向前移动，镜头跟随车身转动，准星指向道路侧方的目标，武器在合适的时间发射，车辆仍然按照驾驶输入改变方向。
从运行时角度看，这个场景至少包含四组同时变化的状态：
- 车辆的路线、速度、转向和物理反馈；
- 角色的座位、姿态、武器和上半身动作；
- 目标的实体、位置、速度和可瞄准状态；
- 任务、脚本和表现层对当前交互的约束。
当这些状态由同一个任务或控制器直接修改时，职责冲突会迅速累积。瞄准动作可能覆盖转向输入，车辆转弯可能使准星突然跳转，乘员切换座位时武器状态可能仍然保留，炮塔旋转又可能与角色动画使用不同的方向来源。
本篇关注的并非新增射击功能，而是：
驾驶执行与车内交互如何在同一辆车上并行存在，并在必要时共享状态、分别提交控制。
本文将车内战斗理解为一个并行运行时。它拥有独立的交互意图、命令窗口、状态推进和结果反馈，但不取代车辆运动控制，也不继承车辆任务的全部生命周期。
文中“车内玩家状态路由器”“目标服务”“车载武器执行器”“炮塔执行/关节层”等名称，均是为了便于公开讨论而采用的职责别名，不表示源码中存在同名、单一或常驻对象。源码事实、架构抽象和迁移启示会分别说明。
一、车辆运动与车内交互的并行关系
车辆进入车内战斗状态后，最容易出现的误解是：系统把车辆从驾驶任务切换到了战斗任务。对于开放世界车辆，这种切换通常过于粗糙。车辆可以继续行驶，乘员可以独立瞄准，车载武器可以拥有自身的朝向和冷却状态，任务还可能要求车辆保持某一条路线或速度范围。
车内战斗首先表现为既有车辆运行时中的并行消费路径；驾驶任务仍然维持车辆运动。
图中两条链分别维护车辆运动和车内交互；它们通过座位关系、车辆能力与任务约束交换状态，但不直接接管对方的执行职责。
当前车辆运动控制链继续维护推进、转向和制动语义；它的来源可以是玩家、AI、脚本或恢复任务。车内交互链只提交属于角色武器、固定武器或炮塔通道的请求，其作用域不延伸到路线清空或车辆执行器替换；后两者仍由运动控制域和命令仲裁层维护。
车内战斗的五类职责
在源码阅读中，需要把“战斗”拆成五类职责，而不是三个纵向控制对象：
第一是交互意图。它回答角色、乘员或脚本希望瞄准、开火、装填、投掷或退出当前武器状态。这个意图通常来自玩家输入、任务指令或固定脚本，不等于实际已经发生了射击。
第二是交互提交资格。它回答当前来源是否仍然拥有座位、模式和任务许可，以及武器、炮塔和目标是否满足提交条件。
第三是状态所有权。角色武器、固定车载武器和炮塔可能分别维护不同的持续状态，座位关系和车辆能力则提供横向约束。
第四是动作执行。角色姿态、炮塔关节和发射执行分别将已接受的请求转换为具体动作。动作执行不负责重新选择目标，也不负责替换驾驶命令。
第五是结果事实。弹药变化、投射物生成、命中、冲量、损伤和表现反馈属于执行结果；这些结果可以被任务、镜头和表现层消费，但不应反向充当交互意图的唯一来源。
五类职责之间存在关联，但“状态所有权”不是一次请求生命周期中的阶段。它在请求建立之前已经存在，在请求结束之后也可能继续存在。更准确的表达应当拆成两部分：
结果事实还需要继续区分：提交先产生投射物、弹道和弹药变化，随后可能产生命中事实，命中再由损伤系统转化为持续状态。损伤并不总是本次武器执行器直接拥有的即时结果。
这条链与 P3 的驾驶命令形成并行关系。P3 的驾驶命令负责车辆运动，车内战斗命令负责乘员或车载武器交互。两条链都可能读取车辆状态，但各自只提交本领域的请求，不承担对方的控制职责。
二、车内玩家状态：交互入口与关系路由
源码入口通常从玩家已经处于车辆座位的状态开始。这个入口需要判断当前角色是否仍在驾驶、是否正在乘坐、是否请求退出、是否进入武器模式、是否需要切换到炮塔或投掷物分支。
这类入口最适合抽象为“车内玩家状态路由器”。它的职责是选择当前应该运行的上层分支，而不是亲自实现全部驾驶、瞄准和射击逻辑。
路由器需要处理的状态变化
一个稳定的车内路由至少要观察以下变化：
- 驾驶者或乘员身份是否仍然有效；
- 当前座位是否仍然允许使用武器；
- 当前车辆是否具备对应的武器或炮塔；
- 玩家是否产生瞄准、射击、装填或投掷意图；
- 当前目标是否仍然有效；
- 车辆是否处于损伤、失控、等待物理或任务限制状态；
- 当前武器分支是否已经完成、取消或被更高约束打断。
路由器不能将“开火输入”直接解释为“立即发射”。输入需要先进入相应的控制器、目标服务和武器模式任务，再由下层确认执行资格。
● 为什么不能让车辆任务直接读取玩家输入
如果车辆侧每帧直接读取玩家输入，会出现三个问题。
第一，AI 或脚本控制的车辆无法复用同一套交互入口。若车辆侧任务直接绑定本地玩家，其他控制源就必须重新实现一套路径；录制与回放只应在后续阶段复用已经定义的交互契约。
第二，玩家输入与武器资格被混在一起。玩家可以产生射击意图，但座位可能不允许射击、武器可能尚未完成加载、车辆可能处于禁用状态。输入读取者只负责保存意图，座位、武器模式和车辆能力分别承担准入判断。
第三，控制源边界会被绕过。玩家、AI、脚本和恢复任务需要通过各自的命令窗口提交运动意图；运动链只消费当前被接受的命令，不直接判断本地设备状态。
更稳定的组织方式是：运动来源先产生运动意图，交互来源产生交互意图，车内状态路由器选择交互分支，当前任务确认提交资格，武器或炮塔执行器提交实际请求。
三、瞄准、目标与武器执行
玩家视角中的准星方向、角色上半身的朝向、武器枪口方向和车辆炮塔方向并不必然相同。它们可能在同一时间拥有不同的角度、延迟和约束。
因此，瞄准系统至少需要维护三个层次：
逻辑瞄准方向
逻辑瞄准方向来自控制视图、准星和玩家输入。它描述玩家希望观察或指向的位置，是目标查询与瞄准意图的输入。摄像机可以提供观察基准，但镜头震动、脚本过渡和表现偏移只属于表现侧状态，不能直接成为炮塔或弹道的事实。
● 角色武器方向
角色武器方向受到座位、身体姿态、骨骼、武器握持和可旋转范围约束。角色可以看向一个目标，但手臂和枪口未必能够在当前动作阶段立即对准该目标。
● 车辆武器或炮塔方向
炮塔方向由车辆武器组件、炮塔关节、俯仰和水平旋转限制共同决定。对于固定朝向的车载武器，允许方向可能更窄；对于可旋转炮塔，系统还需要处理转速、初始朝向、旋转加速度和座位控制权。
逻辑瞄准方向、目标解算、部件方向和最终枪口方向之间需要经过多层转换：
这种结构也解释了为什么目标服务不能只是保存一个实体指针。目标服务需要维护锁定实体、自由瞄准位置、目标速度、发射偏移和目标失效后的回退方向。
目标服务：维护目标事实，而非决定任务结果
在车内战斗中，目标状态经常先于武器状态发生变化。目标可能离开视野、进入遮挡、离开可锁定范围、切换载具，或者因为网络更新延迟而暂时没有有效位置。
目标服务应当提供稳定的目标抽象，而不是把目标丢失直接解释为战斗失败。
● 目标服务的基本输入
目标服务可能读取：
- 当前摄像机射线或准星方向；
- 玩家锁定状态；
- 目标实体的位置与速度；
- 目标的骨骼、车辆座位或可命中部位偏移；
- 当前武器的发射偏移；
- 目标是否可见、可锁定或可攻击；
- 当前任务对目标的约束。
● 目标服务的输出
它可以输出：
- 当前目标实体；
- 当前目标位置；
- 经过发射偏移修正的位置；
- 目标是否发生变化；
- 目标是否暂时无效；
- 目标是否需要重新选择；
- 目标状态是否需要同步。
目标服务只维护目标事实和目标状态。一个目标暂时不可见，可能只需要继续搜索；一个目标离开射程，可能需要车辆保持路线；一个任务目标被销毁，才可能触发持有该目标的任务进入下一状态。
● 目标位置为什么需要偏移
射击位置通常不能直接使用实体原点。角色、车辆和大型载具都有不同的命中区域，武器也可能从枪口、炮管、侧舱或车体固定点发射。目标服务需要把逻辑目标转化为适合当前武器的目标位置。
这类偏移还可能与目标速度有关。对于移动目标，系统可能根据速度和预测时间修正目标位置；对于低速车辆、步行目标或远程玩家，修正规则也可能不同。公开文章无需复述每一个具体公式，但应保留一个关键边界：目标选择、目标位置修正和武器发射不属于同一职责层。
四、驾驶、瞄准与控制权的分离
驾驶控制和瞄准控制的输入维度不同。驾驶主要消费纵向推进、制动、转向和车辆模式；瞄准主要消费视角方向、目标选择、射击和武器模式。两者可以同时有效，但并不意味着两者拥有相同的优先级或修改范围。
驾驶控制的稳定约束
当前车辆运动控制链继续消费：
- 当前运动命令或局部目标；
- 推进、制动和转向语义；
- P7 的即时约束；
- 车辆能力限制；
- P8 的物理反馈与损伤约束。
车内战斗的局部约束
武器任务则需要确认：
- 乘员是否位于可用座位；
- 武器是否允许在当前座位使用；
- 当前目标是否有效；
- 当前瞄准或开火状态是否满足准入条件；
- 车辆运动、损伤或任务状态是否限制射击；
- 武器是否处于装填、冷却或切换阶段。
两者的交集主要发生在车辆状态读取和执行资格判断处，而不是通过互相覆盖任务来实现。
并行命令窗口如何衔接
在一次运行时更新中，可以观察到类似的处理关系，但它不是源码中固定的全局执行顺序：
- 运动控制域取得当前路线、速度、车辆能力和物理反馈；
- 交互控制域取得当前交互来源、目标、模式和座位关系；
- 两条控制域分别形成运动请求和交互请求；
- 各自执行器依据本域资格提交动作；
- 物理、武器和表现系统返回结果事实；
- 任务与状态层消费反馈，并更新下一次命令窗口。
这里的“分别提交”并不意味着系统完全隔离。武器发射可能产生后坐力、冲量和声音；车辆损伤可能限制武器旋转；驾驶状态可能改变角色姿态和镜头。但这些影响应通过明确的状态和反馈通道传播，而不能由某个交互任务直接写入全部车辆状态。
不同车内交互的执行分支
源码阅读中经常会把所有“车内开火”归为同一个任务，这是不准确的。至少可以区分三类运行时路径。
● 乘员持枪或侧向射击
这一类通常由角色座位和武器任务共同完成。角色需要处理上半身动作、枪械状态、瞄准方向、射击节奏和座位约束；车辆继续执行驾驶任务。枪口位置和目标位置与角色骨骼、车辆运动和镜头方向有关。
● 车内投掷物或特殊武器
投掷物通常拥有不同的蓄力、释放和弹道逻辑。它可能暂时覆盖角色上半身动作，但不应自动覆盖车辆运动。车辆的路线、速度和转向仍由车辆侧执行器维护。
● 炮塔或固定车载武器
炮塔武器拥有自己的朝向、旋转限制和物理控制。乘员输入或任务意图需要先进入车载武器任务，再由炮塔执行器解释。炮塔的旋转方向不等于角色身体方向，炮塔的发射资格也不等于角色已经完成瞄准动画。
三者可以共享目标服务、武器控制器或准入语义，但各自仍需保留独立的运动解释。共享的是控制意图和生命周期契约，不是具体的瞄准或发射控制律。
五、炮塔：动画、目标与物理接缝
炮塔是车内战斗中最容易产生层级混乱的部分。它同时涉及乘员动作、目标方向、炮塔关节和武器发射。若只把炮塔理解为一个旋转组件，就会忽略它与座位和任务的关系。
● 动画层
乘员需要根据炮塔或目标方向完成手部、身体、头部和躯干动作。站立式炮塔可能需要先完成初始调整，再允许连续旋转；乘员在转向、闪避、受击或座位切换时，动画任务还需要中断或重新建立。
● 武器层
车载武器任务维护瞄准、开火、锁定、冷却和武器状态。它可以根据目标方向生成炮塔控制请求，也可以在座位无效、武器无效或目标状态不满足时拒绝建立发射请求。
● 炮塔执行 / 关节层
炮塔执行或关节层负责将期望方向转化为真实的部件运动。它需要处理旋转速度、角度限制、碰撞和惯性。执行反馈可能反过来影响武器是否具备发射资格，但不因此取得目标选择或任务完成权。
因此，炮塔控制可以抽象为：
这个过程需要角色任务、武器任务和执行层共同完成；武器任务不能绕过物理约束直接写入最终姿态。
● 初始调整与持续转向
炮塔进入战斗状态时，初始方向可能与摄像机或目标方向存在较大偏差。系统需要先完成初始调整，再进入持续转向。初始调整期间，武器可能允许显示瞄准意图，但暂时不允许发射；等炮塔进入可接受角度后，武器任务再获得完整的发射资格。
持续转向阶段还需要维护：
- 当前水平和垂直角度；
- 目标方向变化；
- 最大旋转速度；
- 转向加速度或阻尼；
- 目标丢失后的回中或保持；
- 乘员动作与炮塔方向的同步。
这解释了为什么“准星已经指向目标”不代表“炮塔已经可以发射”。逻辑瞄准方向、目标解算、期望部件方向、实际炮口方向和物理执行资格之间存在时间差。
六、座位关系与权限边界
P1 已经区分了座位位置、座位占用、驾驶者身份和命令提交权。车内战斗继续依赖这组关系，但增加了武器权限和交互权限。
一个座位可能具备以下状态：
- 允许驾驶；
- 允许乘坐；
- 允许侧向射击；
- 允许使用固定武器；
- 允许控制炮塔；
- 允许切换武器；
- 允许在车辆移动时执行动作。
这些权限不宜合并成一个 CanUseVehicle 布尔值。驾驶座可能允许驾驶但不允许使用某类武器；炮塔座可能允许控制车载武器但不允许退出到普通乘员动作；后排乘员可能允许侧向射击，却不能修改车辆运动。
座位变化如何影响战斗状态
换座、下车、被拉出、受击和死亡都可能改变当前交互关系。系统需要决定：
- 当前瞄准目标是否清除；
- 当前武器任务是否结束；
- 当前发射请求是否取消；
- 炮塔是否回到默认方向；
- 驾驶命令是否继续；
- 其他乘员是否获得武器控制权。
座位关系变更不能只表现为删除角色引用，再由武器任务自行判断。变更需要向角色任务、车辆武器任务、目标服务和表现层传播，并为每个消费者提供明确的结束条件。
驾驶者、乘员与车载武器的权限矩阵
“谁在控制”需要拆成多个问题：谁提出车辆运动意图，谁提出交互意图，谁判断座位与模式资格，谁保存武器状态，谁解释并执行动作，以及谁产生世界结果。驾驶权与武器权可以属于不同角色，也可以在任务阶段之间迁移。
| 问题 | 责任主体 |
|---|---|
| 谁提出车辆运动意图 | 玩家、AI、脚本或恢复来源 |
| 谁提出交互意图 | 玩家、AI 乘员或任务脚本 |
| 谁判断座位与模式资格 | 座位关系、交互任务与能力条件 |
| 谁保存武器状态 | 角色武器或车辆固定武器系统 |
| 谁解释并执行动作 | 角色武器、固定武器或炮塔执行器 |
| 谁产生世界结果 | 投射物、物理、命中与损伤系统 |
| 谁确认网络状态 | 后续权威与复制路径 |
例如，驾驶者可以继续提交车辆运动意图，乘员提交交互意图，任务限制炮塔角度，车辆能力状态拒绝实际发射；这些结果不需要由一个“最终控制者”统一拥有。
交互来源与镜头反馈
玩家输入只是车内战斗的一个来源。AI 乘员、脚本任务和车辆自动武器逻辑也可能产生交互请求。它们需要进入同一套意图和准入路径，而不是各自直接修改武器。网络或回放可以在后续阶段复用这套交互契约，但不在本文展开为新的本地意图来源。
● 玩家来源
玩家来源通常提供：
- 瞄准方向；
- 锁定或自由瞄准状态；
- 开火、持续开火和释放开火；
- 装填、换武器和投掷意图；
- 视角模式和镜头辅助状态。
● AI 来源
AI 乘员通常提供：
- 目标实体；
- 射击时机；
- 目标优先级；
- 武器模式；
- 允许的射击角度与距离。
● 脚本和任务来源
脚本可以要求车辆在特定时间执行开火、保持炮塔方向、关闭武器或等待动画完成。任务来源还可能对射击产生条件约束，例如不得误伤、必须等待目标进入区域或只能在车辆稳定后开火。
这些来源不直接竞争同一个武器字段。较稳定的方式是：来源提交候选意图，当前任务和权限规则决定候选是否有效，武器执行器再根据状态生成最终动作。
● 镜头反馈与交互状态
车内镜头同时承担驾驶反馈和战斗反馈。驾驶镜头需要表现速度、转向、碰撞和车身姿态；战斗镜头需要表现准星、目标、后坐力、炮塔方向和命中反馈。
如果每个系统都可以直接替换摄像机，玩家会看到镜头在驾驶视角、瞄准视角、炮塔视角和受击镜头之间产生不稳定跳转。较稳定的结构是让不同系统提交镜头请求，再由镜头协调层按照当前模式和任务约束合并。
● 镜头反馈的来源
- 车辆运动状态；
- 当前驾驶座或武器座；
- 瞄准模式；
- 炮塔方向；
- 开火和后坐力；
- 碰撞与损伤；
- 任务脚本和过场镜头。
镜头读取这些状态，但不承担驾驶或武器权威。镜头中的准星位置不能反向证明炮塔已经完成物理旋转，镜头震动也不能替代碰撞事实。
损伤状态对车内战斗的能力限制
P9 已确认的车辆能力变化会继续影响车内交互。对于具备独立车载武器部件模型的载具，还可能存在炮塔转动能力或供弹能力受限；这些状态是否由原版单独维护，需要结合对应部件的写入者和消费路径继续核验。发动机或车体状态变化也可能通过车辆能力集合间接影响交互。
能力限制的不同结果
- 发动机受限：车辆速度和路线执行受影响，但乘员可能仍可瞄准；
- 炮塔旋转受限：目标仍然存在，武器也可能可用，但当前方向不可达；
- 车体严重损坏：乘员可能进入受击或撤离流程；
- 武器系统失效：驾驶继续，武器任务进入等待或终止；
- 驾驶者失效：车辆运动控制源需要重新分配，乘员武器状态不一定同步结束；
- 车辆运动和固定车载武器通常需要等待物理表示重新具备执行资格；乘员手持武器是否暂停，还取决于座位、角色表示和当前交互模式。
能力限制应通过结构化反馈传递给车内战斗任务。例如“当前炮塔方向不可达”“武器系统冷却未完成”“座位关系失效”“物理执行资格暂不可用”，比统一返回 false 更容易被上层正确处理。
异常路径与恢复
完整系统不能只描述瞄准成功、武器发射和命中目标；以下失败路径同样构成运行时语义：
● 目标失效
目标退出范围、死亡、隐藏或进入不可攻击状态时，目标服务清除或降级目标。武器任务可以保持搜索，也可以结束当前瞄准，但不直接宣布车辆任务失败。
● 炮塔未就绪
炮塔资产、物理关节或座位动画尚未完成加载时，武器任务应进入等待。等待不等于武器损坏，也不等于任务完成。
● 权限失效
乘员换座、下车、死亡或任务撤销后，当前射击权限失效。已有发射请求需要取消或完成清理，避免角色已经离开座位后仍继续提交武器命令。
● 车辆运动受限
车辆进入失控、严重损伤或物理等待状态时，武器任务可能仍能保存目标和意图，但必须根据执行资格决定是否延迟发射、限制炮塔或结束当前交互。
● 武器任务结束
换武器、装填失败、脚本取消、目标完成和乘员退出都可能结束当前武器分支。结束时需要清理瞄准目标、镜头请求、动画状态和炮塔临时标记；待提交的远程状态属于后续同步系统处理范围。
七、源码阅读与职责验证
阅读车内战斗代码时，不宜从“搜索所有射击函数”开始。更可靠的入口是观察可见行为：车辆保持移动时乘员开始瞄准，炮塔完成初始调整后允许开火，目标暂时丢失后继续搜索，角色离开座位后武器分支终止，或者损伤状态限制炮塔方向。
沿着这些行为，可以建立以下职责表：
| 观察到的行为 | 可能的职责层 | 需要核对的状态 |
|---|---|---|
| 车辆保持路线和速度 | 驾驶执行层 | 路线、控制源、物理反馈 |
| 玩家进入瞄准状态 | 玩家武器路由层 | 输入、座位、武器模式 |
| 目标位置持续更新 | 目标维护层 | 实体、偏移、速度、失效 |
| 炮塔转向目标 | 车载武器执行层 | 角度、速度、座位权限 |
| 角色身体跟随炮塔 | 车内动作层 | 座位、动画网络、姿态 |
| 武器发射 | 武器与物理接缝 | 准入、冷却、弹道、冲量 |
| 车辆受损后限制射击 | 能力状态层 | 部件状态、执行资格、恢复 |
源码中的任务名称可以帮助定位，但不能替代职责分析。某个任务可能只是路由器，另一个任务可能才是车辆侧执行器；某个武器组件可能拥有目标查询，却不拥有任务终止；某个动画任务可能反映炮塔状态，却不拥有炮塔方向。
源码证据、架构抽象与迁移推断
本文公开表达的三种结论需要区分：
第一类是在已追踪的车内状态路径中可以观察到的事实：玩家车内状态会选择驾驶、普通武器、投掷物和车载武器等不同分支；车辆侧会根据载具类型安装不同的玩家驾驶执行任务；炮塔动作路径会读取座位、目标和动画网络状态。具体结论仍应回到任务创建入口、分支条件、状态写入点和消费路径核对。
第二类是职责抽象，例如把角色侧入口归纳为状态路由器，把车辆侧的多种玩家驾驶任务归纳为共享生命周期、类型专用执行器，把目标位置维护归纳为目标服务。
第三类是迁移推断，例如在目标引擎中建立并行的驾驶与交互层、将炮塔控制拆成目标方向与物理执行两层、为损伤反馈提供结构化能力结果。这些是根据机制推导出的设计建议，不应写成原实现唯一可能的形式。
八、并行交互的时序、冲突与提交
前面的职责拆分如果只停留在名词层面，仍然容易被理解成“车辆有一套驾驶系统，武器再挂一套射击系统”。实际运行时更接近一条连续事件链。下面用一个抽象场景说明这些关系如何在同一段时间内被维护。
车辆沿城市道路行驶，驾驶者保持当前车道并接近路口；副驾驶发现侧前方目标，进入瞄准状态；目标服务根据镜头方向和车辆姿态更新目标位置；武器任务检查座位权限、弹药和发射条件；如果车辆发生轻微碰撞，P9 所述的损伤反馈会改变车辆的执行资格，但不必然取消武器任务。这个过程中，任何一个状态都可能先于其他状态发生变化。
例如，乘员刚完成瞄准，目标从建筑物后方消失。目标服务首先将目标标记为暂时不可见，武器任务不应继续使用上一帧的命中点无限期发射，而应根据锁定策略进入短暂保持、重新搜索或取消状态。与此同时，车辆仍然可以沿路线前进，驾驶执行器继续消费驾驶命令。目标失效只影响交互分支，不应把车辆整体切换为停止状态。
反过来，如果车辆突然发生较强冲击，车身姿态、座位状态和武器可用性可能同时变化。物理系统先产生碰撞事实，损伤层更新已确认的车辆状态，车辆运行时再把结果转换为“允许继续移动”“限制转向”“暂时禁止发射”或“进入失控恢复”等能力状态。武器任务消费的是能力结果，而不是直接读取每一个碰撞字段。这样，损伤系统可以改变射击资格，却不需要知道准星、目标服务和弹道执行的内部细节。
这段场景包含四组可能不同步的推进关系：
- 车辆运动按当前命令窗口持续推进；
- 目标服务按感知与查询结果推进；
- 武器任务按瞄准、装填和发射阶段推进；
- 任务脚本按事件和条件推进。
它们不要求拥有相同的更新节奏，也不共享同一个结束条件。驾驶任务可能因抵达目标或失去执行资格而结束；瞄准任务可能因目标失效、玩家松开输入或座位变化而结束；脚本任务则由事件条件推进。各自的命令窗口和结束条件清晰，运行时才具备并行基础。
同一辆车上的三种“继续”
“继续驾驶”“继续瞄准”和“继续任务”不是同一个判断。车辆可能继续移动，但当前目标已经不再可攻击；武器仍然可以发射，但任务已经要求车辆离开交战区域；任务仍然有效，但损伤状态暂时禁止发射。将这些判断压缩为一个 CanContinue 类似的总开关，会导致局部失败扩散到整辆车。
更稳妥的方式是将能力拆成多个可消费的结果：移动资格、转向资格、瞄准资格、发射资格、换座资格和任务继续资格。它们可以由共同的车辆状态产生，但由不同的消费者解释。车辆运行时维护事实和能力，具体任务决定如何使用这些能力。
这种拆分也解释了为什么“武器已装备”不能直接等价于“武器可发射”。装备描述静态关系；发射还需要满足当前座位、当前模式、目标状态、冷却、弹药、碰撞安全、脚本许可和车辆部件状态。每一项都可能在不同阶段被撤销，因此发射必须是一次经过条件确认的提交，而不是对武器对象调用一个无条件动作。
并行交互中的冲突与责任归属
并行系统最容易出问题的地方，不是正常状态，而是多个消费者同时提出互相矛盾的请求。车内战斗至少存在三类冲突：空间冲突、控制冲突和语义冲突。
● 空间冲突：座位与武器占用同一组关系
乘员要使用侧向武器，首先必须占据允许该武器工作的座位；炮塔操作员需要获得炮塔控制权限；驾驶者需要继续保留驾驶席关系。座位关系因此不只是角色附着位置，也决定了哪些交互通道可以建立。
当乘员换座、被击倒或执行离车动作时，武器任务不应自行推断座位已经失效。更可靠的路径是由座位关系发布状态变化，武器任务订阅或查询当前资格，并在下一次提交前重新确认。这样，座位系统仍然是关系所有者，武器系统只是关系消费者。
● 控制冲突：玩家输入与任务约束同时存在
玩家可能持续按住开火键，但任务脚本正在要求车辆驶离区域；玩家可能尝试转动炮塔，但炮塔正处于初始对准或换座动画；AI 乘员可能拥有自动开火策略，而玩家正在切换控制模式。“最后写入者覆盖前一个值”并不能解决这类冲突，因为写入顺序只反映时间顺序，不反映职责和权限。
冲突需要在命令形成和任务许可之间解决。输入层可以记录玩家意图，目标层可以提供可攻击对象，任务层可以提供限制，武器执行层再依据当前模式生成可执行请求。某个请求被拒绝时，原始输入不必被伪装成不存在；它可以保留为输入状态，等待条件恢复后重新评估，或者在模式切换时明确清空。
● 语义冲突：同一个动作在不同模式下含义不同
“按下攻击键”可能表示普通射击、车载武器发射、炮塔开火、投掷物释放或任务专用操作。若输入系统直接向每种武器发送硬编码事件，模式变化会产生大量分支，并且很难说明谁拥有当前动作。
较稳定的做法是让上层提交模式无关的动作意图，再由当前武器模式、座位关系和车辆类型选择解释路径。意图层不负责决定枪口位置、炮塔角度或弹道；执行层也不重新读取整套玩家输入。两者之间需要一个足够小、足够明确的契约。
● 冲突处理的责任归属
可以把冲突处理分成三层：
第一层确认“谁有资格提出请求”，主要涉及座位、控制源和任务状态；第二层确认“请求在当前模式下是否有意义”，主要涉及目标、武器模式和脚本约束；第三层确认“请求是否能够执行”，主要涉及部件状态、冷却、弹药和物理限制。每一层都只能拒绝或修改自己负责的部分，不能越级重建整辆车的状态。
这一点对调试尤其重要。如果车辆仍然移动但武器没有发射，应当能够区分：玩家没有获得武器命令提交权、目标服务没有提供有效目标、武器模式拒绝发射、炮塔尚未完成对准，还是损伤系统撤销了执行资格。一个总的“攻击失败”状态无法承担这样的诊断任务。
车载武器的生命周期：从交互到提交
车内战斗不能简化为“瞄准后调用发射”。从运行时角度，至少存在几个具有不同所有者的阶段：交互请求建立、武器模式确认、目标信息更新、瞄准姿态收敛、执行资格确认、发射提交和结果反馈。
交互请求建立时，系统需要确认玩家或 AI 是否正在操作允许的座位，以及当前车辆模式是否接受这一类请求。武器模式确认时，需要决定当前使用的是普通乘员武器、固定车载武器还是炮塔系统。目标信息更新时，目标服务提供方向、位置、速度或锁定状态。瞄准姿态收敛时，动画或物理执行器把目标方向转换为角色、武器挂点或炮塔所需的姿态。
发射提交前还需要进行一次最终检查。目标可能在上一查询周期后已经失效，座位可能发生变化，车辆可能进入禁止开火的损伤状态，炮塔可能因为物理约束无法到达目标方向。这个检查不是重复计算，而是防止异步状态在最后一步造成错误提交。发射提交成功后，结果再返回到弹药、伤害、音效、镜头和任务事件等消费者。
● 瞄准状态与发射状态的分离
瞄准可以持续存在而不产生发射。玩家可能调整准星、等待目标进入视线、等待炮塔完成转向，或者使用瞄准状态触发镜头和动画反馈。发射是一个离散提交，受到冷却、资源和许可约束。把两者合并，会迫使系统用“正在瞄准”作为“可以开火”的近似条件，最终表现为武器提前发射、目标改变后仍沿用旧方向，或在炮塔尚未就绪时丢失输入。
在源码阅读中，如果能够观察到目标更新、瞄准姿态和发射任务分别拥有自己的状态推进，就不应把它们重新抽象为一个“战斗控制器”。它们的关联关系很强，但职责仍然不同。文章公开表达时，可以描述为“瞄准链”“发射链”和“反馈链”，而不必暴露具体实现类名。
● 车载武器的提交语义
车内战斗中的“开火”不能只用一个布尔状态表达。为区分输入边沿、持续状态、执行资格和不可逆结果，本文采用四个职责阶段：
Fire Intent 可以来自一次按下、持续按住或 AI 的射击策略；它描述来源的愿望。Fire Request 是经过当前模式和目标上下文组织后的请求，仍然可能被座位、损伤、冷却或炮塔状态拒绝。只有执行器返回接受后，才进入 Fire Commit。弹药消耗、投射物创建和任务事件等不可逆结果，应与提交保持一致。
这一区分也适用于固定武器和炮塔。炮塔尚未完成初始调整时，可以继续保留 Fire Intent，也可以在模式规则下丢弃它；但不能把已经过期的输入事件无限期延迟到炮塔到位后自动补发。持续开火则在每个命令窗口重新评估，释放事件负责关闭当前持续请求。
| 输入形态 | 语义 | 适合的生命周期 | 延迟后是否可继续消费 |
|---|---|---|---|
| 按下开火 | 边沿事件 | 生成一次交互意图 | 只在短暂有效窗口内 |
| 持续开火 | 持续状态 | 保持重复请求的意图 | 条件恢复后重新评估 |
| 释放开火 | 结束事件 | 关闭当前持续请求 | 不能作为新的开火请求 |
| 蓄力投掷 | 分阶段状态 | 开始、保持、释放分别确认 | 每个阶段都要检查来源和资格 |
| 装填或换武器 | 任务请求 | 由对应任务推进 | 由任务决定是否排队或取消 |
这一区分可以避免两个相反的问题：把一次按下事件保存过久，导致炮塔完成转向后补发一枪；或者把持续开火当作一次事件，使自动武器在条件恢复后无法继续评估。输入层保存的是来源意图，武器任务决定意图能否转化为请求，执行器决定请求能否进入提交阶段。
● 车载武器的结果不只包括伤害
一次提交可能产生多个结果：弹道或投射物创建、枪口与挂点校正、弹药消耗、后坐或车辆扰动、镜头反馈、音频反馈、目标命中事件和任务事件。它们不一定由同一个对象完成，也不一定在同一帧完成。武器任务提出意图并组织请求，执行器返回接受或拒绝，具体结果由相应执行器和物理系统产生。
这也是“武器任务不等于武器物理”的原因。任务负责何时允许提交、选择什么模式和保持什么状态；执行器负责如何生成投射物、如何施加方向和如何接受物理反馈。将两者混合，短期内可以减少接口数量，长期会让任务状态和物理状态互相覆盖。
● 炮塔、动画与物理的三条接缝
固定车载武器和炮塔系统会把并行问题进一步放大。炮塔既有可见的转动动作，也有目标方向和物理约束；角色还可能需要在座位上保持姿态；武器发射又要求炮口方向和目标状态一致。一个“炮塔角度”字段无法同时代表这些层次。
动画层关注角色与部件的可见姿态。它可能需要流式加载动作资源、完成初始对准、进入持续转动、处理转向过渡以及在结束时恢复普通姿态。动画层可以暂时阻止发射，或者向武器层提供“姿态已经就绪”的状态，但不应直接决定目标是否有效。
目标与武器层关注的是交互语义：当前是否存在攻击目标、是否允许锁定、是否可以发射、是否已经完成一次射击。它需要知道炮塔当前的有效方向，但不必管理动画资源的加载状态。
炮塔执行或关节层关注真实部件的旋转、约束、碰撞和反馈。它可能由物理关节、运动学部件、动画与骨骼驱动，或由混合约束共同实现。源码若只体现角度、速度、限位和反馈，不足以进一步断言一定存在完整的物理炮塔实现。该层拒绝某个方向请求后，应返回可消费的能力反馈，而不应直接清空上层任务的全部目标状态。
源码阅读中可以通过三个问题识别这条接缝：谁更新角色或炮塔的可见姿态，谁维护目标与发射状态，谁写入真实旋转或物理部件。如果三个答案落在不同的状态推进逻辑中，就应保留它们之间的边界。这样，在迁移到其他引擎时，可以分别替换动画、目标和物理实现，而不必重新设计车内战斗的整体生命周期。
异常生命周期：目标、炮塔、座位与车辆能力变化
在开放世界中，异常状态会频繁出现：目标被遮挡、乘员更换座位、武器资源尚未加载、车辆受到冲击、任务被中断，或者驾驶者突然失去控制。车内战斗需要把这些情况作为正常生命周期的一部分，而不是只在测试阶段补救。
● 目标短暂消失
目标消失不等于目标永久失效。目标服务需要区分暂时不可见、超出查询范围、被遮挡和实体已经销毁。武器任务可以根据模式选择保持最近状态、重新获取目标或立即终止。不同结果会影响准星、镜头、炮塔和任务事件，但不应影响车辆本身的驾驶循环。
● 炮塔暂时未就绪
炮塔可能正在加载动作资源、完成初始对准、等待物理部件恢复或处于转向限位。此时目标仍然存在，玩家输入也仍然有效，但发射资格暂时关闭。输入可以被保留为当前意图，也可以根据武器模式丢弃；关键在于系统必须明确这一选择，而不是把“未发射”错误解释为“玩家没有输入”。
● 乘员被迫离开座位
座位关系改变后，目标服务和武器任务都需要停止消费原来的座位权限。若角色进入倒地、跳车或任务转移状态，系统应先撤销交互资格，再处理动画与表现，避免下一帧仍然通过旧引用提交发射。车辆驾驶状态可以继续，也可以进入任务指定的暂停或恢复路径；两者不应因为座位变化而无条件相互销毁。
● 车辆进入不可战斗状态
损伤或任务规则可能禁止武器使用，但仍允许车辆移动；也可能同时限制转向、速度和乘员交互。此时应更新能力集合，而不是直接删除武器任务对象。能力恢复后，任务是否重新激活取决于其生命周期和恢复策略。保留任务状态可以避免每次短暂失效都重建目标、镜头和动画关系。
源码证据：创建、更新、消费与结束
车内战斗的源码分析容易被单个命名吸引。看到某个函数包含 Fire、Aim 或 Turret，并不能证明它拥有整个战斗系统。更可靠的方法是沿着四类证据追踪：创建、更新、消费和结束。
创建证据回答“谁在什么条件下安装了这段任务或状态”；更新证据回答“状态在哪个周期被推进”；消费证据回答“谁读取了目标、权限或能力结果”；结束证据回答“任务为什么停止、恢复或交给下一个来源”。如果只找到创建而没有更新，可能只是包装层；只找到发射调用而没有目标和权限检查，可能只是执行器；只找到动画状态而没有武器提交，可能只是表现侧子任务。
还需要记录状态写入者，而不是只记录字段名称。目标位置由谁写入，炮塔角度由谁写入，发射资格由谁撤销，座位变化由谁广播，车辆损伤由谁转换为能力限制，这些问题比类名更能说明所有权。对于匿名化公开文章，使用职责名称替代具体类名也更安全，因为读者真正需要的是关系结构，而不是私有符号表。
源码事实、架构抽象与迁移推断
源码直接体现的行为，可以用“从调用关系可以观察到”“该状态由某一侧更新”表达；跨函数和跨模块的职责归纳，应使用“可以抽象为”“表现出一层”表达；面向 UE5 或其他目标引擎的迁移建议，则应明确标注为“迁移启示”，不能回写成原版实现事实。
尤其要避免把“适合迁移”的结构写成“原版必然如此”。例如，玩家状态路由、车辆交互桥接和类型专用执行器是有价值的目标架构抽象，但它们不等于原始代码中一定存在同名接口。文章的可信度来自证据与推断的分层，而不是来自更强的断言。
● 请求快照与过期检查
车内战斗的很多问题都发生在“查询”和“提交”之间。目标服务查询时目标仍然存在，武器任务准备发射时座位关系已经变化；炮塔开始转向时车辆仍处于可战斗状态，提交发射时损伤系统已经撤销了执行资格。如果系统只在交互开始时检查一次条件，异步更新就可能让旧结果越过新的状态边界。
因此，发射请求需要一个足够小的有效性快照。它不必复制整个车辆对象，只需要描述本次请求的上下文：交互来源、座位关系、武器模式、目标事实、车辆能力和交互代次。提交时将快照与当前状态比较，任何关键上下文发生变化，都可以拒绝旧请求并触发重新查询。这里的“版本”是迁移设计中的组织方式，不应反写成源码中已经存在完全相同的字段集合。
重要的是，交互请求不能只携带一个“我想开火”的布尔值，而要能够回答：这次请求属于哪个控制源、针对哪个目标、在什么座位关系和车辆能力下生成。否则，延迟返回的目标、重复消费的输入和过期的任务状态都会被误认为当前事实。
● 控制源变化必须有可追踪的提交序号
车辆在移动时可能经历 AI 驾驶、玩家驾驶、脚本动作和恢复任务的连续交接。车内战斗也会发生类似变化：玩家接管武器、任务暂时锁定武器、乘员自动开火、脚本强制停止交互。交互代次可以用于使旧控制源的迟到请求失效；这里强调的是生命周期语义，而不是断言源码采用某一个具体字段。
一个可靠的交互状态至少需要区分当前控制源、当前命令窗口、当前交互代次和最后接受的提交序号。控制源释放时，不一定要立即销毁所有目标和表现状态，但必须使旧提交失效。新控制源建立后，系统可以沿用允许继承的目标上下文，也可以要求重新建立瞄准状态；这取决于交互模式，而不是由某个通用任务默认决定。
这与 P4 的控制源交接是一致的：释放的是提交资格，保留或清理的是状态内容。玩家暂时释放开火输入时，目标关系不必随之删除；任务暂时接管时，旧玩家输入也必须失效。交互状态的保留、失效和恢复需要分别建模。
● 输入快照、目标快照和物理反馈不是同一种数据
输入快照描述“当前来源希望做什么”；目标快照描述“当前交互针对什么对象”；物理反馈描述“世界实际发生了什么”。三者在一帧中可能互相矛盾：玩家希望继续发射，目标已经失效，物理层报告炮塔被限位。系统不能用任意一项覆盖另外两项。
输入快照可以继续存在，等待下一次条件确认；目标快照需要在过期后重新查询；物理反馈则必须进入能力评估，决定本次请求是延期、拒绝还是转换为另一种可执行状态。把物理反馈直接写回输入，会让玩家意图丢失；把输入直接写回物理，会让失败状态被覆盖；把目标快照视为永久事实，则会产生向过期目标开火的问题。
对源码阅读而言，这提供了一个实用的辨别方法：如果一个状态结构同时保存玩家输入、目标实体、炮塔姿态和物理结果，就需要进一步确认它是临时聚合快照，还是错误地承担了多个所有者。一个短生命周期的请求对象可以聚合这些信息用于一次提交；但持久系统仍应分别拥有各自的事实。
多消费者模型能够避免的实现错误
架构抽象的价值不只是解释已有代码，也在于它能够预测错误。下面几类常见故障，都可以从职责边界被破坏来解释。
● 故障一：驾驶输入被武器模式吞掉
如果车辆内的所有输入都先进入武器任务，再由武器任务决定是否转发给驾驶系统，那么瞄准、装填或射击状态可能错误地改变车辆运动。更严重的情况是，武器任务结束时没有恢复驾驶消费者，导致车辆保持上一帧的速度或方向，表现为输入失效。
正确的职责关系应当是：输入路由根据当前角色状态产生多个可消费意图；驾驶消费者消费移动相关意图；交互消费者消费瞄准和开火相关意图。二者可以共享输入快照，但不共享对方的生命周期。某个交互模式独占瞄准输入，不等于它拥有油门、制动或车辆路线的所有权。
● 故障二：镜头转向直接改变炮塔方向
在第一人称或肩后视角中，镜头方向通常会影响瞄准方向，但镜头本身还承担车辆运动反馈、碰撞反馈、座位视角和表现过渡。如果武器直接读取最终摄像机旋转并把它写入炮塔，镜头脚本、车辆姿态修正或震动就可能被错误解释为玩家瞄准意图。
更稳定的链路是先从控制视图得到逻辑瞄准意图，再结合车辆坐标、座位挂点、目标查询和炮塔约束生成武器方向。镜头可以消费相同的方向结果用于反馈，但不应成为唯一的权威来源。这样，镜头切换或过场镜头可以改变表现，却不会无意中驱动物理炮塔。
● 故障三：炮塔未到位时仍然发射
如果目标服务提供了目标点，武器任务就直接调用发射执行器，炮塔初始调整和物理转向会被当作异步细节。结果是视觉上炮口尚未对准，弹道却从目标方向生成；或者物理组件拒绝转向，但武器任务已经扣除弹药。
这类错误要求发射提交拥有明确的“姿态就绪”条件。目标有效只是必要条件，方向可达、组件可用、当前权限有效和发射资源足够同样必要。执行器拒绝后，弹药消耗和任务事件应当遵循提交顺序，不能在执行失败之前提前写入不可逆结果。
● 故障四：车损后整车任务被清空
车辆受到冲击后，如果损伤处理直接销毁所有车内任务，驾驶、瞄准和任务脚本会同时失去状态。玩家可能只是遭遇一次轻微碰撞，却被迫重新建立座位、目标和武器模式；或者车辆已经能够恢复移动，但车内交互永远不会回来。
更合理的方式是由车辆状态生成能力限制，再由各消费者解释。轻微损伤可能只影响发射稳定性，中度损伤可能限制炮塔角度，严重损伤才终止车载武器任务。驾驶任务是否继续、目标是否保留、镜头是否切换，都应该根据各自的恢复规则处理。
● 故障五：离车后武器残留在旧角色上
离车涉及座位释放、控制源关闭、镜头迁移和任务恢复。如果武器任务只在开火阶段检查座位关系，而没有在交互生命周期结束时清理提交权，就可能出现角色离车后仍能向旧车辆提交射击，或者重新上车后收到上一段交互残留的目标状态。
座位关系的版本和交互代次可以用于阻止这类迟到请求。离车不必销毁所有表现对象，但必须关闭旧控制窗口；重新进入后，应根据新的座位关系和模式建立新的交互提交上下文。
不同车内交互形式的统一解释
车内交互不只有一种形式。乘员侧向射击、车顶武器、炮塔操作、投掷物、车辆自带武器和任务脚本操作，在表现上差异很大，但可以使用同一组问题进行分析。
第一，交互由谁提出？是驾驶者、乘员、AI 角色、任务脚本，还是车辆自身的自动逻辑。第二，请求绑定在哪个关系上？是角色与座位、角色与武器，还是车辆与固定部件。第三，请求需要什么目标信息？自由瞄准、锁定目标、路径点和脚本指定位置的约束不同。第四，最终由谁执行？是角色动作、普通武器、固定武器、炮塔物理部件，还是特殊投射物。第五，失败后保留什么？输入、目标、任务、弹药和表现状态不一定同时清除。
用这组问题分析不同交互，可以避免“把所有武器都接到车辆控制器”的倾向。共享的是交互生命周期和资格检查，专用的是目标解释、姿态约束和执行方式。汽车上的乘员武器不需要船舶的浮力模型，炮塔也不应复制普通角色武器的手臂瞄准逻辑；但它们都需要处理来源、目标、权限、执行和反馈。
● 乘员侧向射击
这类交互的核心约束是角色与座位关系。角色动作需要与车身、车门、窗口和座位挂点保持相对关系，武器方向还要受到车身运动和视线的影响。车辆可以继续驾驶，乘员动作与射击任务在车内并行推进。
它的执行结果通常由普通武器链完成，车辆只提供位置、姿态、遮挡和运动反馈。因而不能把乘员武器直接归入车辆驾驶任务；驾驶任务只需要提供车身状态和相关能力，武器链仍然维护自己的瞄准和发射生命周期。
● 固定车载武器
固定武器与车辆具有更强的实体关系，武器挂点、车辆朝向和车辆损伤都可能影响发射资格。玩家或 AI 提供的是交互意图，车载武器执行器负责把它解释为固定挂点上的方向与发射动作。
固定武器不一定需要独立炮塔，但仍需要明确目标服务、武器模式和车辆部件之间的接缝。特别是车辆发生部件损坏时，某一侧武器可能失效，而整辆车仍然能够移动或使用其他交互。
● 炮塔与可旋转部件
炮塔增加了一个持续的姿态收敛过程。目标方向不是瞬间变成物理角度，炮塔需要处理转速、限位、初始对准、部件关系和碰撞约束。角色动作还可能需要表现操作过程，但动画不拥有真实炮塔的最终方向。
因此炮塔场景最能体现本篇的核心：驾驶、目标、动画、武器和物理各自拥有局部状态，车辆运行时负责维持它们的关系，而不是把所有内容合并为一个大任务。
工程迁移启示：先保留关系，再实现表现
虽然本篇不进入 UE5 实现篇，但源码阅读可以给出迁移顺序。第一步不是制作炮塔模型或绑定输入，而是确定座位、控制源、目标、武器模式和车辆能力之间的关系。第二步建立可观察的状态变化，让“为什么没有发射”“为什么炮塔没有转动”“为什么驾驶仍然继续”能够分别回答。第三步再接入动画、镜头和物理表现。
迁移时最容易犯的错误是先建立一个“车辆战斗组件”，把所有输入、瞄准、炮塔和射击代码放进去。这样做可以很快看到效果，却会让车辆驾驶、角色武器和车载武器共享一个无法拆分的生命周期。后续加入 AI、脚本控制和损伤状态时，组件内部会出现大量互相覆盖的条件。
更稳妥的目标是保留四个边界：车辆运行时提供持续状态和能力；角色或玩家路由提供交互来源；目标服务提供目标事实；武器与炮塔执行器负责解释和提交。镜头、动画、音频和任务事件在边界外消费结果。这个结构并不要求复制原始源码的类层级，但能够保留源码阅读中观察到的责任分布。
迁移验证也应从异常场景开始，而不是只测试“按下开火键后产生投射物”。至少需要验证：驾驶期间瞄准是否保持；目标失效后是否能继续驾驶；炮塔未就绪时是否拒绝发射；损伤限制是否只影响相关能力；换座后旧请求是否失效；离车后 AI 或任务是否能够恢复；重新进入后是否建立新的交互代次。只有这些场景可解释，车内战斗才真正成为开放世界车辆运行时的一部分。
与前后篇的边界
P9 关注碰撞、损伤、失控与恢复。本篇读取 P9 的能力变化结果，并说明这些结果如何限制瞄准、武器和车内动作；但不重新展开损伤归因和恢复状态机。
本篇不展开追逐和逃逸中的动态控制权。车辆追逐可能改变驾驶目标、攻击规则、多人协同和策略选择，这些属于下一篇的核心问题。
本篇也不展开网络同步与回放协议。它们只在边界上被保留：本地交互意图不等于权威结果，过期请求需要能够被拒绝；具体的克隆、回放、远景和多载具延续留到系列末篇。
因此，当前系列链条可以整理为：
结语：车内战斗不是暂停驾驶，而是增加一组受约束的控制消费者
驾驶、瞄准和车内战斗能够同时存在，依赖的不是一个更大的车辆控制器，而是职责边界的保持：驾驶任务继续维护车辆运动，车内交互任务维护乘员和武器状态，目标服务维护可瞄准对象，炮塔执行器解释方向与物理约束，镜头和表现层消费状态反馈。
车辆因此可以在持续移动、损伤受限、目标变化和乘员交互之间保持同一身份。车内战斗并不会自动获得整辆车的控制权；它只能在座位、任务、目标、武器和物理资格都满足时，提交属于自身范围的交互请求。
车内战斗的核心不是让乘员在车辆中开火，而是让驾驶、瞄准与武器执行在同一辆持续运行的车辆上保持并行而不互相越权。
AI 协作复盘
本篇的 AI 协作主要用于整理车辆玩家控制、座位武器、炮塔动作、目标服务和车内任务的源码阅读笔记，并将它们映射到“驾驶执行—交互路由—目标维护—武器执行—物理反馈”的职责链。
AI 初稿最容易产生三类偏差：把车内战斗误写成驾驶任务的替换；把目标位置服务写成武器执行器；把炮塔动画、炮塔物理和武器发射压缩成一个控制器。人工复核时，按照任务创建位置、状态更新阶段、字段写入者和结束条件逐项核对，并将源码事实、架构抽象与迁移建议分开。
本篇尚未进入 UE5 实现篇，不展开具体组件、接口或物理 API。后续落地文章再依据这些职责边界建立可验证的并行控制原型。