Spring Boot校园外卖平台实战：订单状态机与Redis缓存设计

1. 项目整体设计与技术选型思路1.1 为什么选Spring Boot来做校园外卖平台聊到用Spring Boot做校园外卖平台系统很多人的第一反应是“这不就是个课程作业吗”。其实把场景限定在校园里这个系统的复杂度比我最初预想的高不少。校园外卖和普通外卖最大的区别在于用户密度高、配送范围集中、下单时间高度集中在饭点、支付和优惠券逻辑相对简单但订单量波动极大。这些特点决定了技术选型的方向——不需要分布式微服务那一套重武器但必须在单体应用内把并发、缓存、状态机这些基本功打扎实。Spring Boot在这个场景里几乎是唯一一个性价比拉满的选择。它自带Tomcat容器打成一个jar包就能跑对初学者友好同时它的自动配置机制让我们不需要花大量时间写各种XML配置能把精力集中在业务细节上。我见过一些同学拿SSMSpringSpringMVCMyBatis去写类似的系统代码量差不多少一半但踩的坑多一倍——光各种配置文件之间的版本兼容问题就能耗掉好几个晚上。Spring Boot的另一个优势是生态成熟无论是MyBatis分页插件、Redis缓存还是JWT鉴权都有大量的现成集成方案这在时间宝贵的毕业设计或个人项目阶段非常关键。再说说为什么不做成前后端分离。如果你只是做一个课设级别的系统模板引擎Thymeleaf就够用了但如果目标是“拿得出手”的个人项目我强烈建议用Spring Boot Vue的前后端分离架构。理由很简单校园外卖的典型使用场景是手机端H5接口化设计天然适配而且面试时前后端分离的经历更能展示你的工程化意识。当然这也意味着你要额外处理跨域、Token鉴权、接口文档这些事后面我会详细讲。1.2 技术栈选型背后的取舍考量具体到技术栈我采用的是目前主流的组合Spring Boot 2.7.x MyBatis Plus Redis JWT MySQL Vue 3。这套组合的兼容性非常成熟网上资料也多出了坑很容易找到解决方案。选择MyBatis Plus而不是原生MyBatis是因为它内置的分页插件和条件构造器能大幅提升开发效率。做外卖平台必然涉及大量列表查询——比如按分类查菜品、按时间查订单、按模糊名查店铺——用手写SQL映射会很繁琐而MyBatis Plus的LambdaQueryWrapper一行就能搞定。但有一点需要注意MP的分页插件需要单独配置拦截器否则分页不会生效这个问题几乎每个入坑的人都会遇到一次。Redis在这个项目里的角色很关键。我做设计了三个核心用途缓存菜品分类和热门店铺、存储短信/图形验证码、维护购物车数据。前两个是典型的缓存加速场景第三个其实是把Redis当成临时数据库用——购物车的读写频率高、有效期短落到MySQL反而浪费。另外订单号生成我用了Redis的自增ID加日期前缀的组合方式避免数据库自增ID在并发下产生重复或泄露订单量。JWTJSON Web Token用来做登录鉴权。用户、商家、骑手三类角色共用一个认证机制但需要在校验时区分角色权限。这个设计看似简单实际写代码时要处理Token过期续期、不同端小程序端和后台管理端的密钥隔离、TOKEN刷新策略等细节稍不留神就会出一堆安全漏洞。1.3 系统模块与功能边界划分校园外卖平台的业务核心可以拆成三个端用户端微信H5或普通H5、商家端PC管理后台、管理端平台运营后台。用户端负责注册登录、浏览店铺菜品、下单支付、订单跟踪、评价商家端是商家管理自己的菜品、订单处理、营业状态切换管理端是平台的最高权限处理店铺审核、用户管理、骑手调度、数据统计。模块拆分要遵循一个原则高内聚低耦合。比如“订单服务”只负责订单的创建、状态流转、取消不关心支付具体怎么调用第三放接口“支付服务”只对接支付回调回调成功后通过MQ或定时任务通知订单服务更新状态。这样拆哪怕最后没有用消息队列直接同步调用代码也清晰得多。我见过不少人把商家、用户、骑手的所有功能全部塞进一个Controller里一个类几百行改一个功能要牵扯一片。正确做法是至少按角色拆Controller或者更细一点按业务域拆分AuthController登录注册、ShopController店铺、DishController菜品、CartController购物车、OrderController订单、AddressController地址管理等等。每个Controller只做参数校验、调用Service、返回结果这三件事。2. 数据库设计与核心表结构2.1 六张核心表的角色分配数据库设计是整个系统中最不能糊弄的部分。很多初学者一上来就建表想到什么加什么字段结果后期要么缺字段反复改表结构要么一个表存了太多无关信息。我的做法是遵循“第一范式起步按业务域拆分”的思路最终落地为六张核心业务表加若干辅助表。用户表user存储用户基本信息包括昵称、手机号、头像、密码BCrypt加密存储、学号校园场景的独特字段。这里有个容易忽略的点——手机号是用户登录的凭证之一必须加唯一索引但有些学校的用户可能没有绑定手机号、只支持学号登录所以登录字段设计上要留出扩展的可能。店铺表shop和菜品表dish是商家端的核心。店铺要记录店铺名称、公告、起送价、配送费、营业状态1营业、0休息、评分。菜品表要关联店铺ID同时要有菜品分类字段比如“招牌热菜”“饮品小吃”、库存量、月销量、图片URL和上下架状态。关于库存我多说一句校园外卖场景下菜品库存不像电商那么复杂不需要精确到SKU级别但至少要有“沽清”概念也就是售完自动下架这个字段设计出来不难难的是并发扣减库存时不超卖。订单表orders是系统中字段最多的表包含订单编号、用户ID、店铺ID、订单金额、配送地址、订单状态、支付状态、收货人信息姓名、电话、地址、骑手ID、备注信息、创建时间和支付时间。这里有一个重要设计就是订单金额必须保存为快照不能去查询商品表现算——因为菜品可能改价或下架金额快照才能保证历史订单的数据准确。地址信息同理直接冗余在订单表里不要关联用户地址表因为用户搬家后历史订单还要能看收到哪里。订单明细表order_detail记录每笔订单包含了哪些菜品、单价、数量、小计金额。它和订单表是父子表关系。再接下来是购物车表cart、地址表address、骑手表rider和系统管理表sys_user。完整建表脚本我就不贴了太长但在设计上有一个关键心得所有表都必须有create_time、update_time这两个字段并且用ON UPDATE CURRENT_TIMESTAMP自动维护否则后期排查问题会非常痛苦。2.2 订单状态字段的设计陷阱订单状态是整个外卖平台中最容易翻车的部分。很多人的第一版设计是直接用一个状态字段存字符串比如“待支付”“已支付”“配送中”“已完成”这样看起来直观但后续做状态统计、异常订单处理时就会很麻烦。我的建议是使用整数状态码通过常量或枚举类统一管理。我的状态机设计是这样的0待支付、1待接单、2已接单备餐中、3配送中、4已完成、5已取消、6退款中、7已退款。注意取消操作在什么状态下允许支付前用户主动取消没问题商家接单后只能申请退款不能简单取消配送中状态下用户取消需要走退款申请流程。这些状态之间的流转规则如果不提前定义清楚代码里就全是散落的if判断时间一长逻辑就乱成一团。具体实现上我推荐用策略模式或者状态机框架来管理流转。比如Spring StateMachine但对这个项目体量来说有点重用自定义的OrderStatusEnum加一个OrderStateValidator工具类就够了核心是维护一张状态流转的规则表每个状态下能执行哪些操作、操作需要什么权限、操作成功后跳到哪个状态。这样写的好处是当你想加一个新功能比如“模拟超时自动取消”只需要在这个规则表里加一条记录就行。2.3 购物车与库存的细节设计购物车是用户端体验的直接影响因素。我用Redis的Hash结构来存储key是cart:userIdfield是dishIdvalue是数量。用户加购一个菜品直接HINCRBY cart:1001 10101 1只有一行代码性能碾压MySQL。但这里有个体验问题同一店铺的菜品才能同时下单跨店时需要提示用户当前购物车中存在其他店铺的商品。这个校验放在后端添加菜品到购物车时就把shopId一起存进Redis判断是否和已有菜品来自同一店铺。库存扣减是另一个高频问题。校园外卖的菜品备货量一般不大我不建议引入复杂的分布式锁最简单可靠的方式是数据库乐观锁。UPDATE dish SET stock stock - 1 WHERE id ? AND stock 0通过受影响行数判断是否扣减成功失败则提示用户“菜品已售罄”。这个方案在单机应用下完全够用。如果以后订单量上来再考虑引入Redis预扣库存MQ异步落库的方案也不迟。3. 关键功能实现与原理解读3.1 JWT登录鉴权的完整流程JWT在这里承担的是“无事发生但一旦需要检查立刻能拿出身份凭证”的通行证职责。实现思路并不复杂用户登录成功后服务端用密钥生成一个包含用户ID、角色、过期时间的Token返回给前端前端在后续请求的Header中带上Authorization: Bearer token后端通过拦截器或过滤器统一解析并校验Token。让我细说下实现细节。生成Token时我用了io.jsonwebtoken这个库核心配置分三段Header算法和令牌类型、Payload用户信息和过期时间、Signature用HMAC-SHA256算法对前两段进行签名。签名密钥必须在application.yml里配置不要硬编码在Java类里方便环境切换。过期时间我会设置成24小时前端拿到Token后存到localStorage并在请求拦截器里统一添加Header。校验环节我用Spring MVC的HandlerInterceptor配置拦截规则为/api/**并排除/api/login、/api/register、/api/shop/list、/api/dish/list这些公开接口。用户端、商家端、管理端三个角色用不同的访问前缀区分比如/api/user/**、/api/merchant/**、/api/admin/**拦截器里获取到Token中的角色字段后判断是否有权限访问对应前缀这样一套逻辑就能覆盖三个端的鉴权需求。有一个关键细节容易被忽视JWT一旦签发在过期之前是无法撤销的。如果用户退出登录前端直接删除Token即可但服务端这边没有感知。所以我在Redis里存了一份“黑名单”key是jwt:blacklist:{jti}用户退出时将jtiJWT的唯一ID塞进去并设置剩余有效期后续请求校验时先查一下黑名单命中就拒绝访问。这样才算一个完整的退出登录闭环。3.2 Redis在购物车和验证码场景的使用Redis在项目里不止做缓存它还承担了几个关键的“状态存储”任务。第一个是短信验证码的存储和校验。注册和登录页面输入手机号后获取验证码服务端生成6位随机数以sms:code:{phone}为key、验证码为value存入Redis并设置5分钟过期校验时取出来和用户输入比对。这里我踩过一个坑同一手机号60秒内只能发送一次防止短信轰炸这个限制必须在后端做不能只靠前端按钮倒计时。第二个是图形验证码。校园外卖后台管理端登录时会用到Kaptcha生成图形验证码同样存入RedisKey设计成captcha:{uuid}用户提交登录时带上uuid和验证码值成功后立即删除保证一次性有效。这里有个细节图形验证码的过期时间通常是2分钟但我在实际测试中发现用户扫码或输入可能要多次尝试过期时间设置为3分钟更合理同时每次校验失败就删除避免暴力破解。第三个是购物车存储前面提过用Hash结构。提一个实际的Redis使用经验一定要给所有业务key设置过期时间特别是验证码类可以防止脏数据累积导致Redis内存膨胀。另外Redis的连接池大小要合理配置默认lettuce的配置可能不够支持高并发场景我在spring.redis.lettuce.pool里设置max-active16、max-wait3000ms在实际压测中表现还可以。3.3 订单状态流转的并发控制外卖平台在饭点高峰期会遇到“同一时间大量用户同时下单”的情况。订单创建的核心逻辑分三步扣减库存、生成订单记录、清空购物车。这三步必须在一个事务里完成任何一个环节失败都要回滚。我的下单接口Service层加Transactional注解但这只是基础。更关键的是扣减库存用乐观锁SQL同时订单表必须设置店铺ID索引和用户ID索引否则订单量上来后查询会非常慢。还有一类并发问题用户在下单的同时取消订单。如果取消操作发生在支付回调之后会导致“订单已支付但被取消了”的状态错乱。我在支付回调处理时加了状态校验只允许从“0待支付”流转到“1待接单”否则返回失败并记录日志。这就是前面状态机设计的价值——状态流转的定义清晰了并发控制就有了依据。另外说一个订单号生成的方案。不使用数据库自增主键做订单号我采用Redis的INCR命令生成自增序列拼接日期格式的字符串形如20250606120000123456长度18位。这样既能保证唯一性又能在日志里一眼看出订单的创建时间排查问题时非常方便。3.4 MyBatis分页插件的用法校园外卖系统的后台管理端必然需要分页列表。MyBatis Plus的分页插件配置很简单注册一个MybatisPlusInterceptorBean并添加PaginationInnerInterceptor即可。只有配置了拦截器Page参数才有效否则底层SQL不拼接LIMIT会把全表数据查出来内存分页数据量一大直接内存溢出。实际使用时的最佳实践是Service层的方法接收一个Page对象和查询条件DTO返回IPageT类型。以订单管理页面来看代码是page(new Page(pageNum, pageSize), new LambdaQueryWrapperOrder().eq(Order::getShopId, shopId).orderByDesc(Order::getCreateTime))。这里有两个性能优化细节第一分页查询时不要select *尽量只查需要的字段如果实体类字段过多就用select指定第二订单表的明细字段如果太大建议单独建一个轻量VO不要把所有字段全返回前端。还有一个小坑要提醒分页插件和自定义SQL的复杂JOIN查询搭配时如果COUNT查询出错需要手动指定optimizeCountSql参数或者检查SQL是否有问题。实际开发中我一直保留一个原则——尽量通过单表查询配合二次过滤来完成列表展示少用复杂的多表关联不仅性能更好代码也更简单。4. 实操过程从零搭建核心模块4.1 项目初始化与目录结构要想复制一个能跑起来的项目初始化这一步必须做对。用IntelliJ IDEA创建Spring Boot项目时我建议直接通过Spring Initializr生成选择Java 8、Spring Boot 2.7.18版本依赖勾选Spring Web、MyBatis Framework、MySQL Driver、Spring Data Redis、Lombok、Validation。为什么选2.7.18而不是3.x因为3.x基于Jakarta命名空间改动较大很多网上资料和第三方库还没完全适配对于学习型项目没必要给自己增加难度。目录结构上我采用标准的Controller-Service-Mapper三层结构同时增加config、common、vo、dto几个包。common里放统一返回结果类Result、异常处理类BusinessException和全局异常处理器GlobalExceptionHandlerdto放接收前端参数的类vo放返回给前端的视图对象。这样分层之后每层职责非常清晰写代码时基本不会迷路。有一个非常关键的配置跨域处理。前后端分离后前端运行在localhost:8080后端在localhost:8081如果不配置CORS跨域资源共享前端所有请求都会被浏览器拦截。我写了一个CorsConfig类实现WebMvcConfigurer的addCorsMappings方法允许所有来源、所有请求头允许GET/POST/PUT/DELETE/OPTIONS方法。当然这里存在安全隐患但放在开发环境没问题上线时可以收紧为具体域名。4.2 实现一个下单接口的完整流程我以“用户下单”这个核心接口为例串一遍完整的代码逻辑。前端请求参数为{shopId, addressId, remark, cartItems: [{dishId, quantity}], totalAmount}。Controller层非常简单PostMapping(/order) public ResultString createOrder(RequestBody Valid CreateOrderDTO dto) { return Result.success(orderService.createOrder(dto)); }Service层的createOrder方法核心逻辑用伪代码描述如下第一步根据userId从Redis中读取购物车数据校验菜品都属于同一店铺且都在上架状态。第二步遍历购物车逐条执行乐观锁扣减库存。注意如果某条扣减失败抛出业务异常触发整体回滚。第三步计算实际订单金额后端根据菜品单价和数量重新计算不信任前端传的totalAmount插入订单主表和订单明细表。第四步异步清空Redis购物车。第五步发送MQ消息通知商家端有新订单如果没有MQ就用Spring的事件机制或直接同步更新商家端的待处理订单列表。中间有很多细节值得展开。比如金额计算我用BigDecimal而不是double避免精度丢失比如地址信息从地址表读取后快照到订单表比如下单后要记录日志方便后续追踪。4.3 Docker部署Java应用的实践项目完成后部署环节我用Docker搞定避免每台服务器都要装一套JDK和MySQL。编写一个最简单可行的DockerfileFROM openjdk:8-jre-alpine MAINTAINER yourname COPY target/order-system.jar /app/order-system.jar WORKDIR /app EXPOSE 8080 ENTRYPOINT [java, -jar, /app/order-system.jar]这个Dockerfile的要点是使用多阶段构建或者配合Maven构建出可执行的jar包后直接COPY进镜像。我在实际部署时还写了一个docker-compose.yml同时编排MySQL、Redis和应用容器一套命令docker-compose up -d就能启动全部依赖这对本地联调和演示都非常方便。部署方面有两个核心经验一是容器时区问题默认的Alpine镜像时区是UTC会导致打印的日志时间比北京时间慢8小时必须在Dockerfile里加上RUN apk add --no-cache tzdata cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime二是Java进程内存配置Docker容器内没有默认的JVM调优建议在启动参数中设置-Xms256m -Xmx512m避免容器内存被吃掉太多导致OOM重启。5. 常见问题与排查技巧实录5.1 经典报错及解决方案开发过程中我整理了一张问题排查表这些都是学生项目里极高概率踩的坑。问题现象根本原因解决方案分页不生效查出全表数据缺少分页插件拦截器配置新增MybatisPlusInterceptorBean并注册PaginationInnerInterceptor前端调用接口报跨域错误后端未配置CORS写CorsConfig类实现跨域配置POST请求报415 Unsupported Media Type前端未设置Content-Type: application/json前端请求头统一设置JSON格式中文乱码数据库连接串缺少编码参数JDBC URL加?useUnicodetruecharacterEncodingutf8登录后请求接口401JWT Token过期或未携带检查本地存储Token及请求拦截器Tomcat报端口被占用默认8080端口被其他程序占用改用--server.port8081或者配置随机端口插入订单数据超时数据库连接池没配好检查sprint.datasource配置合理设置连接池大小5.2 前端联调中的体验优化项目做完后我花了很多时间在联调和交互体验上。后端接口返回格式统一为{code, message, data}其中code200代表成功前端拦截器只认这个约定。有一段时间我自己接口写得很随性有的返回data有的返回result联调时前端同学气得够呛。后来我也总结了一个心得接口契约文件必须在编码前定义哪怕是简单的表格或Swagger注解也比后面对着一堆乱糟糟的接口文档改代码舒服。关于图片上传菜品和店铺都涉及图片。学生的本地环境可以用Base64上送太大了建议用对象存储方案或直接服务器存储并返回静态资源URL。这里要注意的一个细节是Spring Boot上传文件的默认大小限制是1MB菜品图片稍微大点就上传失败需要在application.yml配置spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB联调时顺带把登录态的细节完善了一下用户刷新页面时前端会先调用/api/user/info根据返回的code判断Token是否过期来决定是否跳转登录页这个前置校验比等接口报错再跳转的体验好很多。5.3 压力测试与性能观察的小心得项目完成后建议做一次简单的压力测试。我测试时用JMeter模拟100个并发用户同时下单观察数据库连接数占用和接口响应时间。测试过程中发现两个有意思的现象一是乐观锁扣库存确实能防止超卖但并发过高时会有大量失败请求这时候用户体验会很差考虑引入Redis预扣减库存就会好很多不过对于课设项目把失败信息返回成“手速太快啦请重试”也就够了。二是Redis连接池默认配置下验证码接口的并发能力会先于数据库成为瓶颈所以我把lettuce.pool的max-active从默认值调大了一些。最后说说项目结构的长期维护。我做这个项目时就坚持写简洁的Git提交记录每完成一个模块就提交一次而不是一口气提交所有代码。后来项目进了面试注意点清单别人问起来我能清楚地讲出每个模块的迭代过程这种记录习惯本身也是专业素养的一部分。一个人从零做起一个校园外卖平台确实会遇到不少麻烦但把每一步踩过的坑都记录下来这本身就会让你比只调用接口的“熟练工”强得多。项目做到后期我更强烈地体会到Spring Boot框架是工具真正决定项目上限的是你对业务的理解、对状态流转的定义和对细节的把控。这套系统按上面的方式开发完如果还有精力建议把Redis缓存热数据和MQ异步解耦再打磨一遍整个项目的含金量会再上一个台阶。