最近在整理一套基于 Spring Boot 的公交智能化管理系统，源码和论文都完整跑通了。不少人在做这类题目的时候，最大的困惑不是代码写不出来，而是业务边界不清、模块堆得很多却互相割裂，论文写起来更像是在凑字数。今天我把整套系统的设计思路、核心实现、论文框架和踩过的坑一次性讲清楚，希望给准备做相关项目的同学一些可以直接落地的参考。

这套系统的定位很明确：用后端技术为公交运营提供数据化、可视化、可调度的管理能力。它不是一个“功能越多越好”的堆砌型项目，而是围绕公交公司的真实业务流——线路规划、站点管理、车辆调度、实时监控、乘客出行查询——形成一个闭环。适合用来做毕业设计、课程综合实训，或者作为求职简历里的项目案例。

1. 项目定位与技术选型：先搞清楚系统到底要解决什么问题

1.1 公交公司的痛点是什么

说句实话，很多地方性公交公司至今还在用 Excel 管理线路和排班，调度靠电话沟通，车辆位置只有 GPS 厂商提供的封闭平台能看到，乘客想知道下一班车几点到，基本靠运气。

所以这个“公交智能化系统”要解决的核心问题有三个：

• 运营数据的统一管理：线路、站点、车辆、司机、班次都集中在一个后台里维护，而不是散落在不同表格里。
• 车辆状态的实时感知：通过位置上报机制，让调度员能看到每辆车跑到哪里了、车速多少、是否偏离线路。
• 乘客服务的信息化：让乘客能通过网页或小程序查线路、查站点、查车辆的实时到站信息。

抓住这三条主线，系统的功能边界就清晰了。很多同学做这类项目时容易跑偏，比如非要加一个复杂的财务结算模块，或者做一个花哨的聊天功能，这些都不是公交管理的核心场景，硬加进去只会让代码和论文都显得不伦不类。

1.2 为什么选 Spring Boot 这套组合

技术选型的原则有一个：用最稳的方案，而不是最新的方案。我建议的组合是：

• 后端框架：Spring Boot 2.7.x
• 持久层框架：MyBatis-Plus
• 数据库：MySQL 8.0
• 缓存：Redis
• 权限认证：Spring Security + JWT
• 前端后台：Vue 3 + Element Plus
• 地图可视化：高德地图 JavaScript API
• 乘客端：微信小程序或 H5（二选一）

为什么 Spring Boot 版本不建议直接上 3.x？因为 3.x 要求 JDK 17，很多学校的实验环境、云服务器配置 2G 内存跑 JDK17 加前后端项目会有点吃力，而且网上公开的资料、遇到过的问题大部分还是基于 2.7 的。2.7 版本成熟、资料多、遇到 bug 容易搜到解决方案，对项目开发来说稳比新更重要。

MyBatis-Plus 是真香，单表 CRUD 基本不用手写 SQL，节省了大量时间，可以把精力集中在业务逻辑和调度算法上，而不是整天写SELECT * FROM table WHERE id = ?。

Redis 用来做两类事情：一类是缓存高频查询的线路站点数据，另一类是存储车辆最新位置，因为实时位置表的写入频率很高，如果每次都查 MySQL，数据库压力会大，而且乘客端刷新时要读最新状态，走缓存速度更快。

1.3 各端的技术分工说明

这套系统的开发协调方式，建议前后端分离，不推荐用 JSP 或者 Thymeleaf 去写管理后台。前后端分离一方面符合当前主流开发模式，另一方面论文里可以画出清晰的前后端交互架构图，对论文的含金量是有帮助的。

• 管理后台：Vue 3 + Element Plus，面向系统管理员，负责基础数据维护。
• 调度端页面：可以并入管理后台，用独立菜单和页面承载，负责排班和监控。
• 乘客端：如果是毕设，做一个 H5 页面 + 微信公众号菜单接入就够了，小程序需要注册账号、审核类目，反而拖慢进度。
• 模拟器：这是很容易被忽略但非常关键的一个模块。没有条件接真实 GPS 终端，就写一个模拟车辆轨迹的线程任务，按照线路坐标定时上报位置，整套实时监控功能才能演示得起来。

2. 数据模型设计：业务的核心骨架是这样搭出来的

2.1 核心数据表结构与字段解析

数据库是整个系统的地基，表的数量和字段设计直接决定开发时的效率。我最终落地了 8 张核心表，每张表都对应一个明确的业务模块：

以线路站点关联表为例，这是线路和站点多对多关系的中间表，但设计上有一个细微之处值得注意：额外冗余了站点名称字段。

CREATE TABLE line_station ( id BIGINT PRIMARY KEY AUTO_INCREMENT, line_id BIGINT NOT NULL COMMENT '线路ID', station_id BIGINT NOT NULL COMMENT '站点ID', station_name VARCHAR(50) NOT NULL COMMENT '站点名称（冗余字段）', station_order INT NOT NULL COMMENT '站点顺序，从1开始', direction TINYINT NOT NULL COMMENT '方向：1-上行，2-下行', distance_prev DECIMAL(8,2) DEFAULT 0 COMMENT '与上一站距离(公里)', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_line_station (line_id, station_id, direction) ) COMMENT '线路站点关联表';

为什么加station_name？因为查询线路详情时经常要按顺序展示所有站名，如果每次都去关联站点表，多一次 JOIN，在展示层多做一次循环。做成冗余字段后，查一次表就能拿到完整站点列表，空间换时间，在业务上非常划算。

2.2 线路上下行设计：公交业务的一个关键细节

公交线路有上行和下行，同一个站在上行方向和下行方向的顺序是不同的。这一点很多第一次做公交系统的同学容易忽略，直接用一张表只维护一套站点顺序，结果前端展示出来的线路是乱的。

我的处理方式是在线路站点关联表中用direction字段区分方向，同一个站点在同一个线路上最多存在两条记录，分别属于上行和下行。这样查询线路详情的时候，只需要带线路ID和方向两个条件，按station_order排序即可。

在站点排序的时候，上行方向按发车站到终点站排序，下行方向反过来。初始化数据的时候，可以通过一个简单的后端接口一次提交两个方向的数据，也可以写一个管理页面分别维护。调度排班时，每趟车的发车方向也由这条记录的方向字段决定。

2.3 实时位置表与缓存策略

vehicle_location是写入频率最高的表。模拟器运行时，每 5 秒上报一辆车的位置，10 辆车就是每秒 2 条写入，如果跑上一整天就是数十万条记录。如果不做处理，这表的膨胀速度会很吓人。

我的方案是：位置数据优先写入 Redis，以vehicle:location:车辆ID为 key，存最新经纬度和时间，保留最近 200 条历史轨迹。MySQL 里的vehicle_location表只做定时落库，并且按天归档，这样既保证监控大屏读取最新位置时毫秒级响应，又避免数据库被高频写入拖垮。

具体接实时数据时同样适用：终端上报到后端接口，接口里同时做 Redis 更新和异步写库，让上报请求的响应时间尽量短。

3. 核心功能实现：从接口设计到调度逻辑

3.1 后台管理的通用模块与权限设计

后台管理模块包括线路管理、站点管理、车辆管理、司机管理，这些本质上都是标准 CRUD。MyBatis-Plus 的BaseMapper已经提供了大部分接口，业务层只需要补充校验逻辑即可。

值得展开的是权限方案。我的设计是两种角色：系统管理员和调度员，采用 Spring Security + JWT，接口层面通过注解控制权限。

@PreAuthorize("hasRole('ADMIN')") @PostMapping("/line") public Result addLine(@RequestBody BusLine line) { // 保存线路 }

JWT 的好处是无状态，前后端分离下不用在服务端维护会话，这对部署到单台服务器上的项目非常友好。要注意的是，Spring Security 的默认配置会比较严格，跨域、放行接口、匿名访问这些需要提前配好，不然前端调用接口时会被 401 和 403 折磨得透顶。

3.2 排班调度模块：如何生成合理的发车计划

公交排班是一个经典的调度问题，对于毕设体量，不需要实现动态优化算法，用一个基于固定发车间隔的排班生成器就足够了，但逻辑要完整。

我的实现思路是：

• 每条线路在配置里设定首班时间、末班时间和高峰/平峰发车间隔。
• 排班服务启动时，读取该线路所有车辆和司机，按照早班、晚班的顺序分配车辆。
• 从首班时间开始，按发车间隔生成当天的全部班次，每辆车一天跑 4 到 6 个往返。

核心伪代码如下：

public List<ScheduleResult> generateSchedule(BusLine line, LocalDate date) { List<BusVehicle> vehicles = vehicleMapper.selectByLineId(line.getId()); List<DriverInfo> drivers = driverMapper.selectByLineId(line.getId()); LocalDateTime start = LocalDateTime.of(date, line.getFirstBusTime()); LocalDateTime end = LocalDateTime.of(date, line.getLastBusTime()); List<ScheduleResult> result = new ArrayList<>(); int vehicleIndex = 0; int driverIndex = 0; LocalDateTime current = start; while (current.isBefore(end)) { ScheduleResult sr = new ScheduleResult(); sr.setVehicleId(vehicles.get(vehicleIndex % vehicles.size()).getId()); sr.setDriverId(drivers.get(driverIndex % drivers.size()).getId()); sr.setDepartureTime(current); // 按照这条线路的单程行驶时长推算到达时间 sr.setArrivalTime(current.plusMinutes(line.getTravelMinutes())); // 单程结束后车辆不立即回场，休息10分钟后跑对向班次 current = sr.getArrivalTime().plusMinutes(10); vehicleIndex++; driverIndex++; result.add(sr); } return result; }

这里有三个细节值得注意：

第一，车和司机轮流分配，避免同一辆车连续跑全天导致“疲劳驾驶”，本系统里司机 ID 会轮换分配。第二，每趟车到终点后并不是返回停车场，而是要跑对向班次，所以休息时间后就可以安排下一个方向。第三，生成好的排班结果要落库，同时标记状态“待发车”“运行中”“已完成”，这样调度员才能手动调整。

3.3 车辆实时监控与轨迹回放

实时监控的展示方式是地图上显示所有在线车辆的位置、速度和状态。地图选用高德地图，使用 JavaScript API 2.0 版本，通过 WebSocket 推送位置数据到管理后台。

后端的实现是：位置上报接口收到数据后，除了写 Redis，还通过 WebSocket 将处理后的数据广播给监控页面。管理后台在地图上用 Marker 标记车辆位置，点击后弹出车辆信息和班次信息。

这里有个容易被忽略的细节：如果在高德地图上展示车辆位置，上报的经纬度必须是高德采用的 GCJ-02 坐标系。如果是真实 GPS 设备，上报的通常是 WGS-84 坐标系，直接显示会偏移几百米，必须做坐标转换。模拟器因为直接用高德地图上取的坐标，不存在这个问题。

轨迹回放功能同样需要 Redis 里的历史轨迹数据，前端通过调用接口获取某辆车在某个时间段的坐标点序列，在地图上连线。这部分的实现代码相对简单，但演示效果非常好，论文里值得单独写一节。

3.4 乘客端查询：让系统有面向用户的出口

乘客端如果做得简单，就是一个线路查询和车辆实时位置展示的 H5 页面，但如果有小程序经验，做成小程序也是加分项。两者的后端接口是一样的，区别只是在数据返回格式上做适配。

乘客端核心接口有三个：

• 根据关键词模糊查询线路列表
• 查询某条线路的详情、首末班时间、票价和全部站点
• 查询某条线路的当前运行车辆位置

查询接口要加 Redis 缓存，线路数据很短时间不会变化。可以用一个简单的注解解决：

@Cacheable(value = "line:list", key = "'all'") @Override public List<BusLine> listAllLines() { return lineMapper.selectList(null); }

注意一个问题：乘客端查询车辆位置时，如果车辆在非运营时段没有数据，要返回一个合理的结果，比如“该线路当前暂无运营车辆”，而不是空列表。接口层面做一层状态码和消息的封装，前后端联调会清爽很多。

4. 论文写作指南：让论文真正“配得上”你的源码

4.1 论文整体结构与各章节分工

很多同学代码做完了，论文却不知道怎么下笔，最后只能东拼西凑。其实论文结构和这个系统的代码结构有天然对应关系，把每一章对应到代码模块上，写起来就有底气。

一篇标准的毕业设计论文，章节分配大概是这样的：

很多人问：论文查重最注重的章节是哪些？输出经验是绪论和相关技术这两章网上参考很多、最容易飘红，写的时候尽量用自己理解的话去表述，截图和图表如果是从网上抄的，一定要重新绘制。

4.2 需求分析与用例建模怎么写

需求分析这一章，关键要点是画出三个图：系统角色用例图、功能结构图、数据流图。这三个图画好了，需求分析章节基本上就已经撑起来了。

系统角色可以确定为：

用例图绘制时，每个角色对应一个系统边界，用例之间不要画成杂乱的关系网，保持清晰就好。在论文里，对每个用例补充一段用例描述，包括参与者、前置条件、基本流、异常流。这部分内容看着多，写起来其实很快，基本就是翻译代码里的接口逻辑。

4.3 数据库设计与系统实现章节的写法

数据库设计章节要做到看得懂、可复现。除了列表说明外，建议至少画一张 ER 图，并放上每个核心表的字段描述表格。在你论文里，用表格列出字段名、类型、是否主键、约束用途，比大段文字要直观得多。

系统实现章节恰恰是论文最占据篇幅的部分。建议一个模块配一个界面截图和三到五段核心代码。比如排班模块，配上排班列表页和生成排班的接口代码；位置上报模块，配上上报接口的代码和高德地图的 JS 代码。截图不要用手机拍的电脑屏幕，要用截图工具，页面尽量完整、美观，因为答辩老师会从截图里直接判断项目质量和认真程度。

特别提醒：表示业务录入过程的截图要有边界感，比如录一条线路时，截图里包含线路名称、首末班时间、站点顺序填写，不仅展示功能，还传达出操作流程。

4.4 系统测试这一章用什么素材

测试章节最容易敷衍，但恰恰是论文深度的一个体现。建议准备两份素材：一份是功能测试用例表，一份是性能测试数据。

功能测试用例表可以这样设计：

性能测试数据不需要拿专业的压测工具跑，用简单的 JMeter 或 Postman 跑几个接口看看耗时即可。比如并发 50 个请求查询线路列表，响应时间平均 120ms，这些数据记录下来放论文里，体现实实在在做了验证。

5. 实战避坑与答辩准备清单

5.1 开发中容易踩的坑：坐标、并发、模拟数据

坐标偏移的问题前面提到过，这是最容易踩的坑之一。如果你在展示监控大屏时发现车辆位置和实际线路对不上，第一反应就是坐标系问题。解决方案是提前在系统里做坐标转换工具类，统一坐标系。

第二个坑是缓存穿透。如果乘客端查询一个不存在的线路ID，缓存里没有，数据库也没有，每次请求都打到数据库，这种查询在 Redis 缓存时会导致并发量大的时候把数据库打崩。解决办法很简单：缓存空值，加上短暂过期时间。

第三个坑是模拟器的写法。很多同学把模拟器做成一个 Controller 接口，用 Postman 手动点一次上报一次，这演示效果非常差。正确的做法是做一个后台定时任务，每隔几秒自动推进车辆位置，让它沿着线路站点匀速移动。这样打开大屏，车辆自己在动，整个项目瞬间就有生命力了。

第四个坑是本地运行环境。MySQL 编码要设为 utf8mb4，否则存中文站点名时会乱码。Spring Boot 的配置文件里，数据库连接加上characterEncoding=utf8，这些基础问题如果没提前处理，联调时会非常折磨。

5.2 演示时让评审眼前一亮的技巧

答辩演示时，建议准备三套数据场景：

• 场景一：早高峰，所有车辆正常运行，有车辆出现偏离线路或速度异常，展示报警。
• 场景二：临时调度，把某辆车的排班手动调整到另一条线路，展示调度员的处理流程。
• 场景三：乘客端查询，展示乘客查询某班车的实时位置，和监控大屏做联动对比。

这三套场景对应三个核心亮点：实时监控能力、调度灵活性、乘客信息服务。同时，这三个场景正好对应论文里的三个创新点，答辩老师顺着这条线提问，你回答起来也从容。

5.3 一个容易被低估的准备：数据初始化脚本

统一告诉你要准备一个初始化 SQL 脚本，里面配置好至少 5 条线路、40 个站点、6 辆车、6 个司机和一天的完整排班数据。不要现场手动录入，太浪费时间，而且展示时容易露怯。

脚本里还要造一些合理的运营数据，比如连续一周的运营记录。这些数据用于统计图表展示时，曲线才好看，不至于空荡荡的一条直线。数据造得越真实，答辩时说“系统已经过一段时间试运行验证”就越有底气。

5.4 我自己的经验和体会

我个人在实际项目里最大的感受是：这种完整业务系统，比纯粹堆技术栈的演示项目要有说服力得多。面试官和答辩老师看到的是一个有实际业务逻辑、有完整数据链路、有用户角色的作品，而不是一个“启动即一堆接口列表”的空壳。

另外提醒一点：项目代码要规范。类名、方法名、接口路径统一风格，注释写清楚，尤其是核心算法和调度逻辑，注释能体现你到底懂不懂这行代码。Git 提交记录也保持整洁，抽查代码的时候也能成为一个加分项。

最后一个小技巧：在你完成整个系统后，把最终的初始化和演示脚本执行一次，确定能一步到位跑起来，再打包一份部署说明文档。毕竟源码和论文是否完整，取决于它能不能快速运行起来，这份贴心的整理会在最后评审时成为很有分量的印象分。