基于SSM和Vue的城市公交查询系统毕设完整开发指南

前几天，一个学弟发消息问我：2026年毕业设计想做个公交查询系统，题目写的是“基于SSM和Vue的城市公交查询系统，论文加程序”，可题目拿到手之后整个人是懵的，不知道这个系统到底要从哪里开始做，论文又该写哪些内容。

我没急着给他甩代码，而是把这套系统从选题逻辑、技术框架、数据库设计、前后端实现、论文撰写到答辩准备的完整链路拆了一遍。今天把这个过程整理出来，给准备做同类系统的同学一条清晰可走的路线。这类题目在毕业设计里属于典型的“小而全”：业务上有线路查询、站点查询、换乘规划、线路收藏；技术上有前端页面、后端接口、数据库建模。拿它来练全栈开发能力正好合适，论文素材也足够丰富。

1. 城市公交查询系统为什么是性价比很高的毕设选题

1.1 业务复杂度恰到好处

先说选题。很多同学一上来就追求大而复杂的系统，比如电商平台、社交App、在线教育平台，结果做到一半发现业务逻辑根本收不住，光是订单状态流转、支付回调、消息通知就能把人绕晕。公交查询系统的好处在于，它的业务边界非常清晰：乘客查线路、查站点、查换乘，管理员维护公交基础数据，就这两条主线。

这个复杂度对毕设来说刚刚好。如果题目太简单，比如做一个只有增删改查的公告管理，论文很难写出深度，答辩时也容易被追问到无话可说。而公交查询系统天然包含一个值得展开的核心难点——换乘方案的计算。光这一个点，就够你在论文里用一整章去讲算法思路和实现方式，工作量也能被合理撑起来。

另外，公交系统围绕“数据关系”展开，线路和站点是多对多关系，这种关系在企业级系统里非常常见。做完这个项目，你对关联表、索引、连表查询、数据一致性的理解都会比看书深刻得多。这些内容写在简历上，也是实打实的项目经验。

1.2 技术展示点覆盖完整

从技术角度看，一套SSM加Vue的公交查询系统，刚好把高校计算机专业课程里最重要的一块内容串起来了。

后端有Spring做依赖管理、SpringMVC做请求分发、MyBatis做数据持久化，分层结构一目了然；前端有Vue的组件化开发、组件间通信、路由跳转；数据库有MySQL的表设计和SQL优化；如果再把登录鉴权、跨域处理、前后端联调这些内容加进去，整篇论文的技术点就非常充实。

特别值得注意的是，这类项目在答辩现场的演示效果很好。你可以现场输入一条公交线路，展示它经过的所有站点；再输入一个起点和终点，给它算出一套换乘方案。评委能直接看到系统在真实业务场景下跑起来，而不是停留在“功能截图”层面。视觉上的直观感受，往往比讲十页PPT都管用。

1.3 与同类型题目的横向对比

我把近几年毕业生常选的几个题目方向放在一起对比过：

综合下来，公交查询系统在“能做完”和“有内容写”之间找到了一个很好的平衡点。尤其是你手里已经明确写了“论文加程序”，那选题就更要讲究门当户对——系统越贴近日常交通场景，论文里的需求分析就越容易写真实，而不是编一堆假需求凑字数。

2. 双端架构：Vue前端与SSM后端的项目骨架搭建

2.1 为什么毕设题目里还有大量SSM

现在生产环境中Spring Boot已经是主流，但高校毕设题目里SSM依然大量存在。原因很简单：很多课程设计和毕业设计题目库的更新速度没那么快，而且SSM这种“手动装配”的方式，能逼着学生去理解Spring底层的运作原理。

在SSM体系里，Spring负责IOC容器和Bean管理，SpringMVC负责请求映射和参数绑定，MyBatis负责SQL与Java对象的映射。引入Vue之后，SpringMVC的“视图”职责就退化了——Controller不再返回JSP页面，而是统一返回JSON数据，由前端Vue负责渲染。这个变化是理解整个项目架构的关键：后端只管提供数据接口，前端只管消费数据展示页面。

从开发节奏来看，SSM的坑确实比Spring Boot多一些，比如jar包版本冲突、XML配置繁琐、跨域需要手动处理。但换个角度想，这些“坑”恰恰是答辩时的素材。老师问“你们项目遇到过什么困难”，你完全可以把跨域配置、事务管理、MyBatis懒加载这几个问题拿出来讲，比单纯说“我用了Spring Boot自动配置”更有说服力。

2.2 后端工程的包结构与前端目录划分

搭建骨架的第一步是定结构。后端我习惯用标准的Maven工程，包名按照controller、service、mapper、entity、common来划分。

src/main/java ├─ controller // 控制层，接收前端请求 ├─ service // 业务层，处理具体业务逻辑 │ └─ impl ├─ mapper // MyBatis持久层接口 ├─ entity // 数据库实体类 ├─ common // 统一返回结果、工具类 └─ config // 拦截器、跨域配置

千万别把业务逻辑全写在Controller里，那是毕设代码最容易被老师挑毛病的地方。正确做法是：Controller只做参数接收和结果封装，业务判断放在Service层，SQL访问放在Mapper层。分层清晰之后，论文里的架构图才好画，代码也更好维护。

前端部分用Vue CLI或Vite创建工程，目录结构建议这样组织：

src/ ├─ api/ // 封装所有后端接口请求 ├─ router/ // 前端路由配置 ├─ store/ // 跨组件共享状态 ├─ views/ // 页面级组件 ├─ components/ // 可复用组件 └─ utils/ // 请求工具封装

api目录单独抽出来的好处是，所有接口地址集中管理，后面后端接口路径调整时，只改一个文件就行。很多新手喜欢在页面里直接写axios请求，一开始省事，等到接口变多，就会发现页面代码又长又乱，排查问题非常痛苦。

2.3 前后端接口约定与跨域问题

骨架搭好后，前后端联调前一定要先约定好接口格式。我的习惯是统一返回一个Result对象：

public class Result { private Integer code; // 200成功，401未登录，500异常 private String msg; private Object data; }

所有接口都走这个统一包装，前端axios在响应拦截器里统一判断code，不用每个页面都关心异常处理。接口路径按资源命名，比如：

跨域问题是SSM配合Vue时最先遇到的一个坎。如果用Vue CLI开发服务器做联调，默认端口是8081，后端Tomcat一般是8080，前后端端口不同就会触发跨域。解决方式有两种：后端写一个CORS过滤器统一放行，或者前端配置devServer的proxy代理。我更推荐后端的CORS过滤器，因为部署时即使前端资源没合并进后端工程，也能正常访问。

3. 公交线路与换乘算法的数据库设计要点

3.1 线路、站点、关联表如何设计

公交系统的数据模型核心是三张表：线路表、站点表、线路站点关联表。

很多人第一直觉是给线路表加一个“经停站点”字段，把站点名称存成一个逗号分隔的字符串。这个设计初期看着简单，但一旦要做“按站点查线路”，就要在SQL里做模糊匹配，性能差、容易出错，论文里也解释不通。正确的做法是用关联表把“多对多”关系显式表达出来。

线路表保存线路自身的属性：线路名称、类型、起点站、终点站、首末班时间、票价、状态。站点表保存站点信息：站点名称、所在地址、经纬度。关联表最关键，它的作用是把一条线路上的所有站点按顺序串起来。

CREATE TABLE `line` ( `id` int(11) NOT NULL AUTO_INCREMENT, `line_name` varchar(40) NOT NULL COMMENT '线路名称', `line_type` varchar(10) DEFAULT '公交' COMMENT '线路类型', `start_station` varchar(40) DEFAULT NULL, `end_station` varchar(40) DEFAULT NULL, `start_time` varchar(10) DEFAULT NULL COMMENT '首班时间', `end_time` varchar(10) DEFAULT NULL COMMENT '末班时间', `ticket_price` decimal(4,2) DEFAULT 2.00, `status` tinyint(1) DEFAULT 1 COMMENT '1启用 0停运', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

站点表：

CREATE TABLE `station` ( `id` int(11) NOT NULL AUTO_INCREMENT, `station_name` varchar(40) NOT NULL, `address` varchar(100) DEFAULT NULL, `lng` decimal(10,6) DEFAULT NULL, `lat` decimal(10,6) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

关联表：

CREATE TABLE `line_station` ( `id` int(11) NOT NULL AUTO_INCREMENT, `line_id` int(11) NOT NULL, `station_id` int(11) NOT NULL, `station_order` int(11) NOT NULL COMMENT '站点在线路上的顺序', PRIMARY KEY (`id`), UNIQUE KEY `uk_line_station` (`line_id`, `station_order`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3.2 建表顺序与字段选取的细节

字段类型上有一点要提醒：表名和字段名一律用下画线命名法，实体类里用驼峰命名，MyBatis里配置好驼峰映射，避免每次查询都写一堆列别名。

station_order这个字段特别重要。公交车是有方向的，同一条线路从起点站到终点站和反向的站点顺序完全不同，所以关联表里必须存顺序号。查询线路详情时，按station_order升序排列就能得到完整的正向站点列表。

经纬度字段建议保留，虽然初期用不上，但后期如果想引入地图可视化，把站点标注在地图上，这两个字段就是基础。论文里也可以写“本系统预留了GIS位置数据，为后续地图展示做支撑”，这种表述在总结展望部分非常加分。

别小看这三张表，它们之间还隐藏着一个分层索引问题：查询线路详情时要根据线路ID反查站点，查询站点时要根据站点ID反查线路。这个反查逻辑在Mapper里就是两条SQL的事，但在设计阶段就要把表关系理清楚，不然后面写业务代码时很容易在关联查询里迷路。

3.3 换乘方案计算：一次换乘与两次换乘的枚举逻辑

换乘算法是整个系统里最核心的计算逻辑，也是论文里最有技术含量的章节。我推荐用一种直观且好实现的思路：枚举换乘方案。

先定义一次直达的判断：如果起点站和终点站出现在同一条线路上，说明可以直接乘坐，不需要换乘。这个查询在数据库里很好做，通过关联表把两个站点的线路集合取出来求交集即可。

一次换乘的判断稍微复杂：起点站点所在的线路集合记作A，终点站点所在的线路集合记作B，如果存在一条线路a属于A，一条线路b属于B，并且这两条线路有至少一个公共站点，那么就可以在公共站点完成一次换乘。

二次换乘的判断可以继续套用枚举思想：先找起点站能到达的所有站点集合，再看这些站点中，有哪些站点能与终点站形成一次换乘。思路就是穷举中间站点，虽然听起来笨，但公交线路数量通常是几十条的量级，计算量完全可控。

在Java代码里的实现思路是这样的：

1. 查询起点站经过的所有线路；
2. 遍历每条线路上的所有站点，加入候选集合；
3. 对候选集合中的每个站点，反查它经过的线路；
4. 判断这些线路与终点站所在的线路是否有公共站点；
5. 如果有，就把换乘路径记录下来。

这样算出来的方案在绝大多数公交场景下都是可用的，换乘次数控制在两次以内，也更符合乘客的实际需求。等你把这个逻辑写进论文，配上一张换乘流程图，再把复杂度分析写清楚，这一章的工作量就非常扎实了。

4. 用户端核心功能实现：查询、换乘与收藏

4.1 三个核心查询接口的定义

用户端往下拆，就是三个高频查询动作：按线路查、按站点查、按起点终点换乘查。

按线路查询接口返回的信息最丰富，包括线路基本信息加途经站点列表。这一步的业务逻辑是先从line表查出线路，再根据line_id从line_station表查出站点排序列表，最后把站点名称拼接成有顺序的完整列表。注意这里不要循环查数据库，应该在Mapper层把关联表join起来一次查完，再在Java里组装。

按站点查询接口反过来，输入一个站点名，返回经过该站点的所有线路。这个功能的关键在于模糊搜索，SQL里用LIKE '%keyword%'就能实现，但要注意防止空参数查询，前端在传参前先做非空校验，后端也做一道校验。

换乘查询接口的核心逻辑我在上一节已经讲了，实际开发时要注意边界情况：起点站和终点站本身就是同一站、两个站点之间没有直达也没有换乘方案、输入的站点在数据库里不存在。这些情况接口都要返回明确提示，不能抛异常让前端白屏。

Controller层的代码骨架大概是这样的：

@ResponseBody @RequestMapping("/plan") public Result plan(String fromStation, String toStation) { if (StringUtils.isEmpty(fromStation) || StringUtils.isEmpty(toStation)) { return Result.error("起点和终点不能为空"); } List<TransferPlan> plans = transferService.findPlans(fromStation, toStation); return Result.ok(plans); }

4.2 前端页面的组件化设计

前端页面我建议分成首页、线路查询页、站点查询页、换乘规划页、收藏页、后台管理页这几个主要视图。

首页放一个醒目的搜索框，用户进来看得明白这个系统是干什么的。线路查询结果用卡片展示，每张卡片显示线路名和首末班时间，点击卡片展开完整站点列表。站点查询结果则用表格展示，列出经过该站的线路。

换乘规划页最有意思，输入起点和终点后，前端把后端返回的换乘方案渲染成“路线步骤条”：从A站上车，坐12路，到B站下车；同站换乘8路，到C站下车。这种可视化展示非常直观，答辩演示时一眼就能让人看懂系统的价值。

组件划分上，我建议把搜索框抽成公共组件，把线路卡片抽成公共组件，把换乘方案列表抽成公共组件。这样三个查询页面都能复用，代码量少，结构也清爽。Vue的组件化优势在这里体现得很明显，论文里也能截图展示你的组件树设计。

4.3 登录、收藏与个人中心实现

如果只做查询功能，项目会显得单薄，所以我建议加上用户登录和收藏线路功能。

用户注册登录用JWT做无状态鉴权。用户登录成功后，后端生成一个token返回给前端，前端存到localStorage里。每次请求时，axios拦截器自动把token放到Authorization请求头里。后端在SpringMVC拦截器里校验token，校验通过才放行受保护接口。

收藏功能的业务逻辑比较简单：用户点击收藏按钮，前端发送line_id和后端返回的收藏列表状态。个人中心页面展示我收藏的所有线路，点击可以查看线路详情，也可以取消收藏。

这个模块的价值在于让系统有了“登录用户”和“游客”两个角色，论文里的权限设计就有内容写了。否则全是匿名访问，权限控制这部分根本无从谈起。

5. 后台管理的权限设计与数据维护体系

5.1 管理员登录与Token鉴权

后台管理是给系统维护人员用的，功能包括线路管理、站点管理、线路站点关系维护。因为涉及数据修改，必须做权限控制。

管理员登录和管理员账号单独建一张表，密码不能明文存储，要用加密算法处理。登录成功同样返回JWT，但管理员token和普通用户token建议在同一个拦截器里区分角色，用不同的接口前缀隔离，比如管理员接口统一用/admin/**开头。

权限拦截器有个非常容易踩的坑：对于前端发来的AJAX请求，如果后端按传统方式直接重定向到登录页，前端拿到的会是一堆HTML，页面解析必然报错。正确的做法是后端统一返回JSON状态码401，前端在axios响应拦截器里判断到401后，再跳转登录路由。

5.2 线路与站点维护的交互设计

线路管理页面最核心的功能是维护一条线路经过的站点顺序。这个功能用简单的表格行输入法就能实现：管理员勾选站点名称，自动添加到列表末尾，然后通过上下移动按钮调整顺序。

这个交互虽然朴实，但要注意好数据后端保存的逻辑。前端保存时，要把整条线路的完整站点顺序一次性提交给后端，后端先删除旧的关联关系，再插入新的关联关系。这个操作必须放在一个事务里，要么全部成功，要么全部失败，否则就会出现“线路站点顺序一半新一半旧”的数据错乱问题。

站点管理相对简单，就是站点的增删改查。但站点数据会跟线路关联，删除站点前必须校验该站点是否被线路引用，如果被引用就要给管理员明确提示，不能直接删出脏数据。

5.3 初始化数据脚本：演示效果的关键

后台数据维护的逻辑不难，难的是准备一套能展示效果的初始化数据。很多同学把系统做完了，发现页面上什么都查不出来，就是因为没有数据。我建议写一个初始化SQL脚本，包含管理员账号、20条左右公交线路、300个左右站点、每条线路的完整经停站点顺序。

数据质量比数量更重要。换乘算法演示需要准备几条“特意设计”的线路：比如A线路和B线路在某一个站点相交，B线路和C线路在另一个站点相交，这样演示从A站点到C站点时，系统能显示出一次换乘甚至两次换乘的真实方案。

演示数据还有一个加载顺序问题：先导入站点，再导入线路，最后导入线路站点关联。如果线路还没建，直接插入关联数据就会外键失败。这个坑我见过不少同学踩到，写脚本时注意一下就能避免。

6. 论文撰写的章节规划：从需求分析到系统测试的闭环

6.1 论文章节与开发内容的对应关系

论文这部分，很多人习惯把代码写完再对着代码凑论文，结果写出来非常干瘪。我建议反过来，先把论文大纲定好，再对照大纲去积累开发过程素材。

一个完整的SSM加Vue系统论文，章节结构大致如下：

这套结构最怕的是前后矛盾。我帮人检查论文时，发现最多的问题就是“系统设计里画的表结构和实际建表SQL对不上”、“需求分析里的功能在实现章节里完全没提”。论文和程序必须像两条互相咬合的链子，每个功能都要能在需求、设计、实现、测试四个环节里找到对应位置。

6.2 需求分析和系统设计部分怎么写

需求分析不要罗列假大空的“系统可行性”，直接把用户角色拆清楚就行。本系统有两个角色：普通用户和管理员。普通用户需要线路查询、站点查询、换乘规划、收藏管理；管理员需要登录、线路维护、站点维护、站点顺序维护。每个用例写清楚前置条件、基本流程、异常流程，这样的需求分析才叫落地。

系统设计部分要重点画四张图：系统架构图、功能模块图、数据库E-R图、换乘算法流程图。不要求画得多精美，但逻辑必须严谨。尤其是E-R图，要体现出线路、站点、线路站点关联、用户、收藏这几者之间的关系，并和第三章的数据表设计一一对应。

换乘算法在“系统设计”阶段就应该定下来，而不是写代码的时候临时想。论文里写清楚“一次直达判断”、“一次换乘枚举”、“两次换乘枚举”三个步骤，再用伪代码表述出来，这一节的完整度就已经超过大量同类型毕设了。

6.3 实现与测试部分如何体现工作量

系统实现章节是最容易写成“功能说明书”的部分。我在前面反复强调过一个观点：不要贴一堆代码截图了事。正确的写法是：先说这个模块解决什么问题，再贴关键代码讲解设计思路，最后用运行截图展示效果。每个模块都按这个格式写，整体工作量感立刻就有了。

系统测试章节要有表格。建议准备一张测试用例表，把测试模块、测试步骤、预期结果、实际结果、是否通过这几列都列清楚。比如“输入不存在的站点，系统提示无结果”、“输入起点和终点相同，系统提示重新选择”，这些都是可执行、可验证的用例。再补上一组测试结果统计，说明系统通过了哪些测试、存在哪些限制，这一章就非常完整了。

7. 部署、测试与答辩准备：容易被忽略的加分项

7.1 环境版本与打包部署方案

部署环境我建议直接用本机演示，不推荐折腾云服务器。SSM项目对运行环境有一定要求，本地排查问题更快。推荐版本组合是JDK 1.8加Maven 3.6加MySQL 5.7，前端环境用Node.js 14以上版本。

后端打包用Maven打war包，放到Tomcat的webapps目录，启动Tomcat后自动解压发布。前端有两种部署方式：一种是用Nginx独立托管静态资源，反向代理到后端接口；另一种是把前端打包产物直接放到war包里，让Tomcat统一托管。如果答辩现场不想再开一个Nginx进程，我强烈推荐第二种，因为前后端同源部署能少处理一堆跨域问题。

前端打包后，把dist目录下的静态资源拷贝到war包对应的目录下，再重启Tomcat，一个地址就能同时访问前端页面和后端接口。这类系统面向的是单校区的验证环境，同源部署完全够用，还能减少很多现场演示的不确定性。

7.2 演示数据的准备

答辩现场最怕出现“查询结果为空”的尴尬。解决方式不是祈祷网络好、运气好，而是提前准备一套固定的演示脚本。把系统里最典型的一条线路名、一个换乘案例记住，现场直接输入。

比如事先算好“从文化广场到科技园南站”的最优方案是“坐12路到市民中心，同站换乘8路”，答辩时就输入这两个站点名。不要现场随机输地名，因为你根本不知道数据库里有哪些站点、哪些组合有换乘方案。这个准备工作花不了十分钟，但能让你在台上从容非常多。

初始演示数据里还要保证有一些“好看的数据形态”，比如某条线路有20多个站点，展开时页面列表很长，能展示系统的承载能力；再比如某个站点有七八条线路经过，能展示站点查询功能的丰富性。

7.3 答辩常见问题与应答思路

答辩环节老师最爱问的问题主要集中在框架原理和核心算法上，我把高频问题整理了一下：

这些问题的关键在于理解，不在于背答案。如果你真的动手写完了整个系统，每个问题都能结合自己的代码细节讲出来。比如讲MyBatis防注入，直接说我Mapper里传参全部用#{param}，避免字符串拼接；讲Vue响应式，直接说我页面里搜索框的数据是双向绑定的，输入同时更新视图。这种“结合自身项目”的回答，比背书上的定义要加分得多。

最后再分享一个我自己的体会：做完这个系统后，我对“SSM到底比Spring Boot多做了什么”这个问题有了真正具体的认知。手动配置过DispatcherServlet、SqlSessionFactory，你对一个请求从浏览器到达数据库再返回浏览器的完整链路，会比只写自动配置的人清楚得多。毕设最大的价值不在于题目新旧，而在于你有没有把它真正吃透。哪怕是一个看起来不算新颖的公交查询系统，只要数据库设计合理、换乘算法经得起推敲、前后端编码规范，论文和答辩都足以达到一份优秀毕设的标准。把这套思路走完，你会发现“论文加程序”并不是两个孤立的任务，而是一件事的两面。