简介这是一份面向毕业设计的SpringBoot校园拼车系统资料包整合了源代码、数据库与论文适合作为毕设蓝本或框架实战案例。项目聚焦大学生拼车出行场景围绕用户注册登录、车辆信息维护、路线发布与查询、拼车预约、订单评价等模块展开覆盖从需求分析、系统设计、编码实现到数据库建模、论文撰写的完整开发链路。压缩包内共201个文件以Java源码、HTML页面、XML配置、JS/CSS前端资源为主另含SQL数据库脚本、jar依赖、yml/properties配置文件以及docx版毕业论文文档整体大小6.04MB目录分类清晰方便按后端业务、前端视图和文档材料分区查阅。已有124人学习浏览适合希望快速上手SpringBoot项目开发、需要毕业设计参考范本的计算机专业学生。通过本包可获得可运行的工程代码、数据库建表脚本与成稿论文既能直接部署体验一套完整系统又能从代码结构和论文章节中借鉴项目规划与写作思路显著节省毕业设计前期准备时间。1. 基于SpringBoot的校园拼车系统一套能跑通闭环的毕设源码基于 SpringBoot 的校园拼车系统是我最近完整拆过的一套毕业设计资源后端是 Spring Boot MySQL附带数据库脚本和论文。拆完我的第一印象是它没有堆砌高大上的组件但把拼车这个业务从发布路线、搜索匹配、发起拼单到订单确认的闭环完整走通了这在毕设源码里其实不算多见。适合两类人一是马上交毕设但后端还写不顺的在校生想找一套结构清楚、能本地跑起来的参考工程二是想借真实业务练手 SpringBoot 项目组织方式的初学者。下面从项目结构、表设计、核心接口、部署排错四个维度往下拆尽量做到你拿到当天能跑起来跑起来之后还能讲清楚每一处设计。2. 项目骨架与SpringBoot核心设计分层结构、JWT认证与拦截器2.1 先看项目结构这个包的划分方式基本决定了好不好改拿到这套源码我先不急着启动而是先把src/main/java下面的包结构过了一遍。它的分包方式是毕设项目里比较标准的写法controller、service、mapper、entity、config、common各司其职。这种分层的价值在于你答辩时被问到订单状态在哪里改的可以直接定位到service/impl而不是在几百行的 Controller 里翻。src/main/java/com/example/carpool ├── CarpoolApplication.java // 启动类 ├── config │ ├── WebMvcConfig.java // 注册拦截器配置跨域 │ └── JwtInterceptor.java // Token 校验拦截器 ├── controller │ ├── AuthController.java // 登录注册接口 │ ├── RideController.java // 发布拼车、搜索拼车 │ └── OrderController.java // 发起拼单、取消订单 ├── service │ ├── RideService.java │ └── impl │ └── RideServiceImpl.java ├── mapper │ ├── UserMapper.java │ ├── RideMapper.java │ └── OrderMapper.java ├── entity │ ├── User.java │ ├── Ride.java │ └── Order.java └── common ├── Result.java // 统一返回体 └── JwtUtil.java // JWT 生成与解析逻辑说明Result.java是这套源码里很值得学的一个小类所有接口都返回{code, message, data}这个结构前端只需要统一处理一次响应。JwtUtil负责生成和解析 Token登录成功之后把用户 ID 塞进 Token后续请求通过JwtInterceptor从请求头里取出来。参数说明这套代码里 JWT 的过期时间一般设置在 30 分钟到 2 小时之间具体在JwtUtil里有个常量改成3600000就是 1 小时。如果上线部署建议把密钥放到application.yml里而不是硬编码在类里。2.2 认证链路怎么走的从登录到放行的完整流程看一个毕设项目质量好不好最快的方式是先看它的拦截器配置。这套源码用的是WebMvcConfig里注册拦截器并配置放行路径属于常见做法。我把核心逻辑抽出来讲。// config/WebMvcConfig.java Configuration public class WebMvcConfig implements WebMvcConfigurer { Resource private JwtInterceptor jwtInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns(/api/**) // 拦截所有 /api 下的请求 .excludePathPatterns(/api/auth/login, /api/auth/register); // 放行登录注册 } }逻辑说明addPathPatterns(/api/**)表示拦截所有以/api开头的接口而登录和注册接口通过excludePathPatterns放行。这个设计思路是一个用户没登录之前唯一能做的事就是登录和注册其他所有业务接口都要经过 Token 校验。搜拼车、下单、取消订单这些接口全部走拦截器。// config/JwtInterceptor.java public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 从 Token 中解析出用户 ID放入 request 属性后续接口直接使用 Integer userId JwtUtil.getUserId(token); request.setAttribute(userId, userId); return true; } }逻辑说明这段代码有两个关键点。第一Token 放在请求头Authorization里前端每次请求都要带上否则直接返回 401第二校验通过后从 Token 里解析出userId放进request属性后续 Controller 方法里直接用(Integer) request.getAttribute(userId)就能拿到当前登录用户不用每次查库。参数说明JwtUtil.verify()内部会用密钥去解析 Token如果 Token 被篡改或者过期解析会抛出异常这里返回 false 之后前端会收到 401然后自动跳回登录页。这套认证设计的优点在于够用。毕业设计不需要引入 Spring Security 那一整套过滤器链JWT 拦截器既能在论文里讲清楚代码量也少出问题还好排查。3. 拼车的核心数据模型六张业务表与座位扣减的SQL细节3.1 表结构设计从用户到订单字段是怎么关联起来的数据库脚本是这套资源里含金量比较高的部分。拼车业务对比普通的商品交易多了一个路线和座位的概念。我把它拆成六张核心业务表来理解。表名作用关键字段user用户表id, username, password, phone, student_nocar车辆信息表id, user_id, plate_no, brand, seat_countride拼车路线表发布的车次id, user_id, car_id, start_point, end_point, start_time, total_seats, remain_seats, priceorders拼车订单表id, ride_id, user_id (乘客), seat_count, order_status, create_timecomment评价表id, order_id, from_user_id, to_user_id, rating, contentmessage消息通知表id, from_user_id, to_user_id, content, is_read这里我建议你重点看ride表的total_seats和remain_seats两个字段。total_seats是这条车次总共提供的座位数remain_seats是当前剩余座位数。每次有人下单remain_seats就要减掉对应座位数有人取消订单remain_seats加回来。-- 核心建表语句简化版 CREATE TABLE ride ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL COMMENT 车主用户ID, car_id int NOT NULL COMMENT 车辆ID, start_point varchar(100) NOT NULL COMMENT 出发地, end_point varchar(100) NOT NULL COMMENT 目的地, start_time datetime NOT NULL COMMENT 出发时间, total_seats int NOT NULL DEFAULT 4 COMMENT 总座位数, remain_seats int NOT NULL DEFAULT 4 COMMENT 剩余座位数, price decimal(10,2) NOT NULL COMMENT 每人价格, status tinyint DEFAULT 1 COMMENT 1进行中 2已结束 3已取消, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明status字段用来标记车次状态只有status1的车次才能被搜索到。remain_seats是拼车系统的核心所有下单逻辑都围着它转。price用decimal(10,2)而不是float是为了避免金额精度问题这个细节可以写进论文里。参数说明total_seats默认给 4对应普通轿车除去司机后的座位数。如果你的场景是校园拼车大部分是 4 座或 5 座车改这个默认值即可。start_time用datetime类型如果你希望支持按时间范围筛选可以在查询条件里对start_time做BETWEEN。3.2 座位扣减的SQL细节条件更新避免超卖拼车系统最容易出问题的地方就是两个人同时下单最后一个座位被两个人抢到。为了解决这个问题源码里用的是条件更新的方式这也是我建议你答辩时重点讲的一个点。-- 下单时扣减座位只有剩余座位足够时才更新成功 UPDATE ride SET remain_seats remain_seats - 1 WHERE id #{rideId} AND remain_seats 1 AND status 1;逻辑说明这条 SQL 的关键在WHERE条件里的remain_seats 1。MySQL 执行更新时会锁住这一行两个并发请求同时进来第二个请求执行时remain_seats已经被第一个请求扣成 0 了remain_seats 1不成立更新行数为 0。代码里只要判断int rows rideMapper.updateRemainSeats(rideId);的返回值等于 1 说明扣成功等于 0 说明没座位了直接返回拼车已满。-- 取消订单时返还座位 UPDATE ride SET remain_seats remain_seats 1 WHERE id #{rideId};逻辑说明返还座位的 SQL 相对简单但注意一个边界条件如果拼车已经发车了是不允许取消订座和返还座位的。所以真正写业务代码时取消订单前要先查订单状态和车次状态只有orders.order_status 0已下单未出发且ride.start_time now()时才做返还操作。我实际跑这套 SQL 时踩过一个坑数据库脚本里remain_seats的注释写的是剩余座位数但初始化的INSERT语句里直接写死了几条车次的remain_seats如果某条车次之前被测试数据扣减过后面再用就会对不上。所以建议你导入脚本后先把所有ride表的remain_seats重置成total_seats保证起点干净。4. 从发布到成单核心接口闭环与事务边界4.1 发布拼车接口参数校验比业务逻辑更值得抄发布拼车是整条业务链路的起点。我先看了RideController的发布接口再找到RideServiceImpl的实现发现它的参数校验做得比较完整——这对答辩来说是个加分点。// controller/RideController.java PostMapping(/api/ride/publish) public Result publish(RequestBody RideDTO dto, HttpServletRequest request) { Integer userId (Integer) request.getAttribute(userId); // 参数校验 if (dto.getStartPoint() null || dto.getEndPoint() null) { return Result.error(出发地和目的地不能为空); } if (dto.getStartTime() null || dto.getStartTime().isBefore(LocalDateTime.now())) { return Result.error(出发时间必须晚于当前时间); } if (dto.getTotalSeats() null || dto.getTotalSeats() 1 || dto.getTotalSeats() 6) { return Result.error(座位数必须在1到6之间); } if (dto.getPrice() null || dto.getPrice().doubleValue() 0) { return Result.error(价格必须大于0); } return rideService.publish(userId, dto); }逻辑说明request.getAttribute(userId)拿到的就是在拦截器里解析出来的当前登录用户 ID。校验里有两个细节我特别提一下一是startTime.isBefore(LocalDateTime.now())判断出发时间不能在过去这避免用户发布一条历史车次二是totalSeats限制在 1 到 6因为校园拼车场景下一般不会出现超过 6 座的车这个参数可以按实际车辆调整。// service/impl/RideServiceImpl.java Transactional public Result publish(Integer userId, RideDTO dto) { Ride ride new Ride(); ride.setUserId(userId); ride.setStartPoint(dto.getStartPoint()); ride.setEndPoint(dto.getEndPoint()); ride.setStartTime(dto.getStartTime()); ride.setTotalSeats(dto.getTotalSeats()); ride.setRemainSeats(dto.getTotalSeats()); // 初始剩余座位等于总座位 ride.setPrice(dto.getPrice()); ride.setStatus(1); rideMapper.insert(ride); return Result.success(发布成功, ride.getId()); }逻辑说明Transactional注解表示这个方法整体在一个事务里后续如果还有插入车辆、生成消息通知等操作任何一个失败都会整体回滚。remainSeats初始值直接等于totalSeats不需要额外计算。这里的ride.getId()会返回自增主键方便前端拿到车次 ID 后跳转到详情页。4.2 发起拼单接口先扣座位再插订单顺序不能反发起拼单是拼车系统里逻辑最密集的接口。我拆的时候特意关注了它的执行顺序先扣座位再插入订单最后处理事务提交。这个顺序搞反的话会出现订单有了座位没扣的数据不一致。// service/impl/OrderServiceImpl.java Transactional public Result createOrder(Integer userId, Integer rideId, Integer seatCount) { if (seatCount null || seatCount 1) { return Result.error(拼座数量至少为1); } // 1. 先尝试扣减座位返回影响行数 int rows rideMapper.deductSeats(rideId, seatCount); if (rows 0) { return Result.error(座位不足拼车失败); } // 2. 扣减成功后再创建订单 Order order new Order(); order.setRideId(rideId); order.setUserId(userId); order.setSeatCount(seatCount); order.setOrderStatus(0); // 0待出发1已完成2已取消 order.setCreateTime(LocalDateTime.now()); orderMapper.insert(order); return Result.success(拼车成功, order); }逻辑说明第一步调用rideMapper.deductSeats(rideId, seatCount)这条 SQL 就是第三章里的条件更新语句只不过把- 1改成了- #{seatCount}同时条件改成remain_seats #{seatCount}。如果更新行数为 0直接抛业务错误返回不再执行后续插入。这种做法的好处是座位校验和扣减在一条 SQL 里完成避免了先查剩余座位再更新带来的并发问题。参数说明seatCount表示这个乘客预订几个座位默认传 1 即可。如果之后要支持替室友一起拼座的场景这个字段可以大于 1但要注意deductSeats的条件必须同步改成remain_seats #{seatCount}。这里我要特别提醒一个事务陷阱Transactional默认只对RuntimeException回滚。如果rideMapper.deductSeats返回 0 行你用的是return Result.error(...)而不是抛异常那么已经执行的数据库操作不会回滚。好在这套逻辑里扣减失败时还没执行任何写操作所以没问题。但如果你在扣减座位之前先插入了订单然后再扣减座位扣减失败时订单插入不会自动回滚那就必须手动抛出异常或者在代码里判断后再删除订单。4.3 搜索拼车线路动态SQL与时间过滤搜索接口是使用频率最高的接口它的实现逻辑不算复杂但有一个值得留意的点前端传过来的出发地、目的地、出发时间都可能为空所以要用动态 SQL 来拼查询条件。// mapper/RideMapper.java ListRide searchRides(Param(startPoint) String startPoint, Param(endPoint) String endPoint, Param(startTime) LocalDateTime startTime);!-- mapper/RideMapper.xml -- select idsearchRides resultTypecom.example.carpool.entity.Ride SELECT * FROM ride WHERE status 1 if teststartPoint ! null and startPoint ! AND start_point LIKE CONCAT(%, #{startPoint}, %) /if if testendPoint ! null and endPoint ! AND end_point LIKE CONCAT(%, #{endPoint}, %) /if if teststartTime ! null AND start_time gt; #{startTime} /if ORDER BY start_time ASC /select逻辑说明if标签是 MyBatis 动态 SQL 的核心它让查询条件按需拼接。startPoint和endPoint用LIKE模糊匹配适应南门北门教学楼这类用户输入不精确的场景startTime用过滤掉已经出发的车次。ORDER BY start_time ASC让最早出发的车次排最前面这是个合理的产品决策——用户找拼车肯定是想找最近出发的。参数说明gt;是 XML 里的转义写法如果你直接写会导致 XML 解析报错这是 MyBatis 新手很容易翻车的地方。如果不想写转义符也可以把时间过滤条件放到 Java 代码里判断在 XML 里只处理不为空的字段。5. 部署与常见问题排查五个必踩的坑与解决路径这一章是我把整套源码导入本地、按正常顺序跑起来之后整理的踩坑记录基本覆盖了毕设项目最常见的五类问题。每条按现象 → 原因 → 解决来写你可以直接对照排查。5.1 启动直接报错数据库连接失败现象Spring Boot启动时控制台报Cannot create PoolableConnectionFactory或者Access denied for user rootlocalhost应用启动失败。原因application.yml里的数据库地址、用户名、密码和本地 MySQL 不一致。常见的坑是密码错误或者 MySQL 版本是 8.0 但驱动配置用了 5.x 的写法。解决先确认 MySQL 能正常登录再逐项检查application.yml里的url、username、password三项。MySQL 8.0 的 URL 需要加serverTimezoneAsia/Shanghai否则会报时区错误驱动改成com.mysql.cj.jdbc.Driver。改完重启即可。5.2 数据库脚本导入报错SQL文件执行不过去现象用 Navicat 或命令行导入项目附带的.sql文件时中途报错停住比如Unknown collation: utf8mb4_0900_ai_ci。原因项目里给的 SQL 脚本是在 MySQL 8.0 上导出的建表语句里的utf8mb4_0900_ai_ci排序规则在 MySQL 5.7 里不存在。解决用文本编辑器打开 SQL 文件全局替换utf8mb4_0900_ai_ci为utf8mb4_general_ci然后再重新导入。如果你本地就是 MySQL 8.0可以不用改。这个坑非常典型很多同学卡在第一步导入脚本上实际上就是这个排序规则的问题。5.3 前端登录后请求接口全部 401现象登录接口能通但登录后访问拼车列表、发布拼车等接口全部返回 401前端页面拿不到数据。原因登录接口返回的 Token 没有存到前端本地或者后续请求没有在请求头里带上Authorization。也有一种情况是前端用了 axios但没有在拦截器里统一设置headers。解决在浏览器 F12 的 Network 面板里看请求头如果请求头里没有Authorization就是前端的问题。常见做法是在 axios 请求拦截器里加一行config.headers[Authorization] localStorage.getItem(token)。如果是跨域导致请求头被浏览器拦了还要在后端配置CorsFilter允许携带认证信息WebMvcConfig里加一个CorsRegistry配置。5.4 拼车接口报座位不足但数据明明有座位现象测试下单时数据库里remain_seats明明还有 2 个座位但下单接口一直提示座位不足。原因大概率是你之前测试过下单流程订单表里已经有这条ride_id的记录但座位被扣减后没有正确返还导致remain_seats已经小于seatCount。还有一种情况是并发测试时两个请求同时进来后一个请求在条件更新时失败。解决先查ride表的remain_seats实际值对比orders表里未取消的订单总数确认数据是否一致。如果只是测试数据乱了直接把ride.remain_seats重置为total_seats把orders表清空再重新测。想真正验证并发问题可以用两个浏览器同时登录两个账号对同一车次下单观察只有一个能成功。5.5 SpringBoot版本过高导致依赖冲突现象项目导入 IDEA 后Maven 一直下载依赖下载完成后启动报ClassNotFoundException: javax.servlet.Filter或者Failed to configure a DataSource。原因源码配的 SpringBoot 版本可能和你本地环境不一致。比如源码用的是 Spring Boot 2.3.x你本地 IDEA 默认创建的是 Spring Boot 3.x而 3.x 把javax.servlet换成了jakarta.servlet旧代码直接编译过不去。解决打开pom.xml把spring-boot-starter-parent的版本改成和源码配套的版本一般 2.5.x 或 2.7.x 都比较稳。改完Ctrl Shift O重新导入 Maven 依赖。这个坑在毕设里出现频率极高本质是版本升级带来的包名变更。我的建议是不要用太新的 SpringBoot 跑旧源码2.7 是兼容性最好的一个版本线。6. 验收与进阶把毕设变成自己的作品源码跑通只是第一步答辩时老师真正想听的是你做了什么。我建议你从两个方向准备先按我的验收链路走一遍全流程再做一处源码改造这样项目就能讲成自己的了。验收链路分七步注册两个账号一个车主、一个乘客→ 车主登录后发布一条拼车路线 → 乘客搜索到这条路线 → 乘客发起拼单并支付如果有模拟支付→ 双方都能在订单列表看到记录 → 车主确认发车 → 行程结束后乘客评价。每一步都在前端页面操作一遍同时在后端打开 SQL 日志观察对应 SQL 的执行。这套流程走完你对项目的理解会比只跑起来深刻得多。进阶改造方面我推荐一个改动量不大但讲起来很有亮点的方向把拼车搜索从模糊匹配升级为顺路推荐。原逻辑只按start_point和end_point做模糊匹配你可以在RideService里加一个方法把用户常用的出发地和目的地存到user表的新字段里搜索时优先返回和自己历史路线相似度高的车次。技术上就是多一个LIKE条件加一个排序字段但业务上变成了智能推荐论文里能多写两页。// 进阶按历史路线优先排序的搜索 SELECT r.*, CASE WHEN r.start_point #{myStart} AND r.end_point #{myEnd} THEN 0 WHEN r.start_point #{myStart} THEN 1 ELSE 2 END AS match_score FROM ride r WHERE r.status 1 ORDER BY match_score ASC, r.start_time ASC;逻辑说明CASE WHEN是 SQL 里的条件表达式这里用来计算顺路程度。完全匹配的历史路线排在最前只匹配出发地的排第二其他的排在最后。这个改动不需要动表结构只改一条查询语句但你能讲清楚我做了用户偏好分析。从那以后我每次拆毕设源码都强制自己先走一遍完整验收链路再动手改代码——先证明它原本是通的再谈改进。这套基于 SpringBoot 的校园拼车系统结构清楚、坑也足够典型很适合作为你第一个完整跑通的 SpringBoot 项目。希望这篇拆解能帮你少走点弯路也希望你改完的每一个功能都能在答辩的时候理直气壮地说这是我写的。本文还有配套的精品资源点击获取
简介这是一份面向毕业设计的SpringBoot校园拼车系统资料包整合了源代码、数据库与论文适合作为毕设蓝本或框架实战案例。项目聚焦大学生拼车出行场景围绕用户注册登录、车辆信息维护、路线发布与查询、拼车预约、订单评价等模块展开覆盖从需求分析、系统设计、编码实现到数据库建模、论文撰写的完整开发链路。压缩包内共201个文件以Java源码、HTML页面、XML配置、JS/CSS前端资源为主另含SQL数据库脚本、jar依赖、yml/properties配置文件以及docx版毕业论文文档整体大小6.04MB目录分类清晰方便按后端业务、前端视图和文档材料分区查阅。已有124人学习浏览适合希望快速上手SpringBoot项目开发、需要毕业设计参考范本的计算机专业学生。通过本包可获得可运行的工程代码、数据库建表脚本与成稿论文既能直接部署体验一套完整系统又能从代码结构和论文章节中借鉴项目规划与写作思路显著节省毕业设计前期准备时间。1. 基于SpringBoot的校园拼车系统一套能跑通闭环的毕设源码基于 SpringBoot 的校园拼车系统是我最近完整拆过的一套毕业设计资源后端是 Spring Boot MySQL附带数据库脚本和论文。拆完我的第一印象是它没有堆砌高大上的组件但把拼车这个业务从发布路线、搜索匹配、发起拼单到订单确认的闭环完整走通了这在毕设源码里其实不算多见。适合两类人一是马上交毕设但后端还写不顺的在校生想找一套结构清楚、能本地跑起来的参考工程二是想借真实业务练手 SpringBoot 项目组织方式的初学者。下面从项目结构、表设计、核心接口、部署排错四个维度往下拆尽量做到你拿到当天能跑起来跑起来之后还能讲清楚每一处设计。2. 项目骨架与SpringBoot核心设计分层结构、JWT认证与拦截器2.1 先看项目结构这个包的划分方式基本决定了好不好改拿到这套源码我先不急着启动而是先把src/main/java下面的包结构过了一遍。它的分包方式是毕设项目里比较标准的写法controller、service、mapper、entity、config、common各司其职。这种分层的价值在于你答辩时被问到订单状态在哪里改的可以直接定位到service/impl而不是在几百行的 Controller 里翻。src/main/java/com/example/carpool ├── CarpoolApplication.java // 启动类 ├── config │ ├── WebMvcConfig.java // 注册拦截器配置跨域 │ └── JwtInterceptor.java // Token 校验拦截器 ├── controller │ ├── AuthController.java // 登录注册接口 │ ├── RideController.java // 发布拼车、搜索拼车 │ └── OrderController.java // 发起拼单、取消订单 ├── service │ ├── RideService.java │ └── impl │ └── RideServiceImpl.java ├── mapper │ ├── UserMapper.java │ ├── RideMapper.java │ └── OrderMapper.java ├── entity │ ├── User.java │ ├── Ride.java │ └── Order.java └── common ├── Result.java // 统一返回体 └── JwtUtil.java // JWT 生成与解析逻辑说明Result.java是这套源码里很值得学的一个小类所有接口都返回{code, message, data}这个结构前端只需要统一处理一次响应。JwtUtil负责生成和解析 Token登录成功之后把用户 ID 塞进 Token后续请求通过JwtInterceptor从请求头里取出来。参数说明这套代码里 JWT 的过期时间一般设置在 30 分钟到 2 小时之间具体在JwtUtil里有个常量改成3600000就是 1 小时。如果上线部署建议把密钥放到application.yml里而不是硬编码在类里。2.2 认证链路怎么走的从登录到放行的完整流程看一个毕设项目质量好不好最快的方式是先看它的拦截器配置。这套源码用的是WebMvcConfig里注册拦截器并配置放行路径属于常见做法。我把核心逻辑抽出来讲。// config/WebMvcConfig.java Configuration public class WebMvcConfig implements WebMvcConfigurer { Resource private JwtInterceptor jwtInterceptor; Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(jwtInterceptor) .addPathPatterns(/api/**) // 拦截所有 /api 下的请求 .excludePathPatterns(/api/auth/login, /api/auth/register); // 放行登录注册 } }逻辑说明addPathPatterns(/api/**)表示拦截所有以/api开头的接口而登录和注册接口通过excludePathPatterns放行。这个设计思路是一个用户没登录之前唯一能做的事就是登录和注册其他所有业务接口都要经过 Token 校验。搜拼车、下单、取消订单这些接口全部走拦截器。// config/JwtInterceptor.java public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !JwtUtil.verify(token)) { response.setStatus(401); return false; } // 从 Token 中解析出用户 ID放入 request 属性后续接口直接使用 Integer userId JwtUtil.getUserId(token); request.setAttribute(userId, userId); return true; } }逻辑说明这段代码有两个关键点。第一Token 放在请求头Authorization里前端每次请求都要带上否则直接返回 401第二校验通过后从 Token 里解析出userId放进request属性后续 Controller 方法里直接用(Integer) request.getAttribute(userId)就能拿到当前登录用户不用每次查库。参数说明JwtUtil.verify()内部会用密钥去解析 Token如果 Token 被篡改或者过期解析会抛出异常这里返回 false 之后前端会收到 401然后自动跳回登录页。这套认证设计的优点在于够用。毕业设计不需要引入 Spring Security 那一整套过滤器链JWT 拦截器既能在论文里讲清楚代码量也少出问题还好排查。3. 拼车的核心数据模型六张业务表与座位扣减的SQL细节3.1 表结构设计从用户到订单字段是怎么关联起来的数据库脚本是这套资源里含金量比较高的部分。拼车业务对比普通的商品交易多了一个路线和座位的概念。我把它拆成六张核心业务表来理解。表名作用关键字段user用户表id, username, password, phone, student_nocar车辆信息表id, user_id, plate_no, brand, seat_countride拼车路线表发布的车次id, user_id, car_id, start_point, end_point, start_time, total_seats, remain_seats, priceorders拼车订单表id, ride_id, user_id (乘客), seat_count, order_status, create_timecomment评价表id, order_id, from_user_id, to_user_id, rating, contentmessage消息通知表id, from_user_id, to_user_id, content, is_read这里我建议你重点看ride表的total_seats和remain_seats两个字段。total_seats是这条车次总共提供的座位数remain_seats是当前剩余座位数。每次有人下单remain_seats就要减掉对应座位数有人取消订单remain_seats加回来。-- 核心建表语句简化版 CREATE TABLE ride ( id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL COMMENT 车主用户ID, car_id int NOT NULL COMMENT 车辆ID, start_point varchar(100) NOT NULL COMMENT 出发地, end_point varchar(100) NOT NULL COMMENT 目的地, start_time datetime NOT NULL COMMENT 出发时间, total_seats int NOT NULL DEFAULT 4 COMMENT 总座位数, remain_seats int NOT NULL DEFAULT 4 COMMENT 剩余座位数, price decimal(10,2) NOT NULL COMMENT 每人价格, status tinyint DEFAULT 1 COMMENT 1进行中 2已结束 3已取消, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;逻辑说明status字段用来标记车次状态只有status1的车次才能被搜索到。remain_seats是拼车系统的核心所有下单逻辑都围着它转。price用decimal(10,2)而不是float是为了避免金额精度问题这个细节可以写进论文里。参数说明total_seats默认给 4对应普通轿车除去司机后的座位数。如果你的场景是校园拼车大部分是 4 座或 5 座车改这个默认值即可。start_time用datetime类型如果你希望支持按时间范围筛选可以在查询条件里对start_time做BETWEEN。3.2 座位扣减的SQL细节条件更新避免超卖拼车系统最容易出问题的地方就是两个人同时下单最后一个座位被两个人抢到。为了解决这个问题源码里用的是条件更新的方式这也是我建议你答辩时重点讲的一个点。-- 下单时扣减座位只有剩余座位足够时才更新成功 UPDATE ride SET remain_seats remain_seats - 1 WHERE id #{rideId} AND remain_seats 1 AND status 1;逻辑说明这条 SQL 的关键在WHERE条件里的remain_seats 1。MySQL 执行更新时会锁住这一行两个并发请求同时进来第二个请求执行时remain_seats已经被第一个请求扣成 0 了remain_seats 1不成立更新行数为 0。代码里只要判断int rows rideMapper.updateRemainSeats(rideId);的返回值等于 1 说明扣成功等于 0 说明没座位了直接返回拼车已满。-- 取消订单时返还座位 UPDATE ride SET remain_seats remain_seats 1 WHERE id #{rideId};逻辑说明返还座位的 SQL 相对简单但注意一个边界条件如果拼车已经发车了是不允许取消订座和返还座位的。所以真正写业务代码时取消订单前要先查订单状态和车次状态只有orders.order_status 0已下单未出发且ride.start_time now()时才做返还操作。我实际跑这套 SQL 时踩过一个坑数据库脚本里remain_seats的注释写的是剩余座位数但初始化的INSERT语句里直接写死了几条车次的remain_seats如果某条车次之前被测试数据扣减过后面再用就会对不上。所以建议你导入脚本后先把所有ride表的remain_seats重置成total_seats保证起点干净。4. 从发布到成单核心接口闭环与事务边界4.1 发布拼车接口参数校验比业务逻辑更值得抄发布拼车是整条业务链路的起点。我先看了RideController的发布接口再找到RideServiceImpl的实现发现它的参数校验做得比较完整——这对答辩来说是个加分点。// controller/RideController.java PostMapping(/api/ride/publish) public Result publish(RequestBody RideDTO dto, HttpServletRequest request) { Integer userId (Integer) request.getAttribute(userId); // 参数校验 if (dto.getStartPoint() null || dto.getEndPoint() null) { return Result.error(出发地和目的地不能为空); } if (dto.getStartTime() null || dto.getStartTime().isBefore(LocalDateTime.now())) { return Result.error(出发时间必须晚于当前时间); } if (dto.getTotalSeats() null || dto.getTotalSeats() 1 || dto.getTotalSeats() 6) { return Result.error(座位数必须在1到6之间); } if (dto.getPrice() null || dto.getPrice().doubleValue() 0) { return Result.error(价格必须大于0); } return rideService.publish(userId, dto); }逻辑说明request.getAttribute(userId)拿到的就是在拦截器里解析出来的当前登录用户 ID。校验里有两个细节我特别提一下一是startTime.isBefore(LocalDateTime.now())判断出发时间不能在过去这避免用户发布一条历史车次二是totalSeats限制在 1 到 6因为校园拼车场景下一般不会出现超过 6 座的车这个参数可以按实际车辆调整。// service/impl/RideServiceImpl.java Transactional public Result publish(Integer userId, RideDTO dto) { Ride ride new Ride(); ride.setUserId(userId); ride.setStartPoint(dto.getStartPoint()); ride.setEndPoint(dto.getEndPoint()); ride.setStartTime(dto.getStartTime()); ride.setTotalSeats(dto.getTotalSeats()); ride.setRemainSeats(dto.getTotalSeats()); // 初始剩余座位等于总座位 ride.setPrice(dto.getPrice()); ride.setStatus(1); rideMapper.insert(ride); return Result.success(发布成功, ride.getId()); }逻辑说明Transactional注解表示这个方法整体在一个事务里后续如果还有插入车辆、生成消息通知等操作任何一个失败都会整体回滚。remainSeats初始值直接等于totalSeats不需要额外计算。这里的ride.getId()会返回自增主键方便前端拿到车次 ID 后跳转到详情页。4.2 发起拼单接口先扣座位再插订单顺序不能反发起拼单是拼车系统里逻辑最密集的接口。我拆的时候特意关注了它的执行顺序先扣座位再插入订单最后处理事务提交。这个顺序搞反的话会出现订单有了座位没扣的数据不一致。// service/impl/OrderServiceImpl.java Transactional public Result createOrder(Integer userId, Integer rideId, Integer seatCount) { if (seatCount null || seatCount 1) { return Result.error(拼座数量至少为1); } // 1. 先尝试扣减座位返回影响行数 int rows rideMapper.deductSeats(rideId, seatCount); if (rows 0) { return Result.error(座位不足拼车失败); } // 2. 扣减成功后再创建订单 Order order new Order(); order.setRideId(rideId); order.setUserId(userId); order.setSeatCount(seatCount); order.setOrderStatus(0); // 0待出发1已完成2已取消 order.setCreateTime(LocalDateTime.now()); orderMapper.insert(order); return Result.success(拼车成功, order); }逻辑说明第一步调用rideMapper.deductSeats(rideId, seatCount)这条 SQL 就是第三章里的条件更新语句只不过把- 1改成了- #{seatCount}同时条件改成remain_seats #{seatCount}。如果更新行数为 0直接抛业务错误返回不再执行后续插入。这种做法的好处是座位校验和扣减在一条 SQL 里完成避免了先查剩余座位再更新带来的并发问题。参数说明seatCount表示这个乘客预订几个座位默认传 1 即可。如果之后要支持替室友一起拼座的场景这个字段可以大于 1但要注意deductSeats的条件必须同步改成remain_seats #{seatCount}。这里我要特别提醒一个事务陷阱Transactional默认只对RuntimeException回滚。如果rideMapper.deductSeats返回 0 行你用的是return Result.error(...)而不是抛异常那么已经执行的数据库操作不会回滚。好在这套逻辑里扣减失败时还没执行任何写操作所以没问题。但如果你在扣减座位之前先插入了订单然后再扣减座位扣减失败时订单插入不会自动回滚那就必须手动抛出异常或者在代码里判断后再删除订单。4.3 搜索拼车线路动态SQL与时间过滤搜索接口是使用频率最高的接口它的实现逻辑不算复杂但有一个值得留意的点前端传过来的出发地、目的地、出发时间都可能为空所以要用动态 SQL 来拼查询条件。// mapper/RideMapper.java ListRide searchRides(Param(startPoint) String startPoint, Param(endPoint) String endPoint, Param(startTime) LocalDateTime startTime);!-- mapper/RideMapper.xml -- select idsearchRides resultTypecom.example.carpool.entity.Ride SELECT * FROM ride WHERE status 1 if teststartPoint ! null and startPoint ! AND start_point LIKE CONCAT(%, #{startPoint}, %) /if if testendPoint ! null and endPoint ! AND end_point LIKE CONCAT(%, #{endPoint}, %) /if if teststartTime ! null AND start_time gt; #{startTime} /if ORDER BY start_time ASC /select逻辑说明if标签是 MyBatis 动态 SQL 的核心它让查询条件按需拼接。startPoint和endPoint用LIKE模糊匹配适应南门北门教学楼这类用户输入不精确的场景startTime用过滤掉已经出发的车次。ORDER BY start_time ASC让最早出发的车次排最前面这是个合理的产品决策——用户找拼车肯定是想找最近出发的。参数说明gt;是 XML 里的转义写法如果你直接写会导致 XML 解析报错这是 MyBatis 新手很容易翻车的地方。如果不想写转义符也可以把时间过滤条件放到 Java 代码里判断在 XML 里只处理不为空的字段。5. 部署与常见问题排查五个必踩的坑与解决路径这一章是我把整套源码导入本地、按正常顺序跑起来之后整理的踩坑记录基本覆盖了毕设项目最常见的五类问题。每条按现象 → 原因 → 解决来写你可以直接对照排查。5.1 启动直接报错数据库连接失败现象Spring Boot启动时控制台报Cannot create PoolableConnectionFactory或者Access denied for user rootlocalhost应用启动失败。原因application.yml里的数据库地址、用户名、密码和本地 MySQL 不一致。常见的坑是密码错误或者 MySQL 版本是 8.0 但驱动配置用了 5.x 的写法。解决先确认 MySQL 能正常登录再逐项检查application.yml里的url、username、password三项。MySQL 8.0 的 URL 需要加serverTimezoneAsia/Shanghai否则会报时区错误驱动改成com.mysql.cj.jdbc.Driver。改完重启即可。5.2 数据库脚本导入报错SQL文件执行不过去现象用 Navicat 或命令行导入项目附带的.sql文件时中途报错停住比如Unknown collation: utf8mb4_0900_ai_ci。原因项目里给的 SQL 脚本是在 MySQL 8.0 上导出的建表语句里的utf8mb4_0900_ai_ci排序规则在 MySQL 5.7 里不存在。解决用文本编辑器打开 SQL 文件全局替换utf8mb4_0900_ai_ci为utf8mb4_general_ci然后再重新导入。如果你本地就是 MySQL 8.0可以不用改。这个坑非常典型很多同学卡在第一步导入脚本上实际上就是这个排序规则的问题。5.3 前端登录后请求接口全部 401现象登录接口能通但登录后访问拼车列表、发布拼车等接口全部返回 401前端页面拿不到数据。原因登录接口返回的 Token 没有存到前端本地或者后续请求没有在请求头里带上Authorization。也有一种情况是前端用了 axios但没有在拦截器里统一设置headers。解决在浏览器 F12 的 Network 面板里看请求头如果请求头里没有Authorization就是前端的问题。常见做法是在 axios 请求拦截器里加一行config.headers[Authorization] localStorage.getItem(token)。如果是跨域导致请求头被浏览器拦了还要在后端配置CorsFilter允许携带认证信息WebMvcConfig里加一个CorsRegistry配置。5.4 拼车接口报座位不足但数据明明有座位现象测试下单时数据库里remain_seats明明还有 2 个座位但下单接口一直提示座位不足。原因大概率是你之前测试过下单流程订单表里已经有这条ride_id的记录但座位被扣减后没有正确返还导致remain_seats已经小于seatCount。还有一种情况是并发测试时两个请求同时进来后一个请求在条件更新时失败。解决先查ride表的remain_seats实际值对比orders表里未取消的订单总数确认数据是否一致。如果只是测试数据乱了直接把ride.remain_seats重置为total_seats把orders表清空再重新测。想真正验证并发问题可以用两个浏览器同时登录两个账号对同一车次下单观察只有一个能成功。5.5 SpringBoot版本过高导致依赖冲突现象项目导入 IDEA 后Maven 一直下载依赖下载完成后启动报ClassNotFoundException: javax.servlet.Filter或者Failed to configure a DataSource。原因源码配的 SpringBoot 版本可能和你本地环境不一致。比如源码用的是 Spring Boot 2.3.x你本地 IDEA 默认创建的是 Spring Boot 3.x而 3.x 把javax.servlet换成了jakarta.servlet旧代码直接编译过不去。解决打开pom.xml把spring-boot-starter-parent的版本改成和源码配套的版本一般 2.5.x 或 2.7.x 都比较稳。改完Ctrl Shift O重新导入 Maven 依赖。这个坑在毕设里出现频率极高本质是版本升级带来的包名变更。我的建议是不要用太新的 SpringBoot 跑旧源码2.7 是兼容性最好的一个版本线。6. 验收与进阶把毕设变成自己的作品源码跑通只是第一步答辩时老师真正想听的是你做了什么。我建议你从两个方向准备先按我的验收链路走一遍全流程再做一处源码改造这样项目就能讲成自己的了。验收链路分七步注册两个账号一个车主、一个乘客→ 车主登录后发布一条拼车路线 → 乘客搜索到这条路线 → 乘客发起拼单并支付如果有模拟支付→ 双方都能在订单列表看到记录 → 车主确认发车 → 行程结束后乘客评价。每一步都在前端页面操作一遍同时在后端打开 SQL 日志观察对应 SQL 的执行。这套流程走完你对项目的理解会比只跑起来深刻得多。进阶改造方面我推荐一个改动量不大但讲起来很有亮点的方向把拼车搜索从模糊匹配升级为顺路推荐。原逻辑只按start_point和end_point做模糊匹配你可以在RideService里加一个方法把用户常用的出发地和目的地存到user表的新字段里搜索时优先返回和自己历史路线相似度高的车次。技术上就是多一个LIKE条件加一个排序字段但业务上变成了智能推荐论文里能多写两页。// 进阶按历史路线优先排序的搜索 SELECT r.*, CASE WHEN r.start_point #{myStart} AND r.end_point #{myEnd} THEN 0 WHEN r.start_point #{myStart} THEN 1 ELSE 2 END AS match_score FROM ride r WHERE r.status 1 ORDER BY match_score ASC, r.start_time ASC;逻辑说明CASE WHEN是 SQL 里的条件表达式这里用来计算顺路程度。完全匹配的历史路线排在最前只匹配出发地的排第二其他的排在最后。这个改动不需要动表结构只改一条查询语句但你能讲清楚我做了用户偏好分析。从那以后我每次拆毕设源码都强制自己先走一遍完整验收链路再动手改代码——先证明它原本是通的再谈改进。这套基于 SpringBoot 的校园拼车系统结构清楚、坑也足够典型很适合作为你第一个完整跑通的 SpringBoot 项目。希望这篇拆解能帮你少走点弯路也希望你改完的每一个功能都能在答辩的时候理直气壮地说这是我写的。本文还有配套的精品资源点击获取
