我前阵子帮一个学弟把关他的毕业设计，题目就是校园周边短程配送系统。他一开始拿着题目来问我，说导师只给了个方向，剩下全靠自己琢磨。聊到后面我发现，这个题目放在2025年其实非常讨巧——Spring Boot本身是Java方向毕设的绝对主流，校园配送又自带"外卖、跑腿、兼职、定位追踪"这些容易出彩的业务点。只要代码结构别做崩，答辩的时候能讲清楚几个关键模块的原理，拿个不错的成绩是大概率事件。所以这篇文章我就把这个项目从头到尾拆一遍，从需求梳理、技术选型、数据库设计到几个核心接口的实现细节和常见坑，尽量按我自己的实操经验来讲，给准备做Spring Boot方向毕设、或者在学SSM之后想找一个完整业务项目练手的同学做个参考。

先说明一下这个项目做什么。简单说，它解决的是"外卖不送进校园、快递代取需要人帮忙"这类短距离配送问题。系统里面有学生用户、商家、骑手和管理员四个角色，学生下单买食堂或者其他校园周边的商品，商家接单备货，骑手在系统里抢单、取货、送到宿舍楼下，用户还能实时看订单状态。技术栈上，后端是Spring Boot + MyBatis Plus + MySQL，前端是Vue，鉴权走JWT，数据缓存用Redis，管理后台可以看订单量、用户数这些统计报表。整体是标准的前后端分离架构。

下面我按做项目的实际顺序来写。

1. 项目概述与需求拆解

1.1 这个系统到底要解决什么问题

校园配送场景和外面的外卖平台有一个本质区别：配送距离极短。校园范围一般也就一到两公里，宿舍楼能下单食堂，教学楼能下单门口奶茶店，但恰恰是这种"短"带来了一些很琐碎的问题。最典型的是配送高峰集中在中午和晚上，某个食堂窗口高峰期可能同时有几十个订单，人工调度根本忙不过来。宿舍区又把控严，外卖骑手进不去，只能堆在大门口，找个外卖都要翻半天。

这个系统本质上做的是"短程配送的接单、追踪、结算闭环"。它要解决三个核心问题：第一，用户下单之后订单信息能准确、即时地推送到商家端；第二，骑手能高效地接单、取货、配送，且整个过程的订单状态对用户可见；第三，管理员能实时掌握平台运营数据——待配送订单数、骑手接单率、商家订单量——而不是靠Excel报表事后统计。

需求拆解出来之后，功能边界其实非常清晰：用户端需要注册登录、浏览商品、下单支付、查看订单状态、确认收货和评价；商家端需要管理商品上下架、接单、备货后通知骑手；骑手端需要抢单、查看取送地址、更新配送状态；管理员端需要审核入驻、订单监控、用户管理、基础数据统计。每个角色的需求都要能落到具体的页面和接口上，这才是真正能做成的东西。

1.2 四个核心角色与业务流程梳理

这个系统的角色划分我是强烈建议照着"一个订单从产生到完成"的流程去设计的。我们设想一个用户在小程序里点了食堂某窗口的砂锅饭，这个订单流是这样的：用户注册登录 → 浏览商家及商品 → 选择商品加入购物车 → 结算下单 → 商家端弹出新订单提醒 → 商家确认接单并出餐 → 出餐后订单进入待配送池 → 骑手在骑手端看到可抢订单并抢单 → 骑手到店取餐 → 开始配送 → 到达宿舍楼下点击送达 → 用户收到通知取餐并确认收货 → 订单完成，用户可评价。

这四个角色对应的数据需求分别是：用户要看自己的历史订单和积分；商家要看当日营收和待处理订单；骑手要看自己的配送收益和配送里程；管理员要看平台整体的订单量、骑手效率、商家经营情况。如果你画一张时序图或者状态图来沟通这些流程，你会发现"订单状态机"是整个系统的中心，所有角色都围着订单状态转。

1.3 功能模块拆分与优先级

我一般做毕设项目会先列功能清单，然后按"基础版、进进阶版、加分散户"三个档来区分工作量。基础版是必须实现的：用户登录注册、商品浏览与下单、订单状态流转、商家与骑手端的基础操作。进阶版可以加：JWT鉴权拦截、Redis缓存热门商品、骑手抢单的并发控制、订单统计报表、上传图片展示。加分项可以加：WebSocket消息推送、基于高德地图API的配送路线展示、支付沙箱接入、积分评价体系。

这里我给一个优先级建议：先把订单状态机跑通，再把并发抢单做好，这两个是答辩时最有技术含量的部分。支付模块如果觉得接入沙箱太麻烦，做成模拟支付（点击支付直接改变订单状态）也完全可以，但要在论文里说明这是模拟实现，不要硬写成已对接真实支付。

2. 技术选型与架构设计

2.1 为什么选Spring Boot而不是SSH或SSM

很多同学纠结后端框架到底选什么。我从毕业设计和找工作的双重角度说：Spring Boot是目前Java后端最主流的框架，几乎没有之一。它不是你简历上的加分项，而是必备项。毕业设计选Spring Boot，一是因为自动装配让你省掉大量XML配置，开发效率高；二是因为网上资料多，遇到问题搜得着解决方案；三是因为答辩时老师对Spring Boot的预期明确，你容易答到点子上。

对比一下SSH（Spring + Struts + Hibernate），那套早过时了，维护成本高，写起来还特别难受；SSM（Spring + SpringMVC + MyBatis）逻辑上和Spring Boot很接近，但配置繁琐，你花在配置上的时间比写业务的时间都多。Spring Boot把这些都简化了：内嵌Tomcat、自动配置、starter机制、Actuator监控。你用Spring Boot写业务，拿出来的时间可以花在更值得打磨的业务逻辑上。

2.2 技术栈清单与版本搭配

我这个项目的技术栈可以照抄，版本都是Nebula实测没问题的组合：

版本这个东西我特别提醒一句：Spring Boot 3.x虽然出了好几年，但很多第三方starter还没完全跟进，比如某些图形验证码、文件上传的兼容性。你真要做毕设，就直接用2.7.x，别追求新版本。等你工作了再上3.x不迟。

2.3 三层架构与模块代码规范

项目采用的是教科书式的经典三层架构：Controller（负责接收参数、返回统一结果）→ Service（核心业务逻辑）→ Mapper（数据库交互）。在此基础上我加了一层VO/DTO转换：Entity对应数据库字段，DTO接收前端参数，VO返回给前端数据。比如订单表里面有个字段叫status，数据库存的是Integer（0待接单、1配送中、2已送达），前端不能直接拿数字去展示，VO里面就要转成对应的状态文案。

代码规范方面有一点特别重要：统一返回结果。我自己习惯写一个Result类，code区分成功和失败，message放提示信息，data放业务数据。所有Controller方法都返回这个统一结构，这样前端只需要做一个拦截器处理code，而不用每个接口都去解析不同格式。这个习惯虽然是基础工程能力，但很多人不重视，最后代码越写越乱。

3. 数据库设计与核心表结构

3.1 数据库表设计思路

数据库设计是一个系统成败的关键。我通常先列出所有实体：用户、商家、商品、订单、订单明细、配送单、评价、公告、购物车（可不要表，前端存localStorage也行，但为了毕设完整度我建议保留）。然后逐个确认实体间的关系：用户和订单是一对多，订单和订单明细是一对多，订单和配送单是一对一，商家和商品是一对多。

建表的时候有几条红线必须记住：第一个是主键用自增id或者雪花id都可以，但是不要用UUID做主键，因为UUID是无序字符串，索引效率极差。第二个是金额字段用 decimal(10,2)，不要用float/double，否则会出现9.99变成10.0000004这种脏数据。第三个是所有表都加create_time、update_time两个字段，MyBatis Plus有自动填充注解，处理起来非常简单。

3.2 订单表设计详解

订单表是整个系统的核心，我给它标注了最详细的字段说明。order_info表核心字段如下：order_no（订单编号，唯一索引，业务上用于用户查询和系统对账）；user_id（下单用户外键）；merchant_id（商家外键）；driver_id（接单骑手外键，初始为null）；goods_id和goods_name（快照字段，存下单时的商品名字和单价，防止商家改价清空）；total_amount（总价）；status（订单状态）；address_receiver/receiver_phone（收货信息，冗余存储，防止用户修改后历史订单查不到原数据）；remark（备注，比如"不要葱"等）；payment_type（支付方式）。

订单状态我强烈建议用数字0-6表示一个闭环：0待支付、1待接单、2已接单（待取货）、3配送中、4已送达、5已完成、6已取消。注意"已取消"必须保留，因为用户也可能在商家出餐前取消订单，状态图里得有这个分支。数据库表里加一个索引在(status)字段上，因为大量的业务查询都是按状态筛选的。

3.3 配送单与商品表、评价表

配送单表（delivery_order）是订单表的子表，加了delivery_type（配送类型：校内、校外）、distance（预计距离）、fee（配送费）、pickup_time（取货时间）、finish_time（完成时间）。商品表（goods_info）除了基础字段外还要有stock（库存）和sales（销量），这两个字段一个管库存，一个用于排序时把热门商品排前面。

评价表我建议用reply_id关联订单号，不要关联用户id，因为评价本身的粒度是一个订单一次，用户不可能针对同一个订单评价两次。评价表里存user_id是为了展示"某某用户评价"，存merchant_id是为了商家后台看到评分，所以评价其实是三个维度（用户、商家、订单）的交叉记录，外键设置要合理。

4. 核心功能实现与实操细节

4.1 登录注册与JWT鉴权

前端用户、商家、骑手共用一套登录接口，靠role字段区分身份。我的实现方式是：用户提交手机号+密码（或者手机号+验证码），后端校验成功后生成JWT令牌返回，前端每次请求都在Authorization请求头里带上这个令牌，后端通过拦截器统一校验。

JWT的生成我用的是jjwt库(java-jwt)，核心代码大概是先设置签发者（issuer）、过期时间（expire时间我习惯设成24小时）、私有声明（存userId和role），然后用HS256算法和密钥签名。因为这个过程完全无状态，服务端不用存会话，很方便做多端登录。密钥不要硬编码在类里，我建议放在application.yml里，答辩时可以讲这是安全配置项。

拦截器环节有两层：第一层是Spring Interceptor，写一个JwtInterceptor实现HandlerInterceptor接口，preHandle方法里从request.getHeader("Authorization")取出token，调用JwtUtil.parseToken校验合法性，校验通过把userId和role塞到request的attribute里，供后续controller使用。第二层是登录角色校验，因为不同角色能访问的接口权限不一样，比如创建订单只有user可以调，发货和配送只有对应角色可以调，所以我会在Controller方法上加自定义注解，比如@RequireRole("ADMIN")，拦截器里解析注解做权限控制。这个设计你在论文里写一句"基于RBAC轻量级权限模型"会显得比较专业。

4.2 下单流程与库存扣减

下单是一个事务性很强的操作。用户点结算，前端提交商品id和数量，后端要做这几步：查询商品是否存在并且在架、计算总价、扣减库存（库存如果小于购买数量就报错）、生成订单主表和明细表、返回订单号。

这里有一个非常关键的细节：扣库存。如果你先查询库存再更新库存，在高并发下会出现超卖。安全做法是直接在SQL里扣：UPDATE goods_info SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}，然后判断受影响行数，如果等于0说明库存不足。这种"原子更新"是秒杀系统的经典方案，毕设里用了这个点是加分项。

订单创建为什么要事务？因为订单表和订单明细表必须同时成功或同时失败，否则会出现主表存在但明细为空的数据脏状态。我们用@Transactional注解控制，注意事务方法里不要try-catch吞掉异常，否则事务不会回滚。如果你用了try-catch，记得在catch块里手动设置rollbackOnly或者重新抛出RuntimeException。

4.3 骑手抢单与并发控制

骑手抢单是另一个并发重点。设想一下：一个订单进入待配送池后，可能有多个骑手同时点击"抢单"按钮。如果你先SELECT该order_Info，看status是不是待配送，再UPDATE status改成配送中并设置driver_id，那么两个骑手可能同时通过第一步的查询，然后各自更新，结果是两个人同时抢到一单。

解决办法统称为乐观锁。我这里的实现是：UPDATE order_info SET status = 3, driver_id = #{driverId}, pickup_time = NOW() WHERE id = #{orderId} AND status = 2。注意最后那个status = 2条件，数据库在更新时会自动检查当前值是否等于2，只有等于2才更新成功，受影响行数才会返回1。如果返回0，说明订单已经被别人抢了，你直接提示"手慢了，订单已被抢走"。这一条SQL就解决了并发问题，不需要引入分布式锁，逻辑又清晰又高效。Redis的分布式锁也能做，但用在毕设里反而会增加复杂度，除非你想专门讲Redis的应用，否则首选乐观锁。

4.4 实时定位与订单轨迹

实时定位这个需求有很多做法。最简单的方案是：骑手端通过前端定位拿到经纬度，每10秒或者每30秒向后端上报一次位置坐标（POST接口），后端把这些坐标存到Redis中，以orderId为key存一个坐标点集合。用户端的订单详情页则每隔几秒向后端拉取最新位置（GET接口），前端拿到坐标后渲染在地图上。

这里我建议用高德地图JavaScript API，把坐标转换成地图上的标记。你不需要自己实现复杂的轨迹规划，只需要拿上一段路线的起终点连线就行。如果你不想接高德API，可以做成"配送进度条"的形式——用百分比数字表示骑手从取货点到目的地的进度，前端用一个进度条组件展示。这两种方案在毕设里都是够用的，看你的时间安排。

如果你想做WebSocket推送状态变化，思路是：用户下单后建立WebSocket连接，服务端持有这个连接，当订单状态变化（比如商家接单、骑手取货、送达）时主动推送消息，前端收到后更新页面，可以做成一个弹窗提示"您的订单已被骑手接单"。WebSocket用Spring封装的SimpleMessagingTemplate，网上教程很多，核心点是要处理连接断开的问题，否则用户退出页面后连接还挂着会报错。

4.5 模拟支付与回调

如果不想接支付宝/微信支付沙箱，最稳妥的做法是写一个模拟支付接口。用户在支付页点"确认支付"后，前端调用/pay/mock接口，后端直接把订单状态从"待支付"改成"待接单"，然后生成一条支付流水记录（支付单号、支付时间、金额），并标记pay_type=1（模拟）。这样做的目的是：支付逻辑有了，流水记录有了，又不依赖第三方平台的环境。答辩的时候如果老师问"为什么不做真实支付"，你可以回答"毕设的定位是系统设计和流程完整，接真实支付需要商户资质和沙箱环境，所以用模拟支付来保证核心流程闭环，生产环境下替换成第三方SDK即可"。这个回答是加分的，因为它体现了你对业务边界的理解。

4.6 ECharts统计报表

管理端的统计报表，我建议用ECharts做图表展示。三个核心报表：第一，近30天订单趋势折线图，数据按天分组count一下；第二，商家订单量饼状图，统计每个商家的订单数；第三，骑手配送排行柱状图，按完成配送单数排前10名。这些SQL用MyBatis Plus的wrapper条件构造器加上groupBy就能实现，不需要写原生SQL。前端用Vue的ECharts组件，接口返回什么指标我就渲染什么图。

做报表有个坑：ECharts本身对数据格式有要求，比如饼状图需要[{name:"麻辣香锅",value:120},{name:"黄焖鸡",value:80}]这种结构，你在后端就直接组装成这种格式，别把原始List丢给前端让前端去处理格式。前端处理数据格式的能力有限，后端返回结构化的VO是更好的合作方式。

5. 常见问题排查与避坑指南

5.1 启动报错排查

我见过最多的问题是Spring Boot项目启动时端口被占用，报Port 8080 was already in use。解决办法是在application.yml里改端口（比如server.port=9999），或者找到占用进程杀掉。还有一个很常见的问题是MyBatis Plus的Mapper扫描不到，报Invalid bound statement，这个大概率是因为你的Mapper接口上没加@Mapper注解，或者启动类上的@MapperScan路径不对。检查三件事：注解有没有加、路径对不对、XML文件路径和namespace是否匹配。

如果遇到依赖冲突，比如Spring Boot 2.7和某个starter版本不对，大概率是Maven没有刷新。IDEA里点一下右侧Maven面板的刷新按钮，重新reimport一下依赖，问题基本能解决。导包失败很可能是Maven镜像源问题，换成阿里云镜像或者腾讯云镜像，拉依赖的速度和成功率都会明显提升。

5.2 数据库版本导致的建表失败

很多同学用的是MySQL 8.0，然后用到了Navicat导出的SQL脚本，结果在MySQL 5.7上建表失败，报错信息要么是utf8mb4_0900_ai_ci字符集不认识，要么是CHECK约束语法不支持。MySQL 8.0引入了许多5.7没有的语法特性，导致SQL脚本不兼容。如果你的目标是5.7，建表语句里就别写CHECK约束，字符集统一用utf8mb4_general_ci，datetime类型用default current_timestamp设置默认值，这个写法在8.0和5.7都能过。

另外一个经典坑：数据库连接URL没带serverTimezone=Asia/Shanghai参数，导致查询出来的时间比本地时间少8小时。这是JDBC驱动在解析datetime类型时的时区问题。解决方案是在spring.datasource.url里加上?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8。注意这里的useUnicode和characterEncoding也要写，否则中文会变成问号。

5.3 跨域问题与上传文件路径问题

前端页面跑在8081或者80端口，后端跑在8080端口，浏览器就会拦截跨域请求。解决方案有两个：一个是在后端写一个WebMvcConfigurer的配置类，重写addCorsMappings方法，设置允许的源、请求头和方法；另一个是前端通过Nginx反向代理把/api的请求转发到后端地址。毕设阶段我建议用后端允许跨域的方式，代码简单，不用额外配Nginx。

静态资源上传是另一个高频问题。商品图片上传到后端的本地磁盘文件夹，但前端通过访问IP加路径却找不到图片，这是因为SpringBoot默认不会把你自定义的磁盘目录映射为静态资源。解决方式是配置一个资源映射，用WebMvcConfigurer的addResourceHandlers方法，把/file/**这个请求路径映射到你的本地上传目录物理路径。这样前端就能通过http://localhost:8080/file/xxx.jpg访问到了。注意Linux服务器和Windows服务器的路径写法不同，Windows下要用"file:E:/upload/"，用一个配置项维护这个路径，方便部署时修改。

5.4 答辩高频问题应对

答辩环节老师有几个问题特别爱问。第一个是"你这个项目的亮点是什么"，不要回答什么"用了SpringBoot开发效率高"这种话，要讲具体的：比如抢单功能的敏感条件在数据库层面做并发控制避免超卖、订单状态机让整个流程有明确可追踪的节点、统计分析用缓存减少了对数据库的压力。第二个是"项目中遇到最大的技术难点是什么"，回答要有故事性，比如"骑手抢单场景并发导致超单，我最初用了悲观锁，性能较差，后来改成了Update语句带where条件的乐观锁方案，性能提升了而且逻辑更简洁"。第三个是"数据库为什么这样设计"，你可以讲冗余字段的设计思路，比如订单快照字段如何保证历史数据的可追溯性。提前准备好这三个问题的回答，答辩现场会比临场发挥稳很多。

5.5 从毕设到完整项目的几个加分扩展点

如果你时间还有富余，建议做这几个扩展。第一个是把静态文件上传换成对接MinIO对象存储，这个可以在论文里写"解耦本地存储依赖，提高可扩展性"。第二个是给系统加一个RabbitMQ消息队列，订单创建后通过MQ通知商家和骑手，而不是在业务方法里同步调用，这样业务链路更解耦，也更接近生产环境。第三个是把前端Vue2换成Vue3 + TypeScript，虽然学习成本高一些，但简历上写Vue3会更有竞争力。第四个是加一个基于WebSocket的全站消息中心，把订单状态通知集成进去。

不过我得提醒一句：这些扩展点量力而行。如果你的核心功能还没做完、论文还没写，那就别盲目加，先把基本盘做稳。一个功能完整、代码整洁、能流畅跑通的系统，比一个有残缺的高级功能更能打动评审老师。

写在最后的个人体会

回头再看这个项目，我觉得最值得学的不是Spring Boot怎么配、CRUD怎么写，而是"把一个真实场景拆成一整套系统方案"的能力。从需求分析到数据建模，从并发控制到权限设计，每一步都在逼你想清楚"为什么"。很多同学在校阶段写代码习惯"先把功能跑通再说"，但做毕设这段时间如果能养成"先设计再编码、每段代码都知道自己在解决什么问题"的习惯，那这个毕业设计对你实际能力的提升会比想象中大得多。我学弟做完这版之后，自己又在上面加了个定时任务，每天凌晨对前一天订单做汇总、生成日报，他说"没想到写起来这么顺手"，这就是平时训练的结果。

如果你现在正在为毕设选题发愁，或者已经开了头又卡在某个环节，那这套校园配送系统值得你动手试一遍。代码不难，难点全在把细节想清楚。照着上面的思路把数据库表建好，把订单状态跑通，把抢单的并发控制写上，你拿到的不仅是一个能答辩的项目，更是一套能写进简历的完整经验。