说实话城市公交调度这块十多年前基本靠“老师傅经验对讲机吼”后来进步点也就是Excel排个班表调度员拿个本子记发车时间。真轮到车辆晚点、临时加车、司机调休全靠电话沟通一个环节出错整条线路的节奏全乱。我自己参与过几个类似的管理系统项目也帮朋友排查过不少线上问题从最早的JSP单体到后来的前后端分离折腾一圈下来SpringBoot Vue这套组合确实是最适合中小型调度系统的方案。这篇文章就把我当时做城市公交车调度管理系统的完整思路拆给你看从技术选型、功能拆解、数据库设计到核心代码逻辑再到那些文档里不会写的坑一次性聊透。这套系统说到底解决的是三个问题一是把“人排班”变成“规则排班人工微调”把调度员从重复劳动里解放出来二是把“靠对讲机问车辆在哪”变成“大屏实时看位置状态”三是把“月底翻记录算运营数据”变成“系统自动出报表”。适合正在做类似课设、毕设或者刚入行想搞明白前后端分离项目到底怎么落地的朋友参考。我会把能直接复用的表结构和代码逻辑都放出来你照着改改就能用。1. 项目整体设计与技术选型思路1.1 为什么是SpringBoot Vue而不是其他组合我最早接触这类系统时见过用纯JSP Servlet写的也见过用SpringMVC Thymeleaf做服务端渲染的。不能说不能用但在城市公交调度这个场景下问题非常明显调度大屏需要高频刷新车辆位置和状态服务端渲染每次都要重新生成整个页面网络开销大页面还容易闪白。到后来我接手改造时毫不犹豫选了前后端分离SpringBoot只负责出接口Vue负责页面交互和渲染。选SpringBoot核心原因是它把配置简化到了极致。以前SpringMVC时代要写一大堆XMLSpringBoot一个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 技术栈全景与选型理由直接列一下我当时用的完整技术栈后面聊到细节都有依据层次技术选型说明后端框架SpringBoot 2.7稳定、社区资料多ORMMyBatis-Plus 3.5单表CRUD不用写SQL复杂查询用XML数据库MySQL 8.0业务数据存储缓存Redis 5.x登录令牌、车辆状态缓存、排班锁实时通信WebSocket车辆位置推送、调度指令下发权限认证JWT Spring Security无状态认证前后端分离标配前端框架Vue 3 Vite组合式API写起来更顺手UI组件Element Plus中后台表单、表格利器图表ECharts 5客流分析、运营报表、大屏展示HTTPAxios统一请求封装状态管理PiniaVue 3官方推荐选MyBatis-Plus而不是JPA是我个人偏好。调度系统里大量涉及多表关联查询比如“查某条线路当天的班次执行情况还要关联司机和车辆信息”JPA的懒加载和N1问题在复杂查询里会让人怀疑人生。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 数据库表设计核心思路数据库设计直接决定系统的复杂度和可维护性。我把核心表列出来并说明几个关键设计决策表名核心字段用途说明lineid, line_name, start_station, end_station, base_duration, distance线路基础信息stationid, line_id, station_name, sort_no, distance_from_last, plan_arrive_time站点及线路关系vehicleid, plate_no, vehicle_type, line_id, status, capacity, maintenance_date车辆信息与当前状态driverid, name, license_type, work_type, status, phone司机信息与排班模式shiftid, line_id, departure_time, arrival_time, direction, date班次计划scheduleid, shift_id, vehicle_id, driver_id, date, status排班结果dispatch_logid, schedule_id, type, content, operator_id, status, create_time调度指令与日志vehicle_locationid, vehicle_id, lng, lat, speed, status, update_time车辆实时位置可走Redisoperation_reportid, line_id, date, planned_shifts, actual_shifts, punctuality_rate, passenger_flow运营日报几个容易踩坑的设计决策我单独展开说一下第一所有表都带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 ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.code 200; r.message success; r.data data; return r; } public static T ResultT error(Integer code, String message) { ResultT r new Result(); r.code code; r.message message; return r; } }Controller层只做参数接收和结果包装业务逻辑全部在Service层事务边界也开在Service上。举个例子生成班次表的方法在Service内部是Transactional的一旦中途出错整个批次的班次生成全部回滚不会出现“生成了上午的班次下午的失败”这种半成品数据。分页查询是个高频操作MyBatis-Plus的Page对象帮了大忙。配合LambdaQueryWrapper查“某线路当天未发车的班次”这种需求三行代码搞定PageShift page new Page(current, size); LambdaQueryWrapperShift 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 ResultVoid 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 CopyOnWriteArraySetWebSocketSession 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 常见问题速查表问题现象可能原因解决方案前端请求后端接口报CORS错误未配置跨域SpringBoot加CrossOrigin或配置CorsFilter排班时车辆被重复分配缺少唯一约束schedule表加(shift_id, vehicle_id)唯一索引MyBatis-Plus分页返回所有数据缺少分页插件配置PaginationInnerInterceptorJWT登录后刷新页面就失效token未持久化前端存localStorage不要存sessionStorage大屏收到的车辆位置断断续续心跳丢失WebSocket断开前端加心跳和自动重连机制生成的班次时间与配置间隔不符时区问题MySQL连接串加serverTimezoneAsia/Shanghai修改密码后旧token仍有效JWT无状态缺陷Redis维护token黑名单前端传日期字段后端解析失败格式不匹配统一使用yyyy-MM-dd HH:mm:ss或加JsonFormat注解同时发车多辆车位置显示错乱经纬度字段精度不够经度维度用decimal(10, 6)不要用float4.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 GMT8)问题迎刃而解。第三个是接口路径或字段名不统一。前端和后端对同一个字段的命名不同比如后端叫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-age31536000这样既保证加载速度又保证更新及时。这套SpringBoot Vue的公交调度系统从零到上线完整走一遍前后大概花了一个半月。说实话最花时间的不是写代码是理清调度业务背后的边界情况司机临时请假怎么办车辆中途抛锚怎么改派两辆车同时到达终点站如何避免抢道。这些业务如果没摸透代码写得再漂亮上线也是天天在“救火”。我个人在设计这类系统的体会中比较重要的一个认知是技术永远服务于业务场景不要为了炫技引入复杂的框架或算法多想想“调度员每天打开系统最需要看到什么”。聪明的做法是先把核心的闭环打通让调度流程数字化运转起来再逐步引入智能推荐、自动排班这些进阶能力。这样对于毕业设计或实际项目来说风险都可控演示效果也好更重要的是你从中学到的技能是可迁移的后续换任何管理类系统这套设计思路和方法论都能复用。