校园订餐外卖系统实战：SpringBoot+MyBatis-Plus全链路解析

1. 为什么校园订餐外卖系统值得自己动手做一版我做这个项目纯属偶然。当时在某高校信息化小组帮忙发现学生订餐高峰期食堂排队时间长周边商家又没法精准触达校内用户就萌生了做一个校园订餐外卖系统的想法。市面上现成的外卖平台很多但通用平台在校园场景下有几个绕不开的痛点校外骑手进校难、取餐点分散、学生订单集中在饭点前后形成明显波峰、商家需要按宿舍楼或教学楼分组配送。通用平台根本没有针对这些场景的字段设计于是我决定基于SpringBoot从零搭建一套。这个项目做下来收益远超预期。它不是一个“玩具项目”而是真正覆盖了电商类系统最典型的一整条链路用户端浏览菜品、加入购物车、下单支付、订单状态流转、商家端接单出餐、管理员端审核与统计。无论你是刚学完SpringBoot想做课程设计还是想把Spring生态的常用组件系统过一遍这套“校园订餐外卖系统”都是很好的练手对象。先说一下我最终的技术选型和项目规模。后端采用SpringBoot 2.x MyBatis-Plus数据库用MySQL 8.x前端使用Vue Element UI搭建管理后台用户端使用微信小程序承载。整个项目包含三个核心角色学生用户、商家、系统管理员另外还有一套简单的配送状态管理。采用前后端分离架构后端提供RESTful API前端通过HTTP接口调用。标题里提到“附源码81793”这个编号是源码包内部的项目标识。源码包内包含了完整的后端工程、前端管理后台、小程序端代码以及SQL初始化脚本拿到手之后按顺序导入数据库、改完配置就能直接跑起来。下面我从设计思路、数据库建模、核心模块实现、部署避坑几个环节逐一拆解把自己实际开发过程中踩过的坑也一并交代清楚。2. 技术选型与总体架构SpringBoot MyBatis-Plus的配置逻辑2.1 为什么选这套技术栈校园订餐外卖系统在技术上没有太大挑战但它非常适合作为SpringBoot实战项目因为业务场景足够完整。我选择SpringBoot 2.7作为基础框架原因很简单它的自动配置机制极大降低了整合成本内嵌Tomcat让部署变成单jar包运行。对于课程设计或中小型项目没有必要上微服务那套复杂治理单体应用配合好分层结构反而更容易维护。持久层我选择了MyBatis-Plus而不是原生MyBatis。两者差别很大原生MyBatis需要手写大量XML映射文件而MyBatis-Plus内置通用Mapper单表CRUD几乎不用写SQL。实际开发中我统计过订单、用户、菜品这些基础表的增删改查MyBatis-Plus帮我省掉了大概60%的持久层代码。尤其是分页查询一页代码就搞定比手写PageHelper配置或者自己拼LIMIT语句要省心。身份认证方面我没有引入Spring Security或Shiro那套重量级方案。原因在于校园订餐系统只有简单的角色区分用拦截器加复杂组件反而增加学习门槛。我最终选择用拦截器 Session 自定义注解实现三端统一登录校验同时用ThreadLocal保存当前登录用户上下文。这种轻量方案在中小型项目中非常实用也更容易让初学者看懂。Redis我引入了但用得克制。主要缓存菜品分类列表、首页轮播图信息以及热点菜品的访问计数。购物车和订单核心数据放在MySQL因为校园场景的并发量远没有达到必须用Redis扛购物车的程度。刚开始我也想过把所有数据都放Redis但后来发现项目可维护性会变差最终调整为“MySQL持久化为主Redis缓存为辅”的模式。2.2 工程目录与职责划分源码包中的后端工程按标准分层结构组织每个层级职责清晰com.campus.order ├── controller # 接口层接收前端请求返回统一响应体 ├── service # 业务层处理具体逻辑事务 │ └── impl # 业务接口实现 ├── mapper # MyBatis-Plus持久层接口 ├── entity # 数据库实体映射 ├── dto # 前端交互数据对象 ├── vo # 视图返回对象 ├── config # 全局配置类 ├── interceptor # 登录拦截器 ├── common # 统一返回结果、异常处理 └── utils # 工具类这种分层是我多次实践后觉得最舒服的结构。Controller层只做参数接收和结果返回不含任何业务逻辑Service层承担核心业务处理Mapper层对接数据库。需要注意的是有的同学习惯把逻辑全写在Controller里页面一多、权限一复杂就完全失控。别学那种写法宁可前期多建几个DTO也别让Controller变成大杂烩。2.3 统一返回结构与全局异常处理前后端联调时最容易出现的问题就是接口返回格式不统一。有的接口返回成功就只给个true有的失败时字段名又不一样前端只能到处写分支判断。我从一开始就定义了统一的返回体{ code: 200, message: 操作成功, data: null }对应的Java类是ResultT包含code、message、data三个字段提供静态方法Result.success(data)、Result.error(code, message)来构造响应。所有Controller的返回值类型都必须是ResultT不准直接返回裸数据。这样约定之后前端小程序的请求封装只需要写一套就全项目通用。全局异常处理也是必须做的。我在common包下创建了GlobalExceptionHandler类加上RestControllerAdvice注解内部定义了几个ExceptionHandler方法分别处理业务异常BusinessException、参数校验异常MethodArgumentNotValidException以及兜底的Exception。这里有一个实际经验业务异常和系统异常一定要分开处理。业务异常比如“库存不足”“订单已取消”这类需要在响应中返回友好提示且HTTP状态码保持200方便前端直接弹出消息。真正系统异常和数据库连接异常则要记录完整堆栈日志到服务端文件。最忌讳的就是把系统堆栈直接返回给前端既暴露内部结构又让用户看到一堆看不懂的英文报错信息。2.4 跨域配置与端口规划前后端分离后第一个遇到的问题就是跨域。我一开始的配置是在Controller类上加CrossOrigin注解但接口一多就发现每个类都得重复加后来统一改用WebMvcConfigurer全局配置Configuration public class WebConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/api/**) .allowedOriginPatterns(*) .allowCredentials(true) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .maxAge(3600); } }端口规划方面后端服务固定8080端口前端管理后台使用9528端口小程序端没有固定端口。生产环境部署时我把后端打包成jar在服务器上用nohup java -jar方式后台启动用Nginx做反向代理统一入口。前端静态文件由Nginx托管/api前缀的请求反向代理到本机8080端口这样浏览器端完全没有跨域问题。3. 数据库设计从菜品表到订单状态机的核心思路3.1 核心表结构与业务字段这套系统的数据库一共12张表最核心的是围绕用户、商户、菜品、订单这四条主线展开。我直接给出建表时的核心字段设计这些都是我自己反复斟酌后敲定的。用户表(user)主键id、用户名、密码、手机号、角色(1学生/2商家/3管理员)、学校id、宿舍/收货地址、头像、注册时间。密码字段必须有盐值或至少用MD5加盐处理。有的系统直接用明文存密码那是给自己留坑。这里是课程设计无所谓真有同学毕设答辩时被问到安全问题回答“密码明文存储”会非常减分。商家表(merchant)主键id、用户id外键、店铺名称、公告、起送价、配送费、营业状态(1营业/0休息)、评分、图片。起送价和配送费是订单计算金额时的关键字段我在设计中把它们单独抽出来避免了每次查询用户关联商家再取价格的性能损耗。菜品表(dish)主键id、商家id、分类id、菜品名称、图片、价格(单位分)、描述、月售数量、库存状态、上架状态(1上架/0下架)。价格我强烈建议用整数型的“分”来存储而不是小数型的“元”。浮点数在金额累加过程中会出现精度丢失两个9.9元的菜加一起可能等于19.79999。实际项目里还要结合分页查询、模糊搜索等操作整数金额可以避免大量边界问题。菜品分类表(category)主键id、商家id、分类名称、排序字段。分类表挂在商家下而不是全局共享因为不同商家的分类五花八门比如炸鸡店是“鸡排/小吃/饮品”面馆是“汤面/拌面/小菜”全局共享分类反而无从挂载。购物车表(cart)主键id、用户id、商家id、菜品id、菜品名称(快照)、菜品图片(快照)、单价(分快照)、数量、选中状态。这里有一个关键设计点购物车表存了菜品名称和图片的“快照”字段。这样菜品菜单被商家修改甚至删除后用户购物车里的历史信息仍然能正常展示。这种做法和订单表的“商品快照”思路一脉相承问题是很多人容易忽略。订单表(orders)主键id、订单编号、用户id、商家id、总金额(分)、配送地址、联系电话、备注、订单状态、支付状态、创建时间、支付时间、完成时间。订单状态我用int存储配合一套常量类定义状态含义0待支付、1待接单、2已接单/制作中、3配送中、4已送达/完成、5已取消、6退款中/已退款。订单明细表(order_item)主键id、订单id、菜品id、菜品名称(快照)、菜品图片(快照)、单价(分快照)、数量、小计金额。这个表用来展开订单详情里用户买了哪些菜。快照字段在订单表这层同样是重点因为订单生成后商家改价、改名都不应该影响订单历史数据。地址表(address)主键id、用户id、收货人姓名、联系电话、所在校区、宿舍楼栋/具体地址、是否为默认地址。校园场景非常特殊收货地址直接绑定了宿舍楼栋或教学楼配送员不需要像社会外卖那样精确到门牌号而是送到楼栋门口后由用户下来取。其他如轮播图表、公告表、管理员操作日志表这类辅助表就不一一展开了。3.2 订单状态机的流转设计订单状态逻辑是整个系统的核心难点。很多同学习惯用if-else在代码里层层判断状态后面状态一多就乱套。我在这个项目里用状态机思维重构了订单生命周期每种状态下只允许固定的动作触发固定的状态变更0待支付 → (支付成功) → 1待接单 0待支付 → (超时未支付/用户主动取消) → 5已取消 1待接单 → (商家接单) → 2已接单/制作中 1待接单 → (商家拒单/超时未接单) → 5已取消 2已接单/制作中 → (商家出餐) → 3配送中 3配送中 → (用户确认收货/超时自动确认) → 4已送达/完成 2已接单/制作中 → (用户申请退款/商家同意) → 6退款中/已退款我把这个状态机实现为一个订单状态机常量类每个状态变更操作在Service层最终通过统一方法校验。状态一旦从“待支付”变为“已接单”就再不允许直接跳转到“完成”必须严格经过中间状态。这样做的好处是查询订单列表时需要统计各状态数量SQL里只需要GROUP BY order_status就能快速得出结果不会出现同一订单同时处于两个状态的分裂数据。3.3 学校与商户的关联设计校园订餐和常规外卖的另一个差异是“学校”这个维度。同一个系统可能被不同高校部署不同学校的学生只能看到本校范围内的商家。最简单的设计是user表加school_id字段merchant表也加school_id字段查询菜品时通过商家关联过滤学校。我在实际项目中还加了一层“校区”的概念比如某高校有东校区和西校区学生默认有一个主校区可以切换。配送费在跨校区时会发生变化。由于系统规模不大我用一套school表和campus表配合外键字段campus_id存储。这个设计在演示时是一个不错的加分点能体现你对业务场景的理解深度而不是仅仅实现了通用的CRUD。4. 登录与权限学生、商家、管理员三种身份的Session处理4.1 单表多角色还是分表存储这是我踩过的一个重要设计坑。最开始我把学生、商家、管理员分别建了user、merchant、admin三张表登录接口时分三套逻辑去验证结果写出来的代码大量冗余拦截器也不好处理。后来我重构为单用户表加role字段统管三种身份。用户表中role字段取值为1、2、3分别对应学生、商家、管理员。商家额外有merchant表补充店铺维度的信息user表只存登录账号和基础字段。登录接口只需要执行一次验证逻辑根据返回用户实体里的role字段再做后续分支处理。登录成功后将用户对象放入Session中后续请求通过拦截器统一识别当前登录用户身份及角色。这里涉及权限控制的层面。学生端接口要求role1商家端接口要求role2管理员接口要求role3。我将注解RequireRole标注在Controller的方法上在拦截器里读取该注解并进行权限校验。4.2 拦截器实现细节拦截器的核心逻辑分为三步第一步从请求中取出JSESSIONID进而还原Session中的登录用户第二步根据路径前缀判断请求归属哪一端第三步根据角色注解校验权限。部分接口比如菜品浏览、轮播图查询允许游客访问就在注解上标记permitAll。Session会话过期时间要做好规划。学生用户可能中午订完餐下午继续刷页面Session过期时间我设置为2小时商家端操作频繁但通常是店员操作设置为1小时管理端后台操作相对低频也设置2小时。实际开发中要注意浏览器端刷新页面时Session还在但小程序端的Session机制需要自己在请求封装里携带凭证信息。小程序是前后端分离的典型场景服务端同时开启基于Session和基于自定义Token两种方式并无必要我最后统一用Session方式小程序端保持了同一会话上下文。身份认证这块最容易被忽视的环节是“未登录状态下的接口返回”。如果拦截器发现未登录用户直接返回401前端需要在请求封装里全局拦截401并跳转到登录页。我初期项目没做统一处理每个页面都单独写判断后来封装了一请求工具类加上对应的拦截函数问题彻底解决。5. 点餐下单的核心流程购物车、订单、支付模拟与超时处理5.1 购物车的前后端交互设计学生端点餐的第一步是加购物车。设计中购物车以商家为维度进行隔离。这个维度在代码中体现为用户加购物车时必须携带商家id前端封装的加购接口会自动判断当前购物车里是否存在其他商家的商品如果存在就弹窗提示“清空购物车或直接下单”的选择。购物车接口我设计成四个清理的端点GET /api/cart/list 前端购物车角标用的数量统计 POST /api/cart/add 添加菜品到购物车 PUT /api/cart/update 修改菜品数量 DELETE /api/cart/empty 清空购物车实现过程中我遇到一个边界问题购物车里的同一个菜品如果重复添加要不要合并数量。我之前遇到过用户反复点加购按钮加了10次同一个菜购物车列表显示10条重复记录结算时数量计算就乱了。后来在add接口里加了合并逻辑同一用户、同一商家、同一菜品已经存在时只改数量不加新记录。这个操作虽然简单但直接影响前端展示的整洁度。5.2 下单接口的业务事务处理下单是整个系统中业务逻辑最集中、事务要求最高的接口。核心操作链路如下从请求体中获取配送地址id、用户备注、购物车中选中的商品列表查询商家信息校验营业状态和起送价计算商品总金额遍历每个菜品单价乘以数量累加再参考购物车快照字段计算配送费和包装费。包装费我在商家表里并没有单独设置实际是菜品自带的“打包价”额外计算每份菜打包价从0到1元不等生成订单列表数据并计算总金额。订单总额 商品总金额 配送费 包装费。校验是否达到商家起送价减库存。实际库存字段我并没有做得非常复杂只做了简单的可用库存判断如果某菜品已售罄或剩余库存不满足购买数量则直接抛出异常生成订单编号订单状态置为0待支付清空购物车中已结算的菜品返回订单详情供前端跳转支付页。生成订单编号我最初用的时间戳格式比如2025000112100001这种但同一秒生成两单可能重复。后来改成“日期 用户id后四位 6位随机数”的组合并在数据库为订单编号建立唯一索引兜底保证不重复。第6步减库存这里隐藏了一个并发问题。如果两个用户同时下单购买同一款只剩下1份的菜品可能出现超卖。我在菜品表增加了一个库存字段stock下单时使用UPDATE dish SET stock stock - ? WHERE id ? AND stock ?这种条件更新SQL确保减库存操作原子化。受影响行数为0时表示库存不足立即返回异常。5.3 支付模块的实现选择校园项目中接入真实的支付宝或微信支付需要商户资质绝大多数课程设计根本不具备这些条件。我建议用一种“模拟支付”来实现在支付接口里不做真实扣款只校验订单状态和金额后直接将订单状态从待支付改为待接单并记录模拟支付时间。如果将来要接入真实支付替换点也已经预留好集中在PayService接口目前提供的是MockPayServiceImpl。要注意的坑是支付回调是异步的真实支付环境下服务器需要接收支付网关的回调通知这时候不能用Session判断用户身份只能通过商户订单号关联订单。模拟支付接口里我保留了orderNo入参就是为了以后对接真实支付时无需改动Controller层。5.4 超时未支付自动取消订单校园用户经常把订单加进购物车后忘记支付导致商家收到大量待支付垃圾订单占用备餐资源。因此我实现了超时取消机制。方案有几种定时任务扫描数据库、Redis延迟队列、或者下单时写入过期时间。最稳妥且容易实现的方式是Spring的Scheduled定时任务每30秒扫描一次订单表将创建时间超过15分钟且处于待支付状态的订单自动置为已取消并恢复对应菜品的库存。代码如下Scheduled(fixedDelay 30000) public void cancelExpiredOrders() { LocalDateTime deadline LocalDateTime.now().minusMinutes(15); ListOrders expiredOrders ordersMapper.selectList( new LambdaQueryWrapperOrders() .eq(Orders::getOrderStatus, 0) .lt(Orders::getCreateTime, deadline) ); for (Orders order : expiredOrders) { cancelOrder(order); } }恢复库存时要注意在事务里操作防止取消订单过程中出现部分库存已恢复、部分因异常导致数据不一致的情况。这个定时任务的调度方式在单体项目里足够。后期如果订单量上来可以考虑改用RabbitMQ延迟队列那就是后话了。6. 商家端与配送逻辑接单、出餐、送达的状态流转6.1 商家端订单列表与状态操作商家端是整个业务闭环中极易被忽略的一个环节。很多外卖系统Demo只做了用户点餐和后台管理商家端却缺失导致订单状态永远卡在“待接单”无法流转。我在设计时把商家端单独作为一个H5页面嵌入管理后台商家登录后可以看到所有属于自己店铺的订单并按状态tab分类。商家可执行的操作有四个接单、拒单、出餐、完成。接单本质是将订单从1待接单改为2已接单/制作中拒单则是将订单改为5已取消同时给用户发送一条退款/取消通知。出餐操作改为3配送中表示餐品已打包好等待骑手或自提。这里需要注意出餐操作是在“已接单”之后才能触发前端按钮也要根据状态动态展示。6.2 校内配送还是自提校园场景和社区外卖的差异在配送环节表现最为明显。考虑到校园内禁止社会骑手进入我设计了两套配送模式商家自配送商家自己配送至宿舍楼下或教学楼固定取餐点适合校内商家。用户自提订单完成后用户收到取餐通知自行前往商家窗口核对取餐码拿餐。我在订单表里增加了字段delivery_type值为1自配送、2自提。这个字段在订单提交时选择商家接单后根据类型展示不同操作。如果是自提出餐后订单直接变为4已送达/完成然后在商家端待取餐列表显示取餐码。如果是自配送出餐后变为3配送中由配送员确认送达后变为4已送达。这里有一个很细节的逻辑自提模式下“出餐”和“送达”是同一个动作但页面展示上仍然要区分。用户看到的状态变化应该是“商家已出餐请到窗口取餐”而不是直接跳到“已送达”。我通过把取餐码下发到用户端和商家端双方对照取餐码完成提货在数不清的演示项目里这一环最容易做漏。6.3 订单统计与商家端数据看板商家首页需要展示今日营业额、今日订单数、待处理订单数、热销菜品TOP5这几个核心指标。SQL层面用一次聚合查询就能得到大多数指标但热销菜品需要关联订单明细表按菜品分组求和。由于菜品名称做了快照分组维度直接用菜品名称即可非常干净。统计接口也有几个坑要提醒。一是时区问题MyBatis-Plus查询当日订单时如果用前端传入的字符串日期需要统一转换为LocalDateTime区间注意数据库时区和服务器时区要保持一致。二是聚合统计要加商家id条件过滤防止商家A看到商家B的数据。这个问题初版确实出现过原因就是统计SQL漏了商户维度过滤后来排查时用两个商家账号交替登录比对数据才发现。7. 部署、测试与避坑实录从本地启动到服务器上线7.1 本地环境准备与启动步骤拿到源码后第一步是导入数据库脚本。SQL文件在源码包的db目录下建议用Navicat或命令行执行整个脚本它会自动建库建表并插入初始数据。初始数据包含一个演示商家账号和若干测试菜品方便直接体验完整流程。第二步修改后端配置文件application.yml中的数据库连接信息和上传文件保存路径spring: datasource: url: jdbc:mysql://localhost:3306/campus_order?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: yourpassword servlet: multipart: max-file-size: 10MB max-request-size: 20MB第三步启动后端主类确认8080端口未被占用。最后将前端管理后台项目用npm run dev启动小程序端用微信开发者工具打开并修改项目根目录的接口地址为http://localhost:8080。需要注意的是微信开发者工具中默认不能访问localhost需要勾选“不校验合法域名”选项。小程序端的网络请求封装我已经在utils/request.js里写好了把baseURL改成你本机的局域网IP即可真机预览时也用这个地址。7.2 我踩过的坑和排查过程第一个坑是前端上传菜品图片时一直报404。后来排查发现图片保存路径配置写成了相对路径./uploadSpringBoot打包成jar后工作目录是临时目录重启后文件就没了。正确做法是在配置文件中指定一个绝对路径比如/home/ubuntu/campus/upload/同时配置一个虚拟路径映射到磁盘目录。第二个坑是中文乱码。MySQL连接串里如果没有characterEncodingutf8菜品名称和商家公告会出现问号。我在application.yml中加上了参数同时建表时统一使用utf8mb4字符集。utf8mb4和utf8的区别在于前者能存emoji表情用户备注里如果带表情utf8会直接报错。这个坑浪费了我一下午。第三个坑是跨域导致登录Session丢失。管理后台和小程序分别调用接口axios默认不携带cookie设置withCredentials: true后前端才能把Session标识带给后端。我一开始只配置了后端的跨域允许忘记调整axios的withCredentials导致用户明明登录成功再点其他接口时又被拦截下来。检查了半天才发现是这个原因。第四个坑是默认密码安全问题。系统初始化创建的管理员账号密码均为admin商家账号密码均为123456。部署到公网时必须修改初始密码我遇到过不修改默认密码导致服务器数据库内容被篡改的真实事件这个真不能懒。7.3 Linux服务器部署步骤服务器部分我只用一台2核4G的云主机系统为Ubuntu。部署步骤大致如下安装JDK 8或11设置JAVA_HOME环境变量。安装MySQL 8并导入初始化脚本。安装Nginx做反向代理。后端打包发布cd campus-order mvn clean package -DskipTests nohup java -jar target/campus-order-0.0.1-SNAPSHOT.jar \ --spring.profiles.activeprod /usr/local/logs/order.log 21 前端项目构建后把dist目录放到Nginx的html目录下Nginx配置里加入location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }如果部署的是小程序端后端域名必须是HTTPS微信官方要求所有请求为HTTPS协议。我自己最初只用了HTTP小程序真机预览时请求全部被拦截后来用云厂商的免费SSL证书配置到Nginx才解决。这一步在正式部署时千万不能跳过。部署完成后我习惯先跑一遍核心链路学生用户登录→浏览商家→加购菜品→下单→模拟支付→商家端接单→出餐→送达→后台统计查看。这个链路走通部署就算成功了。8. 从课程设计到真实产品这套系统还能怎么扩展做完这套系统之后我对校园订餐外卖业务有了更深的理解。很多同学拿到源码跑通后就以为结束了但真正能让简历或答辩出彩的往往是在基础版本之上再做一层有价值的扩展。基于当前架构和源码几条比较顺畅的扩展路径如下第一引入消息推送机制。现在用户只能在订单详情页刷新看状态体验不够流畅。如果引入微信小程序订阅消息订单状态每变更一次就向用户推送一条模板消息用户感知会好很多。微信订阅消息的接入需要在后端调用接口获取access_token再把订单状态变更事件和用户openid绑定逻辑上并不复杂就是HTTP请求加Token管理。第二升级为Redis 延迟队列处理超时订单。当前定时任务扫描方案在数据量大时会有分钟级延迟且每次扫描全表比较浪费。用Redis存储订单ID和过期时间戳配合延迟队列或者Redisson的看门狗机制可以做到秒级取消也大大降低数据库压力。第三增加营销模块。比如满减优惠、新用户立减券、限时秒杀。满减计算要叠加在订单总额上这意味着订单表需要增加“优惠金额”字段和“优惠明细”扩展表。在数据库设计中预留冗余字段并做好优惠快照这个方向能在项目演示时大幅提升商业完成度。第四完善配送人员管理。如果要做真正的配送调度还需要骑手表、配送任务表、位置上报接口。目前订单表中只存了配送方式和状态缺少配送员的关联字段。增加一个delivery_person_id字段扩展接口是件顺理成章的事。第五接入真实支付。正如前文所说PayService已经留好了接口边界只需要实现RealPayServiceImpl接入支付宝的沙箱环境即可完成真实支付闭环。支付宝沙箱不需要真实商户资质是练习接入第三方支付接口非常好的途径。扩展建议这块我个人的看法是别贪多选一个方向做深。把消息推送和营销模块做透已经足够在答辩或面试中讲出完整的故事了。贪多嚼不烂反而容易哪个都做不好。最后分享一个实际开发中的体会校园订餐这类系统真正的难点从来不是写几个CRUD接口而是想清楚业务状态怎么流转、数据快照怎么设计、边界条件怎么处理。我刚动手时也走了不少弯路最开始订单表没有快照字段商家改价后历史订单金额跟着变被测试的同事连续吐槽了好几天。后来又重新设计了订单明细表才把这个问题彻底根治。做项目就是这样踩一次坑记住一次。这套源码不是终点把它当成一个可以“折腾”的半成品多改改、多打补丁技术能力反而提升得更快。如果你打算拿这个项目参加课程设计或毕业设计我建议先完整跑通主流程然后针对你感兴趣的模块做深度优化而不是把全部时间花在堆功能数量上。一个模块做到极致远比十个模块都做得一般更让评审老师印象深刻。