SpringBoot校园拼车系统：从需求到部署的毕业设计全栈实践-平芜编程栈

简介：本资源是一套面向计算机专业本科生的毕业设计实战项目，基于SpringBoot框架开发校园拼车系统，聚焦高校学生短途出行场景，解决拼车信息发布、智能匹配、订单管理与用户评价等核心需求，适合Java Web开发初学者进阶实践。压缩包共201个文件，含96个Java后端逻辑类（涵盖Controller、Service、Mapper层）、34个HTML前端页面、14个XML配置与Mapper映射文件、14个JS交互脚本及8个CSS样式文件，辅以SQL建表语句、论文docx文档、application.yml配置及Maven构建脚本，完整覆盖前后端开发、数据库设计（MySQL）与学术文档撰写全流程，总大小6.04MB。已有122人学习下载。读者可直接导入IDEA运行调试，获得可部署的完整系统源码、符合规范的毕业论文模板、清晰分层的目录结构（含client静态资源与server服务模块），以及包含车辆管理、路线查询、预约拼车等6大功能模块的可验证业务逻辑。

1. 项目概述：为什么校园拼车是个“技术活”？

又到了一年一度的毕业季，相信不少计算机相关专业的同学正在为毕业设计选题发愁。选个太简单的，怕工作量不够，答辩时被老师问住；选个太前沿的，又担心技术栈太新，资料难找，最后做不出来。如果你正处在这个纠结期，那么“基于SpringBoot的校园拼车系统”这个题目，或许是一个兼顾了实用性、技术深度和可完成性的绝佳选择。我当年带过不少学生的毕设，也评审过很多项目，发现这个选题的出镜率相当高，但做出来的质量却参差不齐。今天，我就以一个过来人和技术评审的视角，跟你彻底拆解一下这个项目，从核心需求、技术选型到代码实现和论文撰写，把里里外外的门道都讲清楚，让你不仅能“抄作业”，更能理解背后的“解题思路”。

校园拼车，听起来不就是个发布信息、匹配乘客和司机的小程序吗？但真把它做成一个稳定、可用、安全的系统，里面涉及的技术点可一点都不少。它本质上是一个典型的O2O（线上到线下）平台，核心是解决信息不对称和资源匹配效率的问题。在校园这个特定场景下，用户群体相对固定（师生），出行路线规律（宿舍、教学楼、校门、车站），但需求又非常碎片化（时间、目的地各异）。你的系统需要像一个聪明的“调度员”，在安全合规的前提下，高效地把有车的人和需要坐车的人撮合到一起。这背后，SpringBoot作为快速开发框架，提供了坚实的脚手架；数据库设计决定了系统的扩展性和性能上限；而源代码的质量和论文的逻辑，则是你能否顺利通过答辩的关键。接下来，我们就一层层剥开这个项目的内核。

2. 核心需求与业务场景拆解

做任何软件项目，第一步永远是搞清楚“为谁做”和“做什么”。脱离场景谈功能，就是空中楼阁。校园拼车系统，首要服务对象就是在校学生和教职工，他们的核心诉求其实非常朴素：省钱、省时、安全、方便。

2.1 用户角色与核心诉求

一个完整的拼车系统至少需要区分两类核心用户：乘客和车主（司机）。他们的诉求截然不同：

乘客：核心诉求是“找到车”。他们关心的是：有没有去往我目的地的车？什么时候出发？价格是多少？车主靠不靠谱？上车地点方不方便？系统需要让他们能快速、精准地筛选和发布需求。
车主：核心诉求是“凑满人”。他们关心的是：有没有同路的乘客？能不能分摊油费？出发时间能不能协商？乘客的上下车地点顺不顺路？系统需要帮助他们高效地发布行程并匹配到合适的乘客。

此外，我们通常还需要一个管理员角色，负责审核用户/车辆信息、处理投诉、管理订单、监控系统运行等，这是保障平台秩序和安全的后盾。

2.2 关键业务流程与功能模块

基于用户诉求，我们可以梳理出几个最核心的业务流程，这些流程直接对应到你系统的功能模块：

用户旅程（注册-认证-使用）：用户注册后，必须进行实名认证（学生证/教工号绑定）和车主还需要进行车辆信息认证。这是安全底线，绝不能省。认证通过后，用户才能发布需求或行程。
信息发布与匹配流程：这是系统的灵魂。
- 车主发布行程：填写出发时间、起点、终点、座位数、每人单价、车型、是否接受协商等。
- 乘客发布需求：填写期望出发时间、起点、终点、人数、心理价位等。
- 智能匹配与搜索：系统应根据时间、起点、终点的相似度（这里涉及简单的路线匹配算法，如关键词匹配或预设热门地点），将行程和需求进行双向推荐。同时，必须提供强大的筛选和搜索功能，让用户能主动查找。
订单与支付流程：匹配成功后，生成订单。校园场景下，支付可以简化，初期支持线下支付（订单状态标记为“待支付”，上车后由车主确认“已支付”），但若要做得更规范，可以集成简单的第三方支付（如微信支付沙箱环境）或校园卡虚拟支付接口。订单状态机（待接单、已接单、进行中、已完成、已取消）的设计要清晰。
评价与信用体系：订单完成后，双方互评。这是构建平台信任的核心。基于评价可以构建简单的信用分体系，信用高的用户在匹配时享有优先级，这能有效激励双方保持良好的交易行为。

注意：很多初学者容易陷入“功能堆砌”的误区，比如一开始就想做即时通讯、复杂路径规划。我的建议是，MVP（最小可行产品）原则。先确保上述核心流程能跑通，再考虑锦上添花的功能。你的毕业设计演示，能把一个完整流程流畅地走下来，远比拥有十个半成品功能更有说服力。

3. 技术选型与架构设计思路

为什么是SpringBoot？因为它能让你避开复杂的传统SSH/SSM配置，快速搭建一个可独立运行、生产级别的Web应用。你的精力应该更多地放在业务逻辑，而不是XML配置和环境搭建上。

3.1 后端技术栈详解

核心框架：SpringBoot 2.x：建议选择2.7.x或3.x的稳定版本。SpringBoot的自动配置、内嵌Servlet容器（默认Tomcat）和“约定大于配置”的理念，能让你在几分钟内就启动一个Web服务。它整合了Spring MVC、Spring Data JPA/MyBatis等，一站式解决。
数据持久层：MyBatis-Plus：这是我强烈推荐的选择，而不是原始的MyBatis或JPA。MyBatis-Plus在MyBatis基础上做了强大的增强，提供了通用的Mapper和Service，单表CRUD操作你几乎不用写SQL。对于毕业设计这种以业务演示为主的项目，它能极大提升开发效率。当然，如果你对JPA和Hibernate更熟悉，使用Spring Data JPA也是完全可行的。
数据库：MySQL 8.0：关系型数据库的不二之选。校园拼车系统的数据关系（用户、行程、订单、评价）非常清晰，适合用关系模型来表述。8.0版本在性能、JSON支持和窗口函数上都有增强。
权限与安全：Spring Security + JWT：用户认证和授权是必须的。Spring Security功能强大但配置复杂。对于毕业设计，我建议采用JWT（JSON Web Token）实现无状态认证。用户登录后，服务器生成一个加密的Token返回给前端，前端后续请求在Header中携带此Token。这种方式比传统的Session更适用于前后端分离，也更简单。
缓存：Redis：虽然不是必须，但如果你想让项目亮点更多，可以引入Redis。用它来缓存热门行程信息、用户会话（即使用了JWT，也可以缓存一些高频访问的用户数据）、或者做简单的消息队列（用于异步处理订单状态更新等），能立刻提升项目的技术深度。
API文档：Swagger2 / Knife4j：用Swagger自动生成RESTful API文档，前后端联调和答辩演示时非常方便。Knife4j是Swagger的增强版UI，界面更友好，国产化，推荐使用。

3.2 前端技术选型建议

毕业设计对前端的要求通常不如后端高，但一个美观、交互良好的界面绝对是加分项。

方案一（推荐）：Vue.js + Element UI：Vue易于上手，生态丰富。Element UI是一套基于Vue 2.0的桌面端组件库，提供了丰富的现成组件（表格、表单、弹窗等），能让你快速搭建出风格统一、专业的管理后台和用户界面。
方案二：React + Ant Design：如果你或你的团队更熟悉React，那么Ant Design是同样优秀的企业级UI库。
方案三：Thymeleaf：如果你希望做一个更传统的、前后端不分离的项目（后端直接渲染HTML页面），SpringBoot官方推荐的模板引擎Thymeleaf是个选择。但这在当今前后端分离的主流趋势下，会显得技术栈有些陈旧。

3.3 系统架构草图

一个典型的前后端分离架构如下：

[用户浏览器] <--HTTP(S)--> [Nginx (反向代理/静态资源)] <--> [SpringBoot应用] <--> [MySQL] | <--> [Redis (可选)]

在开发阶段，你可以直接用SpringBoot内嵌的Tomcat，前端通过Vue CLI启动开发服务器，通过配置代理解决跨域问题。部署时，将Vue项目打包的静态文件（dist目录）放到Nginx下，Nginx将API请求转发给后端SpringBoot应用。

4. 数据库设计与核心表结构解析

数据库设计是系统的基石，设计得好，后期编码顺风顺水；设计得差，到处是坑。这里给出最核心的几张表及其字段设计思路。

4.1 核心实体关系分析

核心实体包括：用户(User)、行程/需求(Post)、订单(Order)、评价(Review)。它们之间的关系是：

一个用户可以是车主也可以是乘客。
一个用户（车主）可以发布多个行程，一个用户（乘客）可以发布多个需求。这里有两种设计思路：1) 用一张post表，用一个type字段区分是“行程”还是“需求”；2) 分成ride_post和request_post两张表。对于毕设，我建议用第一种，更简洁。
一个行程可以对应多个订单（因为一个行程有多个座位），一个订单只属于一个行程和一个乘客。
订单完成后，双方可以互评，产生两条评价记录。

4.2 关键表结构设计示例

以下SQL语句展示了核心表的结构（字段已简化，需根据实际情况扩展）：

-- 用户表 CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL UNIQUE COMMENT '用户名/学工号', `password` varchar(255) NOT NULL COMMENT '加密后的密码', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `avatar` varchar(500) DEFAULT NULL COMMENT '头像URL', `role` tinyint(4) NOT NULL DEFAULT '0' COMMENT '角色：0-乘客，1-车主，2-管理员', `driver_status` tinyint(4) DEFAULT '0' COMMENT '车主认证状态：0-未认证，1-审核中，2-已认证，3-认证失败', `id_card` varchar(100) DEFAULT NULL COMMENT '身份证号（加密存储）', `license_plate` varchar(20) DEFAULT NULL COMMENT '车牌号（车主专用）', `credit_score` int(11) DEFAULT '100' COMMENT '信用分，初始100', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB COMMENT='用户表'; -- 行程/需求发布表 CREATE TABLE `post` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` bigint(20) NOT NULL COMMENT '发布者ID', `type` tinyint(4) NOT NULL COMMENT '类型：1-行程（车主发），2-需求（乘客发）', `departure` varchar(255) NOT NULL COMMENT '出发地', `destination` varchar(255) NOT NULL COMMENT '目的地', `planned_time` datetime NOT NULL COMMENT '计划出发时间', `passenger_count` int(11) DEFAULT '1' COMMENT '乘客人数（type=1时，为空座位数；type=2时，为需求人数）', `price_per_person` decimal(10,2) DEFAULT NULL COMMENT '人均价格（车主发布时必填）', `status` tinyint(4) DEFAULT '1' COMMENT '状态：1-有效，2-已满员/已匹配，3-已取消，4-已完成', `remarks` text COMMENT '备注', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_user_id` (`user_id`), KEY `idx_time_route` (`planned_time`, `departure`, `destination`) -- 复合索引，加速查询 ) ENGINE=InnoDB COMMENT='行程/需求发布表'; -- 订单表 CREATE TABLE `order` ( `id` varchar(32) NOT NULL COMMENT '订单号（可使用雪花算法生成）', `post_id` bigint(20) NOT NULL COMMENT '对应的行程ID', `passenger_id` bigint(20) NOT NULL COMMENT '乘客ID', `driver_id` bigint(20) NOT NULL COMMENT '车主ID', `order_status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1-待确认，2-已确认，3-进行中，4-已完成，5-已取消', `actual_price` decimal(10,2) DEFAULT NULL COMMENT '实际成交价', `payment_status` tinyint(4) DEFAULT '0' COMMENT '支付状态：0-未支付，1-已支付', `payment_time` datetime DEFAULT NULL, `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_passenger_id` (`passenger_id`), KEY `idx_driver_id` (`driver_id`), KEY `idx_post_id` (`post_id`) ) ENGINE=InnoDB COMMENT='订单表'; -- 评价表 CREATE TABLE `review` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` varchar(32) NOT NULL COMMENT '关联订单ID', `from_user_id` bigint(20) NOT NULL COMMENT '评价者ID', `to_user_id` bigint(20) NOT NULL COMMENT '被评价者ID', `rating` tinyint(4) NOT NULL COMMENT '评分1-5', `comment` text COMMENT '评价内容', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_from_user` (`order_id`, `from_user_id`) -- 防止同一订单重复评价 ) ENGINE=InnoDB COMMENT='评价表';

实操心得：关于order.id，不建议使用数据库自增主键。因为订单号通常需要暴露给用户，自增ID有泄露业务量的风险。可以使用“时间戳+随机数”或者“雪花算法”生成一个字符串型的唯一ID。planned_time字段上建立复合索引，能极大提升按时间和路线查询行程的效率，这是系统最频繁的操作之一。

5. SpringBoot后端核心功能实现要点

有了清晰的数据模型，后端开发就是按部就班的“填空”。这里挑几个关键功能点，讲讲实现时需要注意的细节。

5.1 用户认证与JWT集成

引入依赖：在pom.xml中添加jjwt（Java JWT库）的依赖。

编写JWT工具类：这个类负责生成Token、解析Token、验证Token有效性。密钥务必放在配置文件中（如application.yml），不要硬编码在代码里。

@Component public class JwtTokenUtil { private String secret = "your-secret-key"; // 应从配置读取 private Long expiration = 86400000L; // 24小时 public String generateToken(UserDetails userDetails) { Map<String, Object> claims = new HashMap<>(); claims.put("sub", userDetails.getUsername()); claims.put("created", new Date()); return Jwts.builder() .setClaims(claims) .setExpiration(new Date(System.currentTimeMillis() + expiration)) .signWith(SignatureAlgorithm.HS512, secret) .compact(); } // ... 其他方法：验证Token、获取用户名等 }

实现登录接口：在AuthController中，接收用户名密码，调用UserService验证。验证通过后，使用JwtTokenUtil生成Token返回给前端。
配置请求拦截：创建一个JwtAuthenticationFilter，继承OncePerRequestFilter。在doFilterInternal方法中，从请求头（如Authorization: Bearer <token>）中提取Token并验证。验证通过后，将用户信息存入SecurityContextHolder，这样后续的Controller就能通过@AuthenticationPrincipal获取当前用户了。
配置Spring Security：在配置类中，放行登录、注册等公开接口，对其他接口启用认证过滤。

5.2 行程发布与智能匹配逻辑

这是业务核心。发布行程相对简单，主要是参数校验和数据入库。重点在“匹配”。

发布行程/需求：Controller接收前端传来的DTO（Data Transfer Object），如PostRequest，包含出发地、目的地、时间等。在Service层进行业务校验（如时间不能是过去时），然后通过MyBatis-Plus的PostMapper插入数据库。

智能匹配：这是一个可以深挖的亮点。最简单的匹配是基于关键词的模糊查询。

// 在PostService中 public List<Post> matchRides(PostRequest request) { // 1. 基础查询：查找类型相反（乘客找行程，车主找需求）、状态有效、时间相近的发布 QueryWrapper<Post> queryWrapper = new QueryWrapper<>(); queryWrapper.eq("type", request.getType() == 1 ? 2 : 1) // 类型相反 .eq("status", 1) // 状态有效 .ge("planned_time", request.getPlannedTime().minusHours(1)) // 时间范围：前后1小时 .le("planned_time", request.getPlannedTime().plusHours(1)) .like("departure", request.getDeparture()) // 出发地模糊匹配 .like("destination", request.getDestination()); // 目的地模糊匹配 // 2. 可以加入座位数/人数匹配条件 if (request.getType() == 2) { // 乘客找车，需要座位数>=需求人数 queryWrapper.ge("passenger_count", request.getPassengerCount()); } // 3. 按时间、信用分等排序 queryWrapper.orderByAsc("planned_time").orderByDesc("(SELECT credit_score FROM user WHERE id = post.user_id)"); return postMapper.selectList(queryWrapper); }

更高级的匹配可以引入路线相似度计算，比如将地点解析为经纬度（需要集成地图API），计算两点间距离；或者使用Elasticsearch进行全文检索和更复杂的相关性排序。对于毕设，实现基础模糊查询加上一两个亮点（如按车主信用分排序）就足够了。

5.3 订单状态机与并发控制

订单状态流转是保证业务逻辑正确的关键。务必在Service层实现一个清晰的状态机。

@Service public class OrderService { @Transactional(rollbackFor = Exception.class) // 重要：开启事务 public boolean confirmOrder(String orderId, Long driverId) { Order order = orderMapper.selectById(orderId); if (order == null || !order.getDriverId().equals(driverId)) { throw new BusinessException("订单不存在或无权操作"); } // 状态机校验：只有“待确认”的订单才能被确认 if (order.getOrderStatus() != OrderStatus.WAITING_CONFIRM.getCode()) { throw new BusinessException("订单当前状态不允许确认"); } // 检查行程是否已满员（需要在PostService中维护已占座位数） Post post = postService.getById(order.getPostId()); if (post.getOccupiedSeats() >= post.getPassengerCount()) { throw new BusinessException("行程已满员"); } // 更新订单状态 order.setOrderStatus(OrderStatus.CONFIRMED.getCode()); orderMapper.updateById(order); // 同步更新行程的已占座位数 postService.incrementOccupiedSeats(order.getPostId()); return true; } }

踩坑提醒：这里有一个经典的并发问题：多个乘客同时确认同一个行程的最后一个座位，可能导致超卖。上述代码在事务内查询和更新，能在数据库隔离级别为“可重复读”（MySQL默认）时防止大部分问题，但更严谨的做法是使用乐观锁（在post表加一个version字段）或者悲观锁（SELECT ... FOR UPDATE）。对于毕设，你可以指出这个风险，并简要说明解决方案，这能体现你的思考深度。

6. 前端Vue.js关键页面与组件实现

前端是实现用户交互的界面。我们以几个核心页面为例，说明如何与后端对接。

6.1 首页与行程列表页

这是用户的第一印象。核心组件是一个行程列表卡片。

组件设计：使用Element UI的Card和List组件。每个卡片展示一条行程的核心信息：出发地/目的地、时间、价格、车主头像和信用分、剩余座位数。
数据获取：在Vue组件的mounted或使用onMounted（Vue 3）生命周期钩子中，调用axios向后端/api/posts发起GET请求，携带查询参数（如出发地、目的地、时间范围）。
筛选与搜索：在页面顶部放置一个表单，包含输入框和选择器。使用Vue的v-model绑定查询参数，当点击“搜索”按钮时，重新调用数据获取方法。

6.2 发布行程/需求模态框

这是一个表单密集的组件，适合用Element UI的Dialog和Form。

表单验证：务必使用Element UI Form的rules属性进行前端验证。例如，出发地/目的地不能为空，时间必须是将来的时间，价格必须大于0。
数据提交：表单验证通过后，将表单数据组装成一个对象，通过axios.post(‘/api/posts’, postData)提交。记得在请求头中带上JWT Token。
用户体验：提交成功后，关闭模态框，并给出一个Message.success(‘发布成功！’)的提示，同时刷新行程列表。

6.3 个人中心与订单管理页

这个页面通常使用Tabs组件来切换“我发布的”、“我参与的订单”、“我的评价”等。

状态展示：订单状态（如“待确认”、“进行中”）可以用Element UI的Tag组件，配上不同颜色，一目了然。
操作按钮：根据订单状态动态显示操作按钮。例如，“待确认”的订单，车主可以看到“确认接单”按钮，乘客可以看到“取消订单”按钮。点击按钮后调用对应的后端接口。
路由与参数传递：使用Vue Router管理页面跳转。例如，从订单列表点击某个订单，跳转到订单详情页，可以通过路由参数/order/:id传递订单ID，在详情页组件中通过this.$route.params.id获取并请求数据。

7. 论文撰写核心要点与结构指南

毕业论文是你整个工作的总结和升华。代码写得好，论文说不清，一样会吃亏。技术类毕业论文有相对固定的结构，但切忌写成流水账。

7.1 摘要与结论怎么写

摘要：这是老师最先看的部分。用300-500字概括全文精华。必须包含：研究背景与意义（校园出行难、资源利用率低）、系统目标（设计并实现一个安全高效的拼车系统）、采用的关键技术（SpringBoot、MyBatis-Plus、Vue.js、MySQL）、完成的主要工作（包括需求分析、设计、实现、测试）以及最终成果（系统具备哪些功能，达到了什么效果）。避免在摘要中出现“本文”、“笔者”等词，直接陈述事实。
结论：总结整个项目工作，重申系统实现的价值。然后一定要写“不足与展望”！这是体现你批判性思维的地方。可以写：当前匹配算法较为简单，未来可引入智能推荐算法；支付功能仅模拟实现，未来需集成真实支付接口；未开发移动端APP，未来可考虑用Uni-app跨端开发等。

7.2 系统设计章节如何出彩

这是论文的技术核心，不要只贴代码和ER图。

架构设计：画出前后端分离的系统架构图（可以用Visio或draw.io），并解释每一层的职责。说明为什么选择这种架构（松耦合、易于扩展、前后端并行开发）。
数据库设计：给出完整的ER图，并重点阐述核心表的设计思路和字段含义，特别是像post表的type字段设计选择、订单状态枚举的设计、索引的设置原因（如前文提到的idx_time_route）。这能证明你不是简单地建了几个表。
关键模块详细设计：选择2-3个核心模块深入写，比如“基于JWT的无状态认证模块”、“行程发布与智能匹配模块”、“订单状态机与并发控制模块”。用时序图或活动图来展示模块内部或模块间的交互流程，比大段文字描述清晰得多。然后配合核心代码片段（注意排版整洁）和文字说明。

7.3 系统实现与测试章节

实现环境：列出你的开发工具（IDEA、VS Code）、运行环境（JDK 11、Node.js 16）、数据库版本等。
核心界面与功能展示：截图！截图！截图！重要的事情说三遍。首页、发布页、个人中心、管理后台等关键界面，配上简洁的文字说明。功能演示要连贯，比如从发布行程到生成订单再到完成评价，用一组截图串起来。
系统测试：不要只写“进行了测试，系统稳定”。要写具体怎么测的。
- 功能测试：设计测试用例表，包括测试项、操作步骤、预期结果、实际结果。例如，“测试用例1：用户成功注册并登录”。
- 性能测试（可选，但很加分）：使用JMeter或Postman Runner对关键接口（如行程列表查询）进行压力测试，记录在并发用户数为50、100时，接口的响应时间和成功率。即使数据不完美，这个过程本身就能体现你的工程素养。
- 安全考虑：阐述你已考虑的安全措施，如密码加密存储（BCrypt）、SQL注入防护（MyBatis-Plus已使用预编译语句）、XSS防护（对用户输入进行转义或使用前端框架的默认防护）、接口权限验证等。

8. 项目部署与答辩准备实战

8.1 本地与服务器部署要点

开发完成后，你需要让老师在答辩时能访问到一个运行中的系统。

后端打包：在SpringBoot项目的根目录下，使用Maven命令mvn clean package -DskipTests，会在target目录生成一个*.jar文件。
前端打包：在Vue项目目录下，运行npm run build，生成dist文件夹。
服务器准备：购买一台最基础的云服务器（学生常有优惠）。安装JDK、MySQL、Nginx。
部署后端：将jar包上传到服务器。可以使用nohup java -jar your-project.jar &命令在后台运行。更规范的做法是创建一个systemd服务来管理。

部署前端：将dist文件夹内的所有文件上传到服务器某个目录（如/var/www/html）。配置Nginx，将根目录指向该文件夹，并设置一个location /api/的反向代理，将所有以/api开头的请求转发到后端SpringBoot应用（默认运行在8080端口）。

server { listen 80; server_name your-domain.com; # 或服务器IP location / { root /var/www/html; index index.html; try_files $uri $uri/ /index.html; # 支持Vue Router的history模式 } location /api/ { proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

配置数据库：在服务器MySQL中创建同名数据库，导入你本地的SQL脚本。

8.2 答辩演示与问答准备

答辩时，老师看的是你的思路、完成度和表达能力。

演示脚本：提前写好一个5-10分钟的演示脚本。从打开系统首页开始，以一条完整的用户路径（例如：注册 -> 登录 -> 发布行程 -> 另一个账号登录并下单 -> 确认订单 -> 完成支付 -> 双方互评）来展示。操作要流畅，边操作边讲解。
准备问答：提前思考老师可能会问的问题，并准备好答案。常见问题包括：
- 技术相关：“为什么用SpringBoot不用SSM？”（答：简化配置，快速开发，内嵌容器便于部署）。“你的匹配算法是怎么实现的？有什么缺点？”（答：目前基于关键词和时间的模糊查询，优点是简单快速，缺点是不够智能，未来可引入路径规划算法）。
- 业务相关：“如何保证拼车安全？”（答：实名认证、信用评价体系、行程分享功能、虚拟号码沟通等）。“如果车主临时取消行程怎么办？”（答：在订单状态机中设计取消逻辑，扣除车主信用分，并通知已接单乘客）。
- 扩展相关：“你这个系统还有什么可以改进的地方？”（这就是你论文“展望”部分的内容，从容回答即可）。
代码与论文一致性：确保你演示的系统功能，和论文里描述的功能是一致的。老师可能会随机抽查某个功能的代码，所以要对关键代码的位置了如指掌。

最后，记住毕业设计的核心是“展示你学会了什么”，而不是“做了一个多完美的产品”。抓住SpringBoot的核心应用、数据库的合理设计、一个完整业务流程的实现以及清晰的论文表述，你就已经成功了一大半。这个项目做下来，你对一个典型Web应用的前后端开发全流程会有非常扎实的体会，这本身就是最大的收获。祝你答辩顺利！

本文还有配套的精品资源，点击获取