简介这是一份基于Spring Boot的城市公交运营管理系统完整设计文档适合计算机相关专业学生、毕业设计开发者及对在线管理系统感兴趣的读者。文档围绕传统公交管理受时间地点限制的问题提出了信息化解决方案详细介绍了系统背景、研发意义、技术选型与总体设计。包体内仅有1个docx文件大小4.84MB内容涵盖用户权限划分与三大核心模块公交员可查看调度、紧急上报、车辆状况调度员负责车辆与调度信息管理管理员统筹线路分类、人员信息及全部业务数据。文档结构完整包含摘要、目录、系统分析与设计等内容可作为学习Spring Boot框架、角色权限设计、业务模块划分的参考范例也能辅助完成相关课题的开题与论文撰写。目前已有53人学习浏览适合需要快速了解系统整体架构或借鉴项目方案的开发者。1. 城市公交运营管理系统一个看似简单、实则栽在状态流转上的项目第一次接到这个标题时我的第一反应是“又一个 CRUD 管理系统”。等真正把需求说明书翻完我才意识到公交运营系统和常规的后台管理系统完全是两码事它的核心复杂度不在增删改查而在线路、车辆、司机、班次、站点之间不断变化的状态流转。一辆车从“待发车”到“运行中”再到“已收车”中间涉及排班是否冲突、司机工时是否超限、站点顺序是否合法、定位上报是否断档任何一环断了调度大屏上就是一片黑洞。所以这篇笔记写给两类人一是准备做毕设或课程设计的同学照着这套方案能在一个月内把系统跑起来论文也有东西写二是公司里要接公交集团或客运企业数字化项目的一线开发者这里的表结构和状态机设计可以直接复用能帮你少走几轮评审的弯路。我会从技术选型、数据库设计、核心模块实现、踩坑排查一路讲到底全部基于可复现的 Spring Boot 工程。2. 技术选型与工程骨架为什么这套组合最稳2.1 Spring Boot MyBatis Plus MySQL 的选型理由公交运营管理系统有一个特点业务规则复杂但并发量并不高。一辆公交车上的 GPS 上报可能每 10 秒一条全市几百台车同时上报也只有每秒几十条的量级远没到需要微服务、消息队列的程度。常见的做法是 Spring Boot 做单体应用MyBatis Plus 做数据访问MySQL 存业务数据Redis 做缓存和实时状态存储。这套组合的开发效率最高排查问题也最直接——一个 jar 包部署完事不需要维护多套服务。如果项目里已经有 Spring Cloud 的痕迹我的建议是能砍就砍。公交运营系统的业务边界非常清晰拆微服务只会让事务变得难以控制。比如“发车”这个动作要同时更新车辆状态、生成运营记录、标记班次状态三个表在一个事务里完成单体应用一条Transactional注解就解决了拆成微服务反而要写分布式事务。A同学之前把一个模拟项目拆成了四个服务结果排班和车辆状态经常对不上最后又老老实实合并回单体。2.2 工程骨架与最小依赖配置直接可抄的 pom.xml先建一个标准的 Spring Boot 工程用 Maven 管理依赖。父工程选择一个你熟悉的稳定版本下面这些依赖是这个系统的底线配置dependencies !-- Web 层 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 数据访问 -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 缓存车辆实时状态放 Redis -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency !-- 工具类 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependenciesMyBatis Plus 的版本需要和 Spring Boot 版本匹配建议用mybatis-plus-boot-starter而不是mybatis-plus前者会自动装配 SqlSessionFactory。注意这里的依赖故意没写 version因为版本号由 Spring Boot 父工程统一管理你只需要在properties里覆盖 MyBatis Plus 的版本即可。spring-boot-starter-data-redis用来存车辆实时位置和在线状态这类数据读写频繁、不需要持久化放 Redis 比放 MySQL 合理得多。2.3 从设计文档到代码包结构把需求说明书变成工程目录拿到的是 .docx 格式的设计文档说明需求已经经过一轮整理里面通常包含用例图、ER 图如果文档规范的话和功能清单。我一般会先做一件让很多人嫌麻烦的事把功能清单里的名词全部抽出来圈出名词之间的关系。公交系统里最常见的名词是线路、站点、车辆、司机、班次、排班、运营记录、乘客刷卡记录这些名词就是要建的表。对应到代码包结构常见的做法是这样的com.example.transit ├── controller # 接收 HTTP 请求 │ ├── LineController │ ├── VehicleController │ ├── DispatchController │ └── ReportController ├── service # 业务逻辑层 │ ├── ScheduleService │ ├── VehicleStatusService │ └── GpsReportService ├── mapper # MyBatis Plus 的 Mapper 接口 ├── entity # 数据库实体 ├── dto # 前端交互对象 ├── config # 配置类Redis、WebSocket、定时任务 └── common # 统一返回结果、异常处理controller 层只做参数接收和结果返回业务逻辑全部在 service 层。这个系统的调度逻辑比较复杂如果把业务写在 controller 里后期加一个“自动排班”功能就要大面积重构。在 service 层里按业务域划分每个域一个服务类比如排班调度一个类、车辆状态一个类条理清楚后面写单元测试也好写。3. 公交运营的数据库设计11 张表把调度、排班、票务串成一张网3.1 线路、站点、班次三张主表的字段取舍线路表是系统的基础数据最简单的设计只需要id、line_no线路编号如 101 路、line_name、start_station、end_station、direction上行/下行、first_bus_time、last_bus_time。很多同学会在这里犯一个错把中间站点做成一个字符串字段存 JSON看起来省事但后续要做“某一站经过哪些线路”的查询时就会非常痛苦。正确做法是单独建一张line_station关联表记录线路与站点的多对多关系以及站点在线路上的顺序号。站点表反而简单就是id、station_name、longitude、latitude。注意经纬度用decimal(10,6)类型float 和 double 会有精度问题定位偏出去几百米在公交场景里就是一次投诉。班次表记录某条线路每天计划发车的时刻表字段包括line_id、depart_time、direction、vehicle_id实际执行的车辆、driver_id、status。班次是排班的结果也是后续统计发车准点率的依据。3.2 排班表与车辆运营记录表状态机是关键排班表存的是“哪天哪辆车哪个司机跑哪个线路的哪个班次”字段有schedule_date、line_id、vehicle_id、driver_id、shift_no第几班、start_time、end_time。这个表的核心约束是同一辆车在同一时间段不能出现在两个班次里同一个司机也是。这个约束不能只靠后端代码判断数据库层面要建联合唯一索引一个简单的uk_vehicle_time就能挡住大部分并发写入的脏数据。车辆运营记录表是这个系统的灵魂它记录的是每一次“发车—运行—收车”的完整过程。字段包括vehicle_id、line_id、schedule_id、start_time、end_time、start_mileage、end_mileage、status。这里的status用枚举表示0 待发车、1 运行中、2 已收车、3 异常。状态机的流转方向是严格单向的待发车只能进运行中运行中只能进已收车或异常不允许跳变。这个规则要写在 service 层做校验不能只靠前端按钮控制。3.3 用 SQL 验证表结构一次模拟的线路发车查询表设计完之后不要急着写代码先拿几组 SQL 把业务场景模拟一遍能查出来再写 Mapper。最常见的查询是“查某条线路今天所有已发车的班次和车辆状态”SELECT s.id AS schedule_id, s.depart_time, v.vehicle_no, d.real_name AS driver_name, o.status AS operate_status FROM schedule s LEFT JOIN vehicle v ON s.vehicle_id v.id LEFT JOIN driver d ON s.driver_id d.id LEFT JOIN operate_record o ON o.schedule_id s.id WHERE s.line_id #{lineId} AND s.schedule_date #{today} ORDER BY s.depart_time;这个查询验证了两个关键点一是排班表和车辆、司机表的关联关系是否通畅二是运营记录表是否通过schedule_id与排班表正确关联。如果这里发现运营记录查出来是 NULL说明发车时没有正确生成记录属于逻辑缺陷要回去检查 service 层。把这些 SQL 在数据库客户端里跑通了表的合理性基本就有底了。4. 排班调度与定位上报两个核心模块的实现路径4.1 排班生成用贪心 约束判断替代复杂算法排班是这个系统最容易被过度设计的部分。一上来就写遗传算法、模拟退火之类的同学最后大概率被调度规则的现实约束逼疯。公交排班的真实约束其实很朴素司机一天累计驾驶不超过 8 小时连续驾驶不超过 4 小时必须休息车辆按线路轮转跑完一班进保养的可能要跳过。这些用贪心算法配合约束校验就能解决效果足够好代码量还少。常见的实现思路是先把某条线路当天的所有班次按发车时间排序然后依次为每个班次分配司机和车辆。每次分配前做一次冲突校验检查司机当天累计工时是否超限、车辆是否空闲。下面这段伪代码描述了核心逻辑public void autoSchedule(LocalDate date, Long lineId) { // 1. 查出这条线路当天所有班次按发车时间排序 ListSchedule schedules scheduleMapper.selectByLineAndDate(lineId, date); for (Schedule schedule : schedules) { // 2. 找一个符合条件的司机当天工时未满 8 小时且与当前班次时间不重叠 Driver driver findAvailableDriver(lineId, schedule.getDepartTime()); if (driver null) { throw new BusinessException(线路 lineId 的班次 schedule.getId() 没有可用司机); } // 3. 找一辆空闲车辆 Vehicle vehicle findAvailableVehicle(lineId, schedule.getDepartTime()); // 4. 更新班次、司机排班、车辆占用 schedule.setDriverId(driver.getId()); schedule.setVehicleId(vehicle.getId()); scheduleMapper.updateById(schedule); } }findAvailableDriver的实现是整个排班的核心先查出该司机当天已有的排班记录计算累计工时再检查当前班次时间和已有排班是否有重叠。这个查询用 SQL 做最简单——查司机当天排班表中是否存在start_time 新班次结束时间 AND end_time 新班次开始时间的记录有就说明冲突。注意这里的“结束时间”不能用end_time字段直接比较因为班次可能跨中午休息要按“发车时间 预计运营时长”计算理论结束时间。4.2 车辆实时位置上报基于 WebSocket 的轻量方案车辆 GPS 数据上报是公交系统里一个“看起来简单、做起来讲究”的模块。最常见的方案是车辆终端每隔 10 秒向服务端上报一次经纬度、速度、方向角。服务端收到后做两件事更新 Redis 里这辆车的实时位置保留最近 N 条记录用于轨迹回放。MySQL 只做异步落库不要每条上报都直接写库否则 500 台车一天就能产生 400 多万条记录查询会明显变慢。上报接口的代码非常直接RestController RequestMapping(/api/gps) public class GpsReportController { Autowired private RedisTemplateString, Object redisTemplate; Autowired private GpsRecordMapper gpsRecordMapper; PostMapping(/report) public ResultVoid report(RequestBody GpsReportDto dto) { // 1. 校验车辆是否在运营状态 String key vehicle:status: dto.getVehicleId(); Object status redisTemplate.opsForValue().get(key); if (status null || !RUNNING.equals(status.toString())) { return Result.error(车辆不在运营状态); } // 2. 更新实时位置用 Hash 结构存经纬度5 分钟过期 String posKey vehicle:pos: dto.getVehicleId(); MapString, Object pos new HashMap(); pos.put(lng, dto.getLongitude()); pos.put(lat, dto.getLatitude()); pos.put(speed, dto.getSpeed()); pos.put(updateTime, System.currentTimeMillis()); redisTemplate.opsForValue().set(posKey, pos, 5, TimeUnit.MINUTES); // 3. 异步写入 MySQL走队列或定时批量 gpsRecordMapper.insert(dto.toEntity()); return Result.success(); } }这里有两个细节值得注意。第一个细节先查车辆状态再更新位置避免已收车车辆继续产生定位数据污染报表这个校验必须放在最前面。第二个细节GpsReportDto转实体的时候要手动截断经纬度精度decimal(10,6)在数据库层会做四舍五入但 MyBatis 在插入时可能因为精度问题报错提前处理掉更省心。异步落库的常用做法是用 Spring 的Async注解配合线程池或者先写 Redis List再由定时任务批量刷库后者的可靠性更好一些。4.3 调度看板的后端聚合查询一次返回当天所有在线车辆调度大屏是公交系统的门面后端要给前端提供“地图上所有正在运行的车辆”这个数据。如果让前端循环调用单辆车查询接口请求量会被放大几十倍所以必须提供一个聚合查询接口。实现思路是从 Redis 里批量获取所有车辆的实时位置再关联线路表和最近一站信息一次返回完整列表。GetMapping(/dashboard/online-vehicles) public ResultListOnlineVehicleVO onlineVehicles() { // 1. 从 Redis 里查出所有运营中的车辆 ID SetString keys redisTemplate.keys(vehicle:pos:*); ListOnlineVehicleVO result new ArrayList(); // 2. 逐辆车取位置信息并补充线路、司机信息 for (String key : keys) { String vehicleId key.replace(vehicle:pos:, ); MapString, Object pos (MapString, Object) redisTemplate.opsForValue().get(key); // 3. 查数据库补全线路号和司机姓名 Vehicle vehicle vehicleMapper.selectById(vehicleId); OnlineVehicleVO vo new OnlineVehicleVO(); vo.setVehicleNo(vehicle.getVehicleNo()); vo.setLineNo(vehicle.getLineNo()); vo.setLongitude((Double) pos.get(lng)); vo.setLatitude((Double) pos.get(lat)); result.add(vo); } return Result.success(result); }注意redisTemplate.keys(vehicle:pos:*)这个操作在 Redis 键数量很多的情况下会阻塞主线程生产环境要改用SCAN命令或者维护一个在线车辆 ID 集合。对于课程设计和中小规模系统KEYS命令在几百个键的规模下压力不大可以先用着但要把这个隐患记在技术方案的风险说明里评审时这是个加分项。查询结果里补全线路号和司机信息用的是逐条查库数据量小无所谓如果车辆数量过百就要改成批量查询WHERE id IN (...)。5. 公交系统开发避坑6 个真实踩过的坑与排查路径5.1 时间字段的时区问题导致班次全部错乱现象系统上线测试时调度员反馈“早上 6 点的班次在系统里显示成了 14 点”。查了半天发现是时间字段的锅——接口入参用字符串接收时间但没有指定时区服务器默认时区是 UTC存储时把本地时间当成 UTC 时间存了进去。原因application.yml里数据库连接串的时区参数没有设置加上LocalDateTime序列化时按系统默认时区处理双重的时区错位叠加。解决数据库连接串加serverTimezoneAsia/Shanghai实体里统一用LocalDateTime类型Jackson 配置spring.jackson.time-zoneGMT8。这个配置必须写进项目的初始化 checklist 里我每做一个新工程都会先看一眼这三处配置。5.2 线路方向与站点顺序的建模错误现象某条线路的上行和下行站点顺序完全反了。公交线路有两个方向上行从 A 站到 B 站下行反过来。如果line_station表里只记录了站点和线路的关联没记录方向查询“下一站”的时候就会算出错误结果。原因设计时为了省事把上行和下行共用的站点合并成了一份数据用同一个station_order表示顺序。但双向线路的站点顺序本来就是镜像的合并必然导致顺序冲突。解决line_station表必须增加direction字段上行和下行各维护一套顺序。查询站点顺序时强制带方向条件同时在建表时给(line_id, direction, station_order)建联合唯一索引防止同一方向出现两个相同顺序的站点。5.3 车辆状态并发更新导致运营记录丢失现象两辆车同时上报 GPS其中一辆的运营记录迟迟不生成调度大屏上这辆车消失了几分钟。定位到代码发现是发车接口里“更新车辆状态”和“生成运营记录”之间的校验被并发请求跳过了。原因Transactional注解保证的是数据库事务但两个并发请求同时读到了车辆状态为“待发车”都通过了状态校验一个生成了记录另一个把状态覆盖成“已发车”后记录却没生成。这是典型的“先查后写”并发问题单靠事务隔离解决不了。解决在车辆表上增加乐观锁版本号字段更新时带WHERE version #{oldVersion}影响行数为 0 说明有人抢先更新重试或抛异常。这个方案实现成本最低对公交这种低并发场景完全够用。5.4 坐标上报频率过高把数据库拖垮现象车辆终端设置为每 5 秒上报一次 GPS500 台车一天产生 864 万条记录数据库磁盘占用暴涨查询报表变慢。运维同学半夜打电话说磁盘告警。原因上报接口直接同步写 MySQL没有做频率限制和批量处理。解决把上报接口改成“先写 Redis再异步批量刷库”。具体做法是上报的坐标先追加到 Redis 的 List 里定时任务每 30 秒从 List 里批量取出攒够 500 条或 30 秒两个条件满足其一就批量 INSERT。这样数据库的写入压力能降低 90%轨迹查询走 Redis 也能满足最近 30 分钟的召回需求。5.5 排班结果“看起来合理”但不满足司机工时约束现象自动排班生成的班次表里某位司机被排了 3 班每班 2 小时理论上只有 6 小时工时但仔细一看中间没有休息间隔连续驾驶超过了 4 小时。调度员一眼看穿开发者却觉得逻辑没问题。原因排班逻辑里只检查了“总工时是否超 8 小时”没有检查“连续驾驶不超过 4 小时”。这是两个独立约束少一个就翻车。解决在findAvailableDriver里增加连续驾驶时长检查——把该司机当天已排班次按时间排序看当前班次与上一班次的间隔是否超过 4 小时。如果不足 4 小时要计算连续驾驶累计时长超过就跳过这个司机。这个检查就是几个字段的比较但漏掉的代价是被调度员当众质疑“系统不行”。5.6 页面分页查询查不到最新一条运营记录现象调度员在“运营记录”页面翻到最后一页看不到刚收车的那条记录。翻到第一页又能看到怀疑是数据丢了。原因分页查询的 SQL 里ORDER BY start_time DESC配合LIMIT而start_time字段有多个相同值MySQL 的排序不稳定导致记录在页与页之间跳动。解决排序字段加上id DESC作为二级排序保证排序稳定。这是一个很容易被忽略的细节但对用户体验影响很大尤其是数据实时变化的列表页。6. 再往上一步把运营数据变成能辅助决策的报表系统跑通之后评审或者答辩阶段最容易被问的问题是“除了看数据你的系统还能做什么”。这时候如果手里有运营分析报表整个项目的分量就不一样了。常见的做法是把每天的运营数据聚合到一张宽表里比如daily_line_stat字段包括线路编号、计划班次总数、实际发车班次、准点班次、异常班次、总客流、平均满载率。这张宽表由定时任务每天凌晨生成报表接口直接查宽表不需要实时跑聚合 SQL。宽表的设计要注意统计口径。准点率的计算有两种口径按发车时间算和按到达时间算。公交行业更常用的是发车准点率——实际发车时间与计划发车时间之差在正负 1 分钟内算准点。这个口径要在宽表里写死注释不然后续维护的同学改错公式整个报表数据就全偏了。我一般会留一张dim_calendar日期维度表用来处理节假日和非节假日的发车频次差异否则国庆和普通周一的“准点率”放在一起比较没有意义。报表接口要加缓存。宽表已经按天聚合数据不会实时变化接口可以直接缓存 5 分钟Redis 里存一次序列化结果响应时间从 200 毫秒降到 20 毫秒。前端大屏每秒刷新一次后端扛得住缓存扛不住缓存就是这道屏障。我自己的习惯是写完报表模块一定要手动核对一遍数据。拿某一天的运营记录按 SQL 里的统计口径手动算一条线路的准点率和宽表里的值对比对不上就说明聚合逻辑有 bug。这个核对动作我翻过车——宽表里的准点率算成了 120%就是因为统计分母用了计划班次分子却用了包含临时加班班次的实发数。从那以后每张报表上线前我都会做一次手工抽样核对这个习惯让我在项目交付验收时少了很多尴尬。希望帮到你。本文还有配套的精品资源点击获取