简介一套完整的红蓝对抗训练可视化系统支持陆地空战与海洋海空联合对抗两种模式内置武器配置、实时得分显示、训练启停与数据回放等模块面向军事仿真、兵棋推演及人工智能方向的开发者。资源包含完整前后端代码后端基于Python 3.8与Flask提供API及对抗引擎前端采用HTML、JavaScript、CSS构建可视化界面可直接运行于Anaconda环境。压缩包共44个文件主要为11个Python源码、7个HTML页面、5个JavaScript脚本、10个pyc缓存及2个SQLite数据库另附5个文本说明与设计文档整体仅356KB。已有83人学习下载。解压后可按目录结构快速定位后端API、数据模型、对抗引擎、前端模板及数据存储训练数据以数据库形式保留支持历史对局查询与回放配套的环境配置、启动说明、数据库设计等文档能帮助用户在本地顺利搭建并二次开发。1. 红蓝对抗可视化系统到底长什么样兵棋推演从桌游变成实时大屏红蓝对抗、兵旗推演在很多单位里已经从沙盘和纸质箭头变成了系统对抗。这套系统是当年花五千块找外包做的定制项目前后端完整、直接能跑支持陆地空战与海洋海空联合对抗两种模式。它解决的问题很具体训练前怎么编排红蓝双方兵力训练中怎么在屏幕上看到实时态势训练后怎么把过程导出来逐帧复盘。相比那些只做数据录入的演练平台它把“对抗”本身做了可视化不是画个地图摆几个图标而是把单位轨迹、交战事件、状态变更都串成一条时间线。适合做仿真训练、战术推演、方案评估的团队拿来二次开发也适合想研究“实时可视化系统怎么搭”的人直接读代码。2. 架构拆解前后端分离、双战场模型与一条 WebSocket 数据专线2.1 前后端分离的边界业务接口和实时通道不能混这套系统用的是典型的前后端分离结构后端负责训练场景的创建、兵力编组、事件记录前端负责地图渲染和交互操作。拆开代码后最直观的感受是后端接口分了两个方向一类是普通的 REST 接口处理训练管理这类低频率操作另一类专门给实时态势用的 WebSocket 通道。两条链路在代码里从路由层就分开互不干扰。这种做法是对的。训练管理接口要返回的是结构化数据比如参演单位列表、对抗条件设置请求频率低但数据量大用 HTTP 很合适。而实时态势是高频小数据包红蓝双方每个单位的位置、状态、事件都需要持续推送如果走轮询接口地图刷新页面会很卡还会把请求日志刷得没法看。我拆这套系统的时候专门数过它请求频率最低的业务接口和 WebSocket 消息的频率差距差不多是几个数量级的差别这也是很多可视化系统翻车的分水岭把实时数据混在业务接口里到对抗规模一大后端线程池直接被打满。前端这边用的是 Vue 加地图组件库路由控制页面切换WebSocket 被封装成一个独立的模块统一管理连接状态。后端是 Python 写的 FastAPI 服务配合 Redis 做短期的实时状态缓存、MySQL 做训练记录和回放数据的持久化。选型上没有特别冷门的东西胜在结构清楚每一条数据链路都能从代码里找到入口和出口。2.2 陆地空战和海洋海空联合对抗同一套引擎两套规则表系统最核心的区分点在规则层。陆地空战和海洋海空联合对抗虽然都在同一张地图上跑但两者的“空间维度”和“单位属性”差异很大。陆地空战里地面单位的位置主要靠二维坐标表达高度信息只在空中单位上体现交战的判定逻辑要处理地形遮蔽、射程衰减这些因素。而海洋海空联合对抗就不一样了舰艇要表达航向、航速、阵位空中单位要表达飞行高度、航线、预警范围还要把水面、水下、空中三层态势叠在一起看。如果硬用一套位置表结构去兼容两边后面扩展规则时改动会非常痛苦。这套系统处理得比较聪明它把战场对象拆成“单位基类”加“规则模板”。基类里只有通用的字段比如单位标识、阵营、经纬度、时间戳具体的属性被放进规则模板里陆地空战加载陆战模板海空联合加载海战模板。模板里定义了可用的字段集合和事件类型前端地图拿到单位数据后根据模板类型决定显示什么图标、渲染什么图层。这样设计的结果是新增一种训练模式时不需要改底层数据结构只需要新增一套规则模板然后在训练创建接口里指定模板编号。从二次开发的角度看这个边界很友好。如果你想扩展空天一体或者陆海联合作战最低成本的路径就是复制一份现有模板改字段表里的事件类型和单位枚举而不是去动序列化层或者地图渲染层。2.3 目录结构清单哪些是核心模块哪些只是页面壳拿到完整的项目压缩包之后第一步别急着跑先花十分钟把目录结构看清楚。这套系统的文件组织虽然不是标准脚手架生成的但模块边界很清楚。目录职责是否核心frontend/src/views页面组件训练管理、实时态势、数据回放三大页面核心frontend/src/map地图封装单位图层、轨迹线、事件标记核心backend/app/apiREST 接口训练 CRUD 用常规backend/app/wsWebSocket 消息处理实时推送通道核心backend/app/service对抗逻辑、规则判定、回放记录核心backend/app/utils时间处理、ID 生成、数据校验工具sql初始化脚本必备页面的部分实际上不复杂登录、训练列表、大屏展示、回放查看。复杂度都沉淀在地图模块和 service 层里。我看到很多接手这类项目的人一上来就去改前端页面样式结果改完发现数据不动原因就是没找到 service 层里数据组装的那一段。建议先从后端 service 入口读起理清一个训练从创建到结束经过了哪些方法再回去看前端地图绑定了哪些事件整个系统就串起来了。3. 训练管理对抗编组、想定加载与 300 毫秒刷新链路3.1 对抗编组与想定加载后端如何把红蓝双方写入同一张战场图打开训练管理页面核心操作是创建一个对抗训练场次然后选择陆地空战还是海空联合模式再把红蓝双方的参演单位填进去。这套系统把这一串动作收敛成了一个 “训练创建 单位批量导入” 的接口组合。前端把编制表提交到后端后端生成一个训练 ID并把这个 ID 作为所有后续数据的关联主键。下面这段是后端创建训练核心逻辑的简化版保留了最关键的编组和数据初始化动作# backend/app/service/training_service.py async def create_training(train_type: str, red_units: list, blue_units: list): # train_type 区分陆空对抗还是海空联合对抗从规则模板表读取配置 rule_config get_rule_template(train_type) session_id generate_session_id(train_type) # 写入训练主表statusinited 表示已创建还未开始 insert_training_record({ session_id: session_id, train_type: train_type, status: inited, rule_template: rule_config.version }) # 红蓝双方单位全部写入同一张单位表用 camp 字段区分 for unit in red_units blue_units: unit[session_id] session_id unit[camp] red if unit in red_units else blue insert_unit_record(unit) # 初始化实时快照把单位初始位置推入 Redis后续前端读的是这份快照 init_snapshot(session_id, red_units blue_units) return session_id逻辑上要说明两个点。第一红蓝双方不是分开存两张表而是写入同一张单位表靠camp字段区分。这样做的好处是查询一次就能拿到全部参演单位的坐标方便地图渲染时按阵营过滤颜色不用做表连接。第二init_snapshot这一步很关键它把单位的初始位置放进 Redis 里的一个实时集合中。前端地图首屏加载时请求的是这个快照而不是直接查数据库。参数层面train_type是系统的开关直接决定了后面加载哪套规则模板status字段用了 inited 状态说明创建和开始是两件事实际开始对抗时要再调用一个开始接口把状态切到 running。这样设计的好处是编制有问题时可以在开始前撤回修改不用删掉重建。3.2 WebSocket 实时链路推模式比定时器更像战场对抗过程中的实时可视化靠的是 WebSocket。这套系统在后端维护了一个连接管理器每个训练 session 对应一组订阅了该 session 的客户端连接。后端把单位位置、事件消息推送到这组连接上前端负责渲染。前端地图默认的刷新节奏是 300 毫秒一批这个数值是在地图渲染效率和数据及时性之间折中出来的。前端连接和重连的逻辑是这样处理的// frontend/src/map/socketClient.js let socket null let reconnectTimer null export function connectRealtime(sessionId, onMessage) { const protocol location.protocol https: ? wss : ws const url ${protocol}://${location.host}/ws/train/${sessionId} socket new WebSocket(url) socket.onopen () { // 连接建立后发送订阅消息后端根据 sessionId 加入对应推送组 socket.send(JSON.stringify({ type: subscribe, sessionId })) } socket.onmessage (event) { // 收到的是批量位置帧减少解析次数比减少包大小更重要 const frame JSON.parse(event.data) onMessage(frame) } socket.onclose () { // 断开后 3 秒重连避免训练中途因网络抖动掉线 reconnectTimer setTimeout(() connectRealtime(sessionId, onMessage, onMessage), 3000) } }这里有两个参数值得说一下。一个是 WebSocket 的路径设计/ws/train/{sessionId}把 sessionId 放在路径里而不是消息体里好处是后端可以直接按路径前缀做路由不用解析消息才知道属于哪个场次。另一个是重连时间设为 3000 毫秒这个值不是拍脑袋定的太短会导致服务端被重连请求打穿太长会让地图出现明显的空白期。三秒钟足够让网络抖动恢复也不会让用户觉得卡死。后端在收到subscribe消息后不是直接把数据塞给这个连接而是把连接实例加入一个按 session 分组的集合里。每 300 毫秒的定时器触发时后端把当前 Redis 快照里的单位位置整理成一个 frame推给这个分组下的所有连接。实际推的数据是批量坐标数组前端拿到后整体更新图层而不是逐条更新。这么做是为了减少地图 API 的调用次数单位数量上百之后逐条更新会造成地图卡顿。3.3 什么数据该推、什么数据该拉别把阵地图刷成 PPT实时可视化系统最常见的过度设计是恨不得把每个字段都通过 WebSocket 推下去。这套系统在数据方向上是做了选择的不是所有数据都走实时通道。数据类型方向理由单位坐标、姿态、状态WebSocket 推送高频变化需要 300ms 级更新训练阶段切换、开始/结束事件WebSocket 推送需要立即感知不能等下一次拉取单位列表、编制表、规则参数REST 拉取低频静态数据首屏一次性获取回放历史数据REST 拉取按时间区间批量取不适合推这个分界逻辑适合所有类似的实时可视化系统不管是设备监控还是态势展示。判断标准很简单这个数据如果晚到 5 秒会出问题吗会就走推送不会就走拉取。把低频数据塞进推送通道只会让连接的消息体越来越大前端解析越来越慢最后地图变成一页页翻的 PPT。4. 数据回放与复盘事件流加快照把一场对抗倒回去看4.1 回放数据落盘事件流加快照双写格式数据回放是本系统里含金量最高的模块。训练过程中后端同时在做两件事把单位位置写进位置轨迹表把交战、损毁、区域控制变化等事件写进事件表。回放的时候前端不是逐条读事件而是先把整场训练的“骨架”拉出来再把轨迹批量填充进去。这套系统的回放存储用的是一个很务实的双写方案。每隔固定秒数存一条单位位置快照同时每发生一个关键事件就追加一条事件记录。快照负责让时间轴跳转时有数据可画事件负责让复盘时能看清“那一刻发生了什么”。如果只存事件没有快照回放进度条拖动时会发现中间大段空白如果只存快照没有事件复盘就变成看一段无声动画没有对抗逻辑。回放记录在代码里是一个扁平结构大致长这样# backend/app/service/replay_service.py def append_frame(session_id, timestamp, units, events): # frame 是回放的最小单元一个 frame 对应一次采样周期的战场状态 frame { t: timestamp, units: [ { id: u[unit_id], lon: u[lon], lat: u[lat], status: u[status] } for u in units ], events: [ { type: e[type], target_id: e[target_id], desc: e[desc] } for e in events ] } # 写入回放表按 session_id t 建立索引回放时按时间范围检索 insert_replay_frame(session_id, frame)参数上的关键是timestamp。这个时间不是服务器当前时间而是训练逻辑内部维护的虚拟时间。虚拟时间的好处体现在回放上复盘时可以用任意倍速播放时间轴推进和真实时间无关。如果直接存服务器时间倍速播放时会让前端做大量时间换算还容易出现时间戳重排。这个细节直接决定回放模块的代码量是快照方案里最值得借鉴的点。事件和单位位置放在同一个 frame 里而不是分开两张表也是刻意的。复盘时最常做的事情是“拖到某个时间点看当时单位在哪、发生了什么”。把它们放在一起一次查询就拿到完整状态省掉了联表合并的麻烦。代价是同样的单位位置会被冗余存储多份但换来回放查询的高效在训练数据量级下是值得的。4.2 回放控制器播放暂停倍速跳转时间轴是核心前端数据回放页面核心是一个时间轴控制条。它负责三件事加载某一段时间的 frame 数据、控制播放速度、在时间轴上标记事件点。代码实现上回放控制器不直接操作地图而是通过一个setTime(t)的接口把当前时间点告诉地图渲染层由渲染层去查找对应时间的快照。// frontend/src/views/replayPlayer.js let replayTime 0 let playing false let speed 1 function play() { playing true requestAnimationFrame(tick) } function tick() { if (!playing) return replayTime 16.7 * speed // 按帧推进speed 支持 1/2/4/8 倍速 loadFrames(replayTime) requestAnimationFrame(tick) } function loadFrames(t) { // 按虚拟时间取数据后端返回这个时刻前后的两个快照做插值 api.getReplayFrame(sessionId, t).then((frames) { mapRenderer.renderReplayFrame(frames) }) }这个控制器的设计要点是replayTime只往前走不做回退。用户手动拖动时间轴跳转时直接设置replayTime并触发一次数据加载而不是把播放器停下来。这样实现最省代码还能保证进度条拖动过程中地图是持续更新的。播放倍速用了 1、2、4、8 四档这不是随便定的。复盘场景里1 倍速看战术动作4 倍速看整体兵力调动8 倍速看全流程脉络。设计成倍数关系而不是自定义任意速度是因为相邻两帧快照之间的插值算法在倍数速度下计算量是可控的任意速度反而更难优化。如果你在自己的系统里想改倍速档位记得同步检查后端接口在快速跳转时的响应能力不然倍速到 16 以后可能变成幻灯片。4.3 一套地图组件复用实时与回放共享渲染器这套系统没有为回放单独写一套地图渲染组件而是复用了实时态势那套地图图层。实时模式下单位图层的数据来源是 WebSocket 推送的帧回放模式下数据来源是后端回放接口返回的快照帧。两种模式数据格式一致前端只是把数据源切换到不同入口。复用的做法是抽了一个mapRenderer对象对外暴露renderFrame(frame)方法。实时模式下WebSocket 的onMessage回调调用它回放模式下回放控制器加载完数据后也调用它。两层逻辑互不认识只是接在同一套渲染接口上。这个设计的直接收益是地图上的标绘逻辑只维护一套。单位的红蓝样式、选中高亮、事件气泡这些表现在实时和回放里完全一致。复盘时看到的画面和训练时指挥员看到的画面是同一个效果不会出现“复盘地图和实时地图长得不一样”这种低级问题。想做二次开发的话在这个渲染器上叠加新的图层是最合理的扩展点比如加一个火力覆盖范围图层不需要改任何数据链路。5. 部署运行与避坑指南四十分钟跑起来四个坑提前排掉5.1 准备环境与启动顺序先数据库、再后端、再前端项目压缩包解压之后目录里带了sql/init.sql初始化脚本和前后端两套完整代码。部署环境要求不高一台 4 核 8G 的 Linux 服务器就够了。依赖的中间件是 MySQL 和 Redis版本没有特别苛刻的要求MySQL 5.7 以上、Redis 5 以上都能跑。启动顺序强烈建议按依赖关系来先导入数据库脚本确认表结构建好再启动 Redis然后启动后端服务最后启动前端开发服务器。这个顺序能把你排查启动错误的范围缩到最小。先跑前端再跑后端的话前端页面能打开但数据全是空的还会误导你去查地图组件配置。# 1. 导入数据库结构 mysql -u root -p sql/init.sql # 2. 启动 Redis redis-server --daemonize yes # 3. 启动后端 FastAPI 服务监听 8000 端口 cd backend pip install -r requirements.txt uvicorn main:app --host 0.0.0.0 --port 8000 --reload # 4. 启动前端开发服务器 cd ../frontend npm install npm run dev启动完成后浏览器访问前端开发服务器的地址默认端口 8080能看到登录页说明前端起来了。用初始化脚本里的默认账号登录进入训练管理页创建一个模拟训练地图上有单位出现拖动视角看刷新是否正常。后端日志里如果出现 WebSocket 连接建立的记录说明实时通道也通了。整个链路四十到五十分钟能验证完。这里有一个容易忽视的细节pip install -r requirements.txt可能会因为网络原因装得很慢建议先确认 Python 版本和依赖列表里的包是否兼容。这套系统的后端代码在 Python 3.9 和 3.10 上表现稳定如果本机默认 Python 是 3.12某些依赖的 wheel 包可能找不到预编译版本需要编译安装时间会拉长。5.2 启动失败的排查清单端口、时区、跨域、瓦片部署过程中最常见的四类问题对照下面的清单排查比看官方文档更高效现象原因解决前端页面白屏或接口 502后端服务没启动或端口不一致检查 uvicorn 监听端口和前端代理目标是否一致回放时间轴漂移 8 小时MySQL 连接时区未指定后端数据库连接串加serverTimezoneAsia/Shanghai登录后接口请求被浏览器拦截跨域未放行后端 CORS 中间件加上前端来源地址地图区域空白不出图瓦片图源无法访问切换本地瓦片包或配置 Nginx 反向代理瓦片服务端口问题是最常见的后端默认 8000前端开发服务器代理配置里如果写的是 8001那页面打开就是一片报错。时区问题只影响回放模块数据写入和读取用的虚拟时间没有时区概念但落到 MySQL 的时间戳字段时会因为默认时区差导致时间轴偏移。跨域问题在开发环境最典型因为前端和后端跑在两个端口上浏览器的同源策略会拦截请求这套系统后端已经加了 CORS 配置但如果改了前端端口记得同步改允许来源。地图瓦片加载是当前这类可视化系统最容易被低估的坑。系统默认用的是在线瓦片服务如果部署环境没有公网访问权限地图组件会在加载瓦片时卡住页面其他部分正常只有地图区域转圈。解决方法是把瓦片地址换成本地部署的瓦片服务或者用 Nginx 做一个静态代理把瓦片路径代理到内网资源。5.3 避坑记录四场实战翻车提前排掉第一个坑是按钮重复提交。训练管理页面里点击“创建训练”后如果网络延迟没有经验的用户会再点一次结果后端生成了两场一模一样的训练。现象是列表里出现重复场次红蓝单位各多了一份。原因有两层前端没有做提交锁后端接口没有做幂等校验。解决时我加了两个保险前端在请求发出后把按钮置为 loading 状态后端在创建逻辑里用“训练名称加创建时间窗口”做唯一性校验重复请求直接返回已有 session_id。这个修法对应那种“前后端分离项目里按钮重复提交”的经典场景不只是这一套系统几乎所有管理系统都值得加。第二个坑是回放数据不完整。复盘时发现快速拖动时间轴某些时间段的单位位置是空的。现象是地图上单位凭空消失再拖一段时间又冒出来。原因出在快照写入的时序上训练逻辑里状态更新和快照写入之间没有做顺序控制导致快照表里存在部分帧只有事件没有位置。解决方法是给每个 frame 生成一个单调递增序号写入时按序号覆盖快照查询时按最大序号取最新状态。从那套系统之后我处理所有轨迹存储需求都会强制要求时序编号。第三个坑是地图卡顿。对抗单位数量到三百左右时地图操作开始掉帧旋转视角有明显延迟。排查后发现不是渲染性能不够而是 WebSocket 消息体里携带了大量冗余字段每个单位的属性里包含了一些从不变化的静态信息比如单位名称、所属编制这些信息每次都跟着位置一起推。解决方法是把推送消息简化成位置数组静态属性只在训练初始化时下发一次前端把静态属性和实时位置合并后渲染。消息体积减少约七成卡顿立刻消失。第四个坑是回放倍速播放时的数据抖动。现象是 8 倍速播放时单位轨迹会出现明显的跳变看起来像瞬移。原因是回放接口按时间区间查询时某些时间点的快照缺失前端做了插值但因为缺少基准点只能画直线。解决方法是把快照采样频率从固定的 5 秒改成按事件驱动保存关键事件发生前后各存一次快照保证轨迹在战术节点上有足够的数据锚点。这个经验后来我用在了所有回放类系统的设计中不要用统一采样率要在状态突变点做额外采样。6. 二开进阶给回放日志加一把签名锁验证数据完整性回放数据毕竟是训练后的结果如果谁能改数据库复盘结论就失去了公信力。最常见的做法是给回放记录加完整性校验。这套系统当时没有做这层防护我接手后给它补了一个轻量级的签名链方案是从电子签名前后端实现里学来的思路用摘要锁住记录顺序。实现方式不复杂。保存回放记录时对每条 frame 的原始内容做 HMAC 签名签名密钥作为环境变量配置在后端不回落到数据库。签名输入里包含当前 frame 的时间戳、单位数据哈希以及上一条 frame 的签名值。这样链路是一条链任何一条记录被修改后面所有记录的签名校验都会失败。import hmac import hashlib import json SECRET_KEY your-secret-key # 从环境变量读取不要硬编码进代码库 def sign_frame(frame, prev_signature): # 先把 frame 内容按固定顺序序列化保证签名结果可复现 payload json.dumps(frame, sort_keysTrue, separators(,, :)) message f{payload}|{prev_signature}.encode(utf-8) return hmac.new(SECRET_KEY.encode(), message, hashlib.sha256).hexdigest()校验时从头遍历回放记录重新计算 HMAC和存储的签名比对不一致就说明数据被动过。这套方案成本很低不用引入区块链或者复杂的证书体系但对复盘数据的可信性提升是实打实的。不需要每帧都验复盘开始前做个批量校验几百条记录几毫秒就算完了。这套做法也适合其他需要留痕的业务场景比如设备操作日志、演练指令记录。从那以后我每次接手这类仿真可视化系统第一件事不是打开界面看效果而是拉一遍数据流中间层的落盘逻辑。先确认回放能验证再去做功能扩展省掉了后续大量返工。希望帮到你。本文还有配套的精品资源点击获取