SpringBoot+Vue城市公交调度系统设计与实现：从排班到实时监控

说实话，城市公交调度这块，十多年前基本靠“老师傅经验+对讲机吼”，后来进步点也就是Excel排个班表，调度员拿个本子记发车时间。真轮到车辆晚点、临时加车、司机调休，全靠电话沟通，一个环节出错，整条线路的节奏全乱。我自己参与过几个类似的管理系统项目，也帮朋友排查过不少线上问题，从最早的JSP单体到后来的前后端分离，折腾一圈下来，SpringBoot + Vue这套组合，确实是最适合中小型调度系统的方案。这篇文章就把我当时做城市公交车调度管理系统的完整思路拆给你看，从技术选型、功能拆解、数据库设计到核心代码逻辑，再到那些文档里不会写的坑，一次性聊透。

这套系统说到底解决的是三个问题：一是把“人排班”变成“规则排班+人工微调”，把调度员从重复劳动里解放出来；二是把“靠对讲机问车辆在哪”变成“大屏实时看位置状态”；三是把“月底翻记录算运营数据”变成“系统自动出报表”。适合正在做类似课设、毕设，或者刚入行想搞明白前后端分离项目到底怎么落地的朋友参考。我会把能直接复用的表结构和代码逻辑都放出来，你照着改改就能用。

1. 项目整体设计与技术选型思路

1.1 为什么是SpringBoot + Vue，而不是其他组合

我最早接触这类系统时，见过用纯JSP + Servlet写的，也见过用SpringMVC + Thymeleaf做服务端渲染的。不能说不能用，但在城市公交调度这个场景下，问题非常明显：调度大屏需要高频刷新车辆位置和状态，服务端渲染每次都要重新生成整个页面，网络开销大，页面还容易闪白。到后来我接手改造时，毫不犹豫选了前后端分离，SpringBoot只负责出接口，Vue负责页面交互和渲染。

选SpringBoot，核心原因是它把配置简化到了极致。以前SpringMVC时代要写一大堆XML，SpringBoot一个@SpringBootApplication注解加几个starter就完事，内嵌Tomcat打jar包直接跑，部署成本低。对调度系统这种业务逻辑复杂但并发量不算极端的管理系统来说，SpringBoot的自动装配机制和成熟的生态刚好够用，又不用像微服务那一套引入注册中心、网关，徒增维护成本。

选Vue，原因是它的学习曲线和开发效率。调度系统里有大量表格、表单、弹窗、联动选择这类交互，Vue的双向绑定和组件化开发，写起来比原生JS爽太多。而且国内前端生态里，Element Plus、Ant Design Vue这些组件库对中后台系统的覆盖度非常高，车次表格、排班表单、线路配置这些界面，基本就是“搭积木”搭出来的。

提示：如果你用的是SpringBoot 3.x，注意JDK版本必须17以上，而且部分老教程里的javax.*包要换成jakarta.*，网上很多案例踩坑都踩在这。我做的时候用的SpringBoot 2.7 + JDK8，稳定且兼容性最好。

1.2 调度系统的核心业务流程梳理

技术上喊得再响，业务不梳理清楚，系统做出来也是空中楼阁。我做之前把公交调度整个流程捋了一遍，大致是这样的：

第一步，线路规划。每条线路有始发站、终点站、中途站点集合、单程时长、发车间隔。这些基础数据是整个系统的地基。

第二步，班次计划。根据线路的客流特征，高峰期、平峰期、低峰期设置不同的发车间隔，生成一整天的行车班次表。比如早高峰7:00-9:00发车间隔5分钟，平峰期10分钟，晚高峰6分钟。

第三步，车辆与司机排班。把公司现有的车和司机，分配到具体的班次上。这步最头疼，因为要兼顾司机的工时合规（不能连续驾驶超过4小时）、车辆维保计划、司机的休息日。

第四步，实时调度。车辆上线运营后，系统要实时掌握每一辆车的位置、速度、是否准点。一旦出现晚点、故障、客流激增，调度员要能下发指令，比如调整发车间隔、临时加车、区间车调度。

第五步，统计分析。每天运营结束后，系统自动汇总各线路的发班数、准点率、客流量、异常事件，生成日报、周报，辅助管理层做决策。

这套流程走完，你会发现系统本质上是两条线：一条是“计划线”，从线路到班次到排班，是提前做好的；另一条是“实时线”，从车辆定位到调度指令，是运营过程中动态调整的。两条线最终汇合到报表体系里，形成一个闭环。

1.3 技术栈全景与选型理由

直接列一下我当时用的完整技术栈，后面聊到细节都有依据：

选MyBatis-Plus而不是JPA，是我个人偏好。调度系统里大量涉及多表关联查询，比如“查某条线路当天的班次执行情况，还要关联司机和车辆信息”，JPA的懒加载和N+1问题在复杂查询里会让人怀疑人生。MyBatis-Plus的LambdaQueryWrapper写条件查询非常直观，复杂SQL直接写XML里，可控性更强。

1.4 前后端分离的开发与部署流程

前后端分离，说直白点就是两个独立的工程，各干各的，通过HTTP接口通信。前端静态文件打包后丢到Nginx，后端打jar包直接跑。开发流程上，第一步首先定接口文档，我用的是Apifox，把所有接口的路径、请求参数、返回结构定义清楚，前端用Mock数据并行开发，后端按文档实现，最后联调。这样流程，前端不用等后端，效率翻倍。

目录结构上我按模块分包，而不是按技术层分包，这个细节挺有用。以前习惯controller、service、mapper三层平铺，项目一大了找代码特别费劲。改成按业务模块分，比如line包放线路相关控制器、服务、映射，dispatch包放调度相关，每个包内部再分controller/service/mapper，高内聚低耦合，改一个功能只需要进一个包。

2. 核心功能模块拆解与数据库设计

2.1 基础数据管理：线路、站点、车辆、司机

基础数据是整个系统的地基，设计不好后面调度逻辑写得再漂亮也白搭。线路、站点、车辆、司机不是孤立的，它们之间有很多隐含关系。比如一条线路关联多个站点，站点有顺序号、距离上一站的里程、预计到站时间；一辆车有自己的线路归属和车辆类型；一个司机有资质等级和可驾驶车型。

我当时设计表的时候，有几个关键点容易忽略，提醒你注意。一是站点顺序，必须有一个sort_no字段，不然你没法判断车辆是往始发站开还是往终点站开。二是线路的单程时长不能是写死的固定值，我用的方案是base_duration加peak_offset两个字段，高峰期在基准时长上加偏移量，更符合实际。三是车辆和司机都要有“状态机”，车辆有运营中、维修中、休息、报废，司机有在线、休息、请假、驾驶中，状态流转要记录日志，方便后续追责。

2.2 班次计划与排班逻辑

班次计划这块，是大多数人会忽略但其实最值得花时间的模块。简单说，系统要根据线路的发车时段配置，自动生成第二天的班次表。比如某条线路6:00-22:00运营，高峰期间隔5分钟，平峰间隔10分钟，那么一天下来大约150个班次。

排班的实现我参考了常见的“轮转排班法”。核心逻辑是：把司机分成若干组，每组按固定的工作模式循环，比如“早班-晚班-休息-休息”，这样既保证公平，又方便计算工时。代码层面就是按司机的工作模式列表，结合上一周期的排班结果，循环给未来的班次分配司机。

注意：排班算法千万别一上来就搞“最优解”，那是运筹学里的大难题，什么遗传算法、禁忌搜索，听着高级，实际落地时你连目标函数都定义不清楚。我先用规则引擎（早班优先、连班限制、工时上限）硬排，排不出来的标记为“待人工处理”，让调度员手动微调。实测下来，80%的班次能自动排出来，剩下20%人工处理，这才是合理的投入产出比。

生成排班后，还有一个“改班”场景很常见，比如有司机临时请假、车辆故障、桥隧封路。改班会牵一发而动全身，所以要支持批量调整，并且记录每次调整的前后差异和操作人，这就是审计日志。

2.3 实时调度监控与调度指令

实时调度模块是系统最有“科技感”的部分，也是面试和演示时最加分的地方。大屏上显示每条线路、每辆车的实时位置和状态。后端通过WebSocket向前端推送车辆位置，前端用ECharts以定时刷新+动态趋势图的方式展示各项指标：准点率、发班数、客流热力、预警事件。

车辆位置在真实场景里靠车载GPS终端上报，但开发调试阶段没有硬件，我做了个模拟器：用一个线程池模拟30辆车，每辆车按线路站点顺序移动，定时向服务端上报位置和速度。服务端把位置缓存到Redis，再通过WebSocket广播给前端大屏。这个模拟器关键点在于要能模拟晚点、故障、拥堵等异常情况，这样调度模块才有数据可“调”。

调度指令这块，我设计了两类指令：一类是“建议类”，系统根据规则计算出的建议，比如“XX路XX车当前晚点6分钟，建议下一班提前发车”，调度员确认后执行；另一类是“强制类”，调度员直接下发，比如“XX车到达终点站后直达某站支援”，司机端APP收到指令弹窗确认。简单说，系统做辅助决策，人做最终判断，这个定位很重要，调度员才愿意真用。

2.4 数据库表设计核心思路

数据库设计直接决定系统的复杂度和可维护性。我把核心表列出来，并说明几个关键设计决策：

几个容易踩坑的设计决策，我单独展开说一下：

第一，所有表都带create_time和update_time，用MyBatis-Plus的自动填充功能维护，省心。第二，状态字段用tinyint不用字符串，0正常、1停运、2故障，注释写清楚，查询排序都更快。第三，涉及日期时间的字段统一用datetime，不要用timestamp，后者有2038年问题，我没必要为一个看似未来的隐患埋雷。第四，vehicle_location这种高频更新的数据，线上正式环境应该走Redis或时序数据库，MySQL只存最终位置用于审计。

排班表schedule一定要加唯一约束(shift_id, vehicle_id)，防止同一车辆同时被排到两个班次。这个约束在并发调度场景下是保命符，很多类似的课设项目栽在这上面，大屏看着没问题，一上线多个人并发操作，数据就乱了。

3. 核心代码逻辑与前后端实现细节

3.1 后端统一接口规范与代码分层

前后端分离之后，接口规范是头等大事。我定义了统一的返回结构Result，所有接口都返回这个格式，前端拿到后统一处理，异常也走这个结构，而不是直接抛一堆英文错误给用户。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.code = 200; r.message = "success"; r.data = data; return r; } public static <T> Result<T> error(Integer code, String message) { Result<T> r = new Result<>(); r.code = code; r.message = message; return r; } }

Controller层只做参数接收和结果包装，业务逻辑全部在Service层，事务边界也开在Service上。举个例子，生成班次表的方法在Service内部是@Transactional的，一旦中途出错，整个批次的班次生成全部回滚，不会出现“生成了上午的班次，下午的失败”这种半成品数据。

分页查询是个高频操作，MyBatis-Plus的Page对象帮了大忙。配合LambdaQueryWrapper，查“某线路当天未发车的班次”这种需求，三行代码搞定：

Page<Shift> page = new Page<>(current, size); LambdaQueryWrapper<Shift> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Shift::getLineId, lineId) .eq(Shift::getDate, today) .eq(Shift::getStatus, 0) .orderByAsc(Shift::getDepartureTime); return shiftMapper.selectPage(page, wrapper);

注意：MyBatis-Plus分页要配置PaginationInnerInterceptor，不配的话分页实际只查了全表再内存截断，数据量大时线上直接就OOM了。这是高频坑，10个用MyBatis-Plus的人里至少有3个踩过。

3.2 JWT认证与权限控制实现

调度系统虽然不像金融系统那么敏感，但也不能谁都能改班次、下发指令。我用的Spring Security + JWT方案，流程是这样：用户登录成功后，后端签发一个JWT令牌返回给前端，前端存在本地存储里，每次请求在HTTP头里带上Authorization: Bearer <token>，后端通过拦截器解析令牌、识别用户身份和角色。

JWT的优势在前后端分离场景下很明显：无状态，服务端不用存登录会话，横向扩展不用考虑session同步。但纯JWT有个问题：没法主动让令牌失效。用户点了“退出登录”，令牌在有效期内还是能继续用。我的方案是Redis黑名单：登录时把token存一份到Redis，退出或修改密码时删掉Redis里的记录，拦截器先查Redis，不存在就直接拒绝。

角色权限上分了三种：超级管理员、调度员、司机。调度员只能操作自己管辖线路的数据，司机端只能查看自己的排班和接收调度指令。实现方式就是Spring Security的@PreAuthorize("hasRole('DISPATCHER')")这种注解，打在Controller方法上，简单直接。

@PostMapping("/dispatch/command") @PreAuthorize("hasRole('DISPATCHER')") public Result<Void> sendCommand(@RequestBody DispatchCommandDTO dto) { dispatchService.sendCommand(dto); return Result.success(null); }

3.3 前端核心页面实现：路由、状态、组件

前端我用了Vue 3 + Vite + Element Plus。Vite的开发服务器启动速度比Webpack快不是一星半点，几乎是秒开，配合热更新，开发体验非常舒服。路由用Vue Router，配合beforeEach守卫做登录判断：没有token就强制跳转登录页，有token但访问的页面没有权限就跳403页。

状态管理用Pinia，主要管理两件事：登录用户信息、全局的线路和车辆筛选条件。举个例子，调度员登录后选了一条线路，进入大屏或者排班页面，都默认看这条线路的数据，这个“当前选中线路”的状态放在Pinia里，跨页面共享，避免每个页面都重新传参。

前端代码结构上，我习惯把API请求单独抽一层，统一放在src/api目录下，每个模块一个文件。这样Controller改路径时，只需要改一个地方，不会满项目找请求代码。另外，请求和响应都做了Axios拦截器，请求拦截器负责加token，响应拦截器统一判断code是否为200，非200直接弹出错误信息。

3.4 实时定位与WebSocket推送的实现

车辆实时定位是调度系统最核心的功能之一，也是技术上比较棘手的一块。我的设计分三层：模拟器产生位置数据、服务端接收并推送、前端渲染并展示。

模拟器这块，我写了一个MockVehicleRunner，每个线程模拟一辆车，按线路的站点坐标插值计算当前位置，每次移动后把经纬度、速度、状态通过HTTP上报给后端。上报接口每秒接收所有车辆的数据，写入Redis缓存（key是vehicle:location:{vehicleId}，value是JSON字符串，过期时间设10秒），然后通过WebSocket推送给前端大屏。

WebSocket的服务端实现用Spring的WebSocketHandler，核心代码大概是这样：

@Component public class LocationWebSocketHandler extends TextWebSocketHandler { private final CopyOnWriteArraySet<WebSocketSession> sessions = new CopyOnWriteArraySet<>(); @Override public void afterConnectionEstablished(WebSocketSession session) { sessions.add(session); } @Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { sessions.remove(session); } public void broadcast(String message) { for (WebSocketSession session : sessions) { if (session.isOpen()) { session.sendMessage(new TextMessage(message)); } } } }

注意这里的CopyOnWriteArraySet，它是线程安全的，适合这种“多线程写入、遍历读取”的场景。每辆模拟车辆的位置上报后，调用broadcast向所有前端推送同一份数据。车辆数量不多时，这种全量广播完全够用，不过要是车辆上千台，就得改成按线路分组推送了。

前端接收WebSocket消息，提到一个特别注意点：WebSocket连接会随时被断开，比如网络切换、服务端重启、浏览器休眠。前端代码里一定要引入心跳检测和自动重连机制。我实现的方式是：每30秒前端发一个ping消息，服务端回pong，如果前端超过60秒没收到任何消息，就主动关闭连接，3秒后重连。这些细节不处理的话，大屏页面开个一上午，车辆位置就全部卡死了。

3.5 大屏数据可视化实现

大屏是给领导看的，也是系统对外展示的门面。我选了ECharts作为图表库，因为它的文档全、示例多、社区活跃。调度大屏我做了以下几个可视化模块：

顶部是核心KPI卡片，展示今日运营线路数、总班次数、当前在线车辆数、综合准点率。四个卡片数据通过一个聚合接口一次性返回，一个请求搞定，避免多次请求造成页面卡顿。

中间是车辆位置地图，由于真实环境接的是GPS定位，可以在腾讯地图或高德地图上打点展示；开发阶段我直接用静态地图图片加ECharts散点图模拟，效果差不多。

左侧是线路准点率排行，用横向柱状图，准点率低的线路标红，方便调度员一眼看到重点。右侧是客流趋势，用折线图展示各时段客流变化。

ECharts数据刷新是个容易忽略的问题。我的做法是：WebSocket每收到一批新的位置数据，就更新地图图层；KPI和图表数据每30秒用定时器请求一次HTTP接口刷新。不建议把图表刷新频率设太高，特别是折线图和柱状图，高频刷新反而会造成视觉闪烁，30秒一次人流感知上完全够用。

4. 实操过程中踩过的坑与排查指南

4.1 常见问题速查表

4.2 并发排班的资源冲突

这个问题我调了很久才彻底搞清楚。多个调度员同时操作同一线路的排班，比如A把某辆车排到8:00的班次，B同时把同一辆车排到8:05的班次，如果不加控制，数据库中就会产生冲突数据。

当时的排查过程让我印象深刻。先是MySQL报警出现了重复记录，我看了一下，当时没有唯一约束，所以也谈不上所谓的“锁”。后来我层层排查，最终发现问题是缺少并发控制机制。解决办法分两步：第一步是加数据库层面的唯一索引，确保底层硬约束；第二步是加应用层锁。

public boolean assignVehicleToShift(Long shiftId, Long vehicleId) { String lockKey = "lock:shift:" + shiftId; boolean locked = redisLock.tryLock(lockKey, 5, TimeUnit.SECONDS); if (!locked) { throw new BusinessException("该班次正在被其他调度员操作，请稍后重试"); } try { // 检查车辆是否已被占用 return scheduleService.assign(shiftId, vehicleId); } finally { redisLock.unlock(lockKey); } }

Redis分布式锁的粒度是“每个班次一把锁”，保证同一时间只有一个调度员能操作同一个班次。加锁超时时间设5秒，防止调度员编辑页面停留太久导致锁无法释放。这个方案实测下来很稳，再没出现过重复分配的问题。

4.3 大屏数据刷新卡顿与优化

大屏上线跑了一天后，发现页面变得越来越卡，特别是车辆状态列表滚动时，明显掉帧。我用Chrome开发者工具的性能面板看了一下，发现问题出在WebSocket推送的消息频率太高，导致前端不断触发DOM更新和ECharts重绘。

优化手段有三板斧，你可以直接照抄：

第一，后端推送频率从“每辆车每秒一次”降到“每辆车每3秒一次”，同时对位置做滤波处理，变化量小于阈值的坐标不推送。调度员对3秒的延迟完全无感，但前端渲染压力直接降了三分之二。第二，前端对WebSocket消息做节流，用requestAnimationFrame合并多次渲染请求，一次动画帧内只渲染一次，避免同步触发多次重绘。第三，车辆状态列表用虚拟滚动，只有视口内的行才渲染DOM节点，几百辆车同时在线时列表依然丝滑。

需要解释一个细节：为什么不是直接降低模拟器上报频率，而是做滤波。其实是因为业务上必须保留高频数据来做准点率计算，直接降频会影响数据准确度，滤波则是在保留高精度数据的同时，减少无效的界面渲染，两全其美。

4.4 前后端联调时几个容易忽略的细节

联调阶段每天都有一堆糟心事，这里说三个最常见的。

第一个是Long类型精度问题。数据库主键id是bigint，前端JavaScript的Number类型最大安全整数是2^53，一旦id超过这个值，前端拿到的id就丢失精度。比如id是1812345678901234567，前端收到的可能是1812345678901234500。解决方式很粗暴有效：后端返回的JSON里，把Long类型的主键字段序列化为字符串，加@JsonSerialize(using = ToStringSerializer.class)，或者全局配置ToStringSerializer。如果不加，你会看到点击“编辑”按钮时，弹窗里明明有数据，但提交更新时后端一直说“记录不存在”。

第二个是日期格式不一致。前端传2024-05-01，后端DateTime类型解析失败。全部统一成yyyy-MM-dd HH:mm:ss格式，后端在实体类的日期字段上加@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")，问题迎刃而解。

第三个是接口路径或字段名不统一。前端和后端对同一个字段的命名不同，比如后端叫lineId，前端写成了line_id，接口一直404或者返回null。这个没有技巧，只能靠接口文档约束，我用的Apifox可以直接生成前端TypeScript类型定义和接口方法，文档和代码保持同步，大幅减少了这类问题。

4.5 功能上线前一定要做的几项检查

写完了代码，测试通过了，我建议上线前再自查一遍这几个点，能省掉很多线上事故：

• 数据库连接池配置：默认的hikaricp最大连接数只有10，多人同时操作时偶尔会出现获取连接超时。调到20-50，具体看你的并发量。
• 接口幂等性：特别是WebSocket和HTTP上报接口，网络抖动时客户端会重试，后端要保证同一辆车同一秒上报的重复数据不会重复入库，加个时间戳+车辆ID的唯一索引就行。
• Redis内存淘汰策略：车辆位置缓存和JWT黑名单的key都设置了过期时间，但如果在极端情况下Redis内存满了，可能触发LRU淘汰，导致JWT黑名单丢失。我在配置里设置了maxmemory-policy volatile-lru，只淘汰设置了过期时间的key，这样未过期的业务数据不会被动清除。
• 静态资源缓存：Vue打包后的JS/CSS文件都会带上hash指纹，但index.html不能设长缓存，否则前端升级后用户打开的还是旧页面。我在Nginx里对index.html设了no-cache，静态资源设max-age=31536000，这样既保证加载速度，又保证更新及时。

这套SpringBoot + Vue的公交调度系统，从零到上线完整走一遍，前后大概花了一个半月。说实话，最花时间的不是写代码，是理清调度业务背后的边界情况：司机临时请假怎么办，车辆中途抛锚怎么改派，两辆车同时到达终点站如何避免抢道。这些业务如果没摸透，代码写得再漂亮，上线也是天天在“救火”。

我个人在设计这类系统的体会中，比较重要的一个认知是：技术永远服务于业务场景，不要为了炫技引入复杂的框架或算法，多想想“调度员每天打开系统最需要看到什么”。聪明的做法是：先把核心的闭环打通，让调度流程数字化运转起来，再逐步引入智能推荐、自动排班这些进阶能力。这样对于毕业设计或实际项目来说，风险都可控，演示效果也好，更重要的是，你从中学到的技能是可迁移的，后续换任何管理类系统，这套设计思路和方法论都能复用。