网上点餐系统这个题目，在Java毕设和课设里算是常客了。但说实话，十份作品里能称得上“完整可用”的，我见过的不超过三份。大多数不是卡在CRUD写不完，就是前后端联调直接摆烂，最后搭个半成品上去答辩。这次我基于SpringBoot+Vue+MySQL+MyBatis这套组合，完整走了一遍从需求拆解、数据库设计、后端接口实现到前端页面联调的全流程，并且把其中真正折磨人的细节——比如MyBatis动态SQL里的类型比较坑、订单事务边界怎么划、Vue打包后资源404怎么处理——全部记录下来。这篇文章不是教科书式的架构讲解，就是我实际做这个项目时的完整记录和踩坑复盘，适合正在做毕设、课设，或者想自己从零写一套前后端分离项目练手的同学参考。
1. 先别急着写代码：点餐系统的需求拆解和模块边界
很多同学拿到这个题目，第一反应是建个SpringBoot工程，然后把用户表、菜品表、订单表一建，就开始写增删改查。这样做到一半一定会乱。原因很简单：点餐系统看起来是标准的CRUD，但真正写完你会发现，角色权限、订单状态流转、库存扣减这些逻辑互相牵扯，没有提前把边界划清楚，代码写到最后就是一团浆糊。
1.1 这个系统到底要解决什么问题
网上点餐系统的核心场景是：用户打开网页，浏览菜品分类，把想吃的菜加入购物车，提交订单；商家在后台看到新订单，接单并开始制作；用户能看到订单状态变化。贯穿全程的三个核心实体就是菜品、订单、用户。
但“能点餐”只是表面需求。真正的需求是“订单状态的完整流转”。用户下单之后，订单不是一步到位的，它至少经历：待支付、待接单、制作中、已完成（或者配送中）、已取消这几个状态。谁来改状态、怎么保证状态不被乱改、用户取消订单时商家那边怎么同步，这些才是系统的骨头。
我把角色拆成了三类：普通用户、商家（管理员）、超级管理员。用户负责浏览、下单、支付模拟、取消订单；商家负责菜品上下架、分类管理、接单和完成订单；超级管理员管用户、管商家、看整体统计数据。三个角色的功能域在模块设计阶段就必须分开，不然后端接口权限无从谈起。
1.2 角色划分与功能闭环
用户端的功能列表看起来很常规：注册登录、菜品浏览、按分类筛选、搜索、加入购物车、提交订单、查看我的订单、取消订单。但注意，购物车这里就有一个设计分歧——购物车数据存在前端还是后端。
我的做法是：购物车放在后端，采用Redis或者MySQL表存储都行，但考虑到这套系统主要用MySQL，我直接建了一张cart表。原因是购物车如果只放前端localStorage，用户换设备、清缓存，购物车就没了；而且后端保存购物车，下单时可以直接把购物车数据转成订单明细，不用前端传一堆参数，接口会干净很多。
商家端的核心是菜品管理和订单处理。菜品管理里面要注意一个“上下架”逻辑——下架的菜品，用户端就看不到了，但正在进行的订单不能受影响，所以菜品表里要有status字段，而不是删记录。订单处理就是修改订单状态：待接单改成制作中，制作中改成已完成。
管理员端就是标准的用户管理和数据统计。用户管理包含封禁/启用账号；数据统计可以简单点，按日统计订单数、销售额，或者统计销量Top10的菜品，这些SQL都不复杂，但做出来展示效果很好。
1.3 非功能需求：并发、事务和数据一致性
这个项目并发量不会很大，不需要上MQ和Redis集群那一套，但有两个点必须想清楚：下单过程的原子性，以及库存扣减的正确性。
下单这个动作涉及的操作不止一条SQL：要查菜品、计算总价、插入订单主表、插入订单明细表、扣减库存。任何一个环节失败，订单都不能残留半截数据，所以必须包在一个事务里。库存扣减的SQL不能是先select再update，那会出现超卖，虽然小项目不容易并发压测出来，但写代码的时候就要用update dish set stock = stock - 1 where id = ? and stock > 0这种带条件的更新。
这些需求理清楚之后，代码才能写得有条理。下面说技术选型。
2. 技术选型背后的逻辑：为什么是SpringBoot+Vue+MySQL+MyBatis
这个组合是现在Java全栈项目里最主流的搭配，但不是因为它“流行”就选它，而是每一样都有它不可替代的理由。我逐个说。
2.1 后端选型：SpringBoot怎么把开发成本压下来
SpringBoot最大的价值不是“自动配置”这个噱头，而是它把大量原本需要显式配置的东西变成了约定。做这个项目，我不需要写一堆XML配置文件，不需要手动配置DispatcherServlet，一个spring-boot-starter-web依赖加上@SpringBootApplication注解，一个能跑起来的Web服务就出来了。
这里我重点提醒一下版本问题。现在网上很多教程还在用SpringBoot 2.x，但直接新建项目很可能会拉到3.x的版本。SpringBoot 3.x要求JDK17起步，而且包名从javax.servlet换成了jakarta.servlet，这意味着很多老代码复制过来直接编译报错。如果电脑上装的是JDK8，老老实实用SpringBoot 2.7.x，别追求新版本，否则光环境问题就能折腾一整天。我用的就是SpringBoot 2.7.18，稳定且网上资料最多。
2.2 持久层选型：MyBatis的灵活性和可控性
MyBatis和Spring Data JPA争论了很久，但点餐系统这种SQL逻辑比较灵活的场景，我选MyBatis。原因很直接：JPA虽然有自动建表、方法名派生查询这些便利，但一旦涉及多表关联、动态条件查询，要么写JPQL，要么写原生SQL，反而不如MyBatis的XML直观。
MyBatis的核心优势是动态SQL。比如菜品列表的查询，条件可能是“分类ID + 关键词 + 上下架状态”的任意组合，用<where>加<if>标签就能拼出正确的SQL，而且肉眼可见、可控性极强。再加上MyBatis的<collection>标签能方便地映射订单和订单明细这种一对多结构，比JPA懒加载踩坑要省心。
2.3 前端选型：Vue怎么支撑点餐这种交互密集场景
Vue的核心价值是组件化和响应式。点餐页面的核心交互——菜品列表、分类切换、购物车角标、购物车抽屉——这些天然适合拆成组件。Vuex管理购物车状态、Vue Router管理页面跳转、Axios统一处理接口请求，这三件套一套走下来，页面逻辑就清晰了。
版本上我用Vue2。不是因为Vue3不好，而是Element UI这个组件库和Vue2的配合最成熟，网上案例也最多。Vue3配Element Plus当然可以，但如果你是想快速把项目做完，Vue2的学习成本更低，踩坑更容易找到解决方案。
2.4 MySQL为什么够用：数据量和并发量评估
MySQL在这个场景下完全够用，不需要考虑分库分表。点餐系统的数据量级撑死几万条菜品、几十万条订单，MySQL单表轻松扛住。真正要注意的是表的字段类型和索引：订单号的唯一索引、用户ID的普通索引、菜品分类的索引，这些加好了查询不会慢。
版本我推荐MySQL 5.7或者8.0都行。8.0的窗口函数、JSON字段更好用，但驱动配置有点区别——8.0的JDBC驱动是com.mysql.cj.jdbc.Driver，而且URL上要加serverTimezone=Asia/Shanghai，否则会报时区错误。5.7则是万金油，兼容性最好。我都试过，没有本质区别，选哪个取决于电脑上装了什么。
3. 数据库设计：点餐系统的表结构该怎么划
数据库设计是整个项目的底盘，表结构没设计好，后面写SQL就是地狱模式。我按“用户体系-菜品体系-订单体系”三条线来设计，总共六张核心表。
3.1 六张核心表的结构和数据关系
用户表（sys_user）字段：id、username、password（MD5或BCrypt加密）、nickname、avatar、role（USER/ADMIN/SUPERADMIN的整型枚举）、status（1启用/0禁用）、create_time。角色用整型字段存，不要用字符串，查询和判断都方便。
菜品分类表（category）：id、name、sort、create_time。分类表只有一层，不做无限级分类，点餐系统用不上的复杂度就是多余的。
菜品表（dish）：id、category_id、name、image、description、price、stock、status（1上架/0下架）、create_time、update_time。注意price用DECIMAL(10,2)，status必须有，下架不等于删除。
购物车表（cart）：id、user_id、dish_id、dish_name（冗余字段）、dish_image（冗余）、price（下单时的快照价格）、quantity、create_time。这里我冗余了菜品名称和图片，是为了查购物车的时候不用关联菜品表，性能更好，代价是菜品改名后购物车里的名字不同步——但购物车本来就是临时数据，问题不大。
订单表（orders）：id、order_no（业务订单号）、user_id、total_amount、status、remark、address、consignee、phone、create_time、pay_time、confirm_time。注意表名不要叫order，order是SQL关键字，虽然加反引号能用，但没必要给自己挖坑，加个s最保险。
订单明细表（order_detail）：id、order_id、dish_id、dish_name、dish_image、price、quantity、subtotal。明细表的作用是固化下单那一刻的菜品快照。如果以后菜品改名、调价，历史订单依然能还原当时点的是什么。
3.2 订单状态机：状态字段怎么流转
订单状态是整个系统逻辑最复杂的部分。我定义了一组int状态码：0-待支付、1-待接单、2-制作中、3-已完成、4-已取消。状态流转规则如下：
用户下单后状态为0（待支付）；模拟支付成功后变为1（待接单）；商家点击接单后变为2（制作中）；商家点击完成或用户确认收货后变为3（已完成）。用户在下单后、商家接单前可以主动取消，状态变为4（已取消）。
这里要强调一个容易忽略的点：状态变更不是谁都能改的。用户只能取消状态为0或1的订单，商家只能把1改成2、把2改成3。如果不在Service层做状态校验，用户传一个status=3就直接把接口改了，那整个系统就形同虚设。所以状态变更的逻辑必须写在后端，前端只是发起点，真正的状态机校验在后端完成。
3.3 一个容易踩的坑：金额字段到底用DECIMAL还是FLOAT
这是我在这个项目里遇到的最经典的坑之一。如果你用float或double存金额，用户付了0.58元，MySQL里面存进去的可能是0.57999999999999998，查询出来再算总价，分分钟对不上账。浮点数在计算机中是二进制的，很多十进制小数无法精确表示，这不是MySQL的问题，是所有编程语言通病。
正确做法是金额全部用DECIMAL(10,2)，Java实体类用BigDecimal，避免使用double去接。BigDecimal之间做运算用add、subtract、multiply，不要用运算符。这个细节写进项目里，答辩时老师问“为什么金额用BigDecimal”，你能从二进制浮点误差讲到数据库精度，这道题就稳了。
4. 后端实现：从接口设计到MyBatis的使用细节
后端这部分是最容易堆代码但最需要小心的。我按“接口划分、MyBatis关键写法、事务控制、常见坑”四个维度来复盘。
4.1 RESTful接口怎么划分
接口设计遵循RESTful风格，以资源为中心。用户模块：POST /api/user/register、POST /api/user/login。菜品模块：GET /api/dish/list（带分类ID可选参数）、GET /api/dish/{id}。分类模块：GET /api/category/list。购物车模块：GET /api/cart/list、POST /api/cart/add、PUT /api/cart/update、DELETE /api/cart/{id}。订单模块：POST /api/order/submit、GET /api/order/list、GET /api/order/{id}、PUT /api/order/cancel/{id}。管理端：GET /api/admin/order/list、PUT /api/admin/order/accept/{id}等。
权限上，我用SpringBoot的HandlerInterceptor写了一个简单的JWT拦截器。用户登录成功后返回一个token，前端每次请求放在请求头Authorization里，拦截器校验token并解析出userId和role。管理端的接口再根据role做二次校验。不用引入Spring Security，对于这个项目来说太重了，而且配置难度会拖慢进度。
4.2 MyBatis的XML映射和动态SQL写法
MyBatis用XML写SQL，这是它的灵魂。以菜品分页条件查询为例，需要支持从分类ID筛选、关键词模糊查询、状态筛选三个可选条件。SQL写在DishMapper.xml里面：
<select id="selectPage" resultType="com.example.entity.Dish"> SELECT * FROM dish <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND (name LIKE CONCAT('%', #{keyword}, '%') OR description LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select><where>标签会自动去掉第一个多余的AND，这个设计非常实用，不用自己拼WHERE 1=1这种丑代码。动态SQL的<if>里面写OGNL表达式，这是MyBatis最需要小心的点，我下面单独说。
订单和订单明细的一对多映射，用<collection>实现。查询订单列表时，一条订单要带上它的所有明细项：
<resultMap id="OrderWithDetailMap" type="com.example.entity.Order"> <id property="id" column="id" /> <result property="orderNo" column="order_no" /> <result property="totalAmount" column="total_amount" /> <collection property="orderDetails" ofType="com.example.entity.OrderDetail"> <id property="id" column="detail_id" /> <result property="dishName" column="dish_name" /> <result property="quantity" column="quantity" /> <result property="subtotal" column="subtotal" /> </collection> </resultMap>这种映射的重点是SQL联查时明细表的主键必须起别名detail_id，否则如果主表ID和明细表ID都叫id，MyBatis会映射错乱。这个坑我踩过一次，查出来的明细数量总是少了，排查半天才发现是主键冲突。
4.3 事务边界：为什么下单这个操作必须加@Transactional
下单接口的逻辑是：校验菜品是否存在且上架、计算总价、生成订单主记录、批量生成订单明细、扣减库存。这五个步骤必须在同一个事务里执行，因为任何一个失败，前面做的都不能生效。
我在下单Service方法上加@Transactional(rollbackFor = Exception.class)。注意rollbackFor必须指定，因为Spring的默认行为是只对RuntimeException回滚，如果代码里抛的是IOException之类的受检异常，事务不会回滚，数据就出现半截状态。这个细节很多人不知道，但面试和答辩都很喜欢问。
扣减库存的SQL这样写：
UPDATE dish SET stock = stock - #{quantity} WHERE id = #{dishId} AND stock >= #{quantity}stock >= #{quantity}这个条件是我前面提到的防超卖关键。如果更新的影响行数为0，说明库存不足，直接抛出异常回滚整个下单事务。这样就算用户疯狂点击提交订单，也不会出现库存负数的情况。
4.4 MyBatis常见的两个坑：单个数字字符比较和SQL日志配置
先说单个数字字符比较，这是MyBatis动态SQL里非常经典的一个坑。假设菜品状态status是Integer类型，你在<if>里判断<if test="status == '1'">，看起来没问题，但OGNL表达式中单引号包起来的'1'会被当作Character字符类型，而status是Integer，Integer永远不等于Character，这个条件就永远不会成立，SQL里就拼不上这个条件。
正确写法是<if test="status == 1">，直接把1写成数字字面量。如果你非要写字符串，就要写成<if test='status == "1"'>，把单引号和双引号反过来。这个坑非常隐蔽，代码不报错，但条件就是不生效，排查起来很费时间。
再说SQL日志配置。开发阶段看不到MyBatis执行的SQL，排查问题效率极低。在application.yml里加上：
mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl配置之后控制台会完整打印SQL语句和参数值。调试完联调阶段建议关掉，不然日志刷屏影响看其他信息。
5. 前端实现：Vue层面如何组织和对接接口
前端我用的是Vue2全家桶：Vue Router做路由、Vuex管理购物车状态、Axios统一请求后端接口、Element UI做UI组件库。整体结构分成用户端页面和管理端页面两块。
5.1 前端项目结构和路由设计
项目创建用vue create命令，选默认的babel+router+vuex预设。目录结构按功能划分：src/views放页面级组件，用户端有MenuPage.vue（点餐页）、CartDrawer.vue（购物车抽屉）、OrderList.vue（订单列表）、OrderDetail.vue（订单详情）；管理端有AdminLogin.vue、AdminHome.vue、DishManage.vue（菜品管理）、OrderManage.vue（商家订单处理）、CategoryManage.vue（分类管理）。
路由需要在main.js里配置。用户端和管理端建议分成两个独立的布局：用户端是“顶部导航+左侧分类+中间菜品列表+右侧购物车”的结构，管理端是“左侧菜单+右侧内容区”的典型后台布局。可以给管理端路由统一加一个前缀/admin，路由守卫里校验登录状态。
{ path: '/admin', component: AdminLayout, meta: { requiresAuth: true, role: 'ADMIN' }, children: [ { path: 'dish', component: DishManage }, { path: 'order', component: OrderManage } ] }路由守卫在beforeEach里判断meta中的requiresAuth，没有token就跳去登录页。有token但role不匹配就拦截住，防止普通用户直接敲URL进管理端。
5.2 axios封装和接口对接
前端请求不要直接在每个页面里写this.$axios.get，那样改接口地址要改到崩溃。统一封装一个request.js，做三件事：创建axios实例并设置baseURL，请求拦截器里把token加到请求头，响应拦截器里统一处理错误码和401跳转。
import axios from 'axios' const request = axios.create({ baseURL: process.env.VUE_APP_BASE_API, timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = token } return config }) request.interceptors.response.use( response => response.data, error => { if (error.response.status === 401) { localStorage.removeItem('token') window.location.href = '/login' } return Promise.reject(error) } ) export default requestbaseURL用环境变量控制：开发环境走http://localhost:8080/api，前后端联调时还会遇到跨域问题，后面会细说。
5.3 购物车状态管理和组件通信
购物车是点餐页最核心的交互。用户点击“加入购物车”后，顶部导航的购物车角标要立刻更新，右侧购物车抽屉也要能同步显示最新的数据。这种跨组件的状态同步，用Vuex的Module来管理最合适。
定义cart模块的state是cartList数组，mutations里有addToCart（新增或累计数量）、updateQuantity、removeFromCart、clearCart。点餐页的菜品卡片组件不直接操作Vuex，而是通过this.$store.commit('cart/addToCart', dish)提交mutation，购物车抽屉组件通过mapState读取cartList自动响应更新。
组件通信还有一个细节：菜品卡片点击的对象是整个dish对象，Vuex里计算购物车总价时要用cartList.reduce遍历累加每一项的price * quantity，金额计算一定用整数分来算，展示的时候再转成元，避免浮点误差。我在前端统一用分作为计算单位，接口返回的金额也是以分为单位的整数，彻底绕开浮点问题——这是后端也能做但前端更需要坚持的约定。
5.4 前后端联调时的三个经典问题
第一是跨域。前端跑在8081端口，后端跑在8080，浏览器会拦截跨域请求。解决方案有两种：后端加@CrossOrigin或配置CorsFilter全局跨域，或者前端在vue.config.js里配devServer的proxy代理。我推荐前端代理的方案：
devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }这样前端请求/api/dish/list会被代理到后端的/api/dish/list，浏览器看到的始终是同源的，不需要后端做任何跨域配置，上线部署也更安全。
第二是时间格式。MySQL的datetime字段，Jackson默认序列化成"2024-01-15T10:30:00"这种带T的格式，前端显示很不友好。统一在application.yml里配置：
spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8第三是IP配置的问题。如果你的本机IP不是localhost，后端接口地址写死了localhost，手机访问项目时就会全部失败。联调时建议把前端环境变量里的VUE_APP_BASE_API留空，通过代理转发，这样后端地址只管在vue.config.js里改一处就行。
6. 部署、打包和那些文档里不会写的坑
项目写完不是结束，能打包部署起来才算真正完成。这个环节的坑，比写代码时遇到的还要多。
6.1 环境版本的匹配问题
这个项目最大的环境坑是版本匹配。我踩过最痛的一次是：SpringBoot拉到3.0版本，但电脑装的是JDK8，结果mvn spring-boot:run直接报错，提示Class文件版本错误。SpringBoot 3.x强制要求JDK17，Maven编译器插件也会检查Java版本，版本不匹配根本无法启动。
同理，前端Node版本也会影响。Vue2项目如果Node版本过高（比如Node 18以上），执行npm run build时可能报错Digital Envelope Routines::unsupported，这是OpenSSL版本变化导致的，需要指定NODE_OPTIONS=--openssl-legacy-provider才能打包，或者降Node版本到16。我建议直接装一个Node版本管理工具，方便切换版本。
数据库方面，MySQL 8.0的JDBC驱动要把URL写成jdbc:mysql://localhost:3306/db?serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true，不加allowPublicKeyRetrieval有时会报Public Key Retrieval错误，这个坑遇到过的人应该不少。
6.2 前端打包后布局异常和资源404的问题
npm run build生成dist目录之后，双击index.html打开，页面要么白屏，要么样式全乱、图片全挂。两个原因：一是Vue Router的mode是history，静态文件服务器没有做路径重写，访问/admin/dish返回404。二是打包后的资源路径是绝对路径/js/app.js，直接file协议打开必然失败。
解决方案：Vue Router改用mode: 'hash'，这样URL里会带#，任何路径都不会404；打包配置设置publicPath: './'，让资源加载使用相对路径。如果你有静态服务器环境，也可以不绕hash模式，而是在Nginx里配置try_files $uri $uri/ /index.html，但本地演示用hash模式最省心。
我在实际部署时用的是hash模式加相对路径，dist目录直接扔到Tomcat的webapps下就能跑，不用额外配Nginx，对毕设演示来说足够了。
6.3 后端打包：Maven打JAR包和运行时的注意事项
后端打包用mvn clean package -DskipTests，生成target目录下的JAR文件。直接在命令行运行java -jar xxx.jar就能启动。这里有两个注意点：如果SpringBoot内置了Tomcat，默认端口是8080，需要确认没有端口冲突；JAR包里的配置文件默认读取的是src/main/resources下的application.yml，如果打包后想改数据库密码，不能直接改JAR内部文件，要用外部配置覆盖：
java -jar xxx.jar --spring.config.additional-location=/path/to/application.yml或者用环境变量注入SPRING_DATASOURCE_PASSWORD。这个技巧对部署环境切换非常实用，不用每次改配置都重新打包。
前端dist目录还可以尝试直接复制到SpringBoot的src/main/resources/static目录下，然后重新打包，这样就能用同一个SpringBoot进程同时提供接口服务和前端页面。这是最简单的一体化部署方案，缺点是前后端耦合了，但用于演示和答辩，一个JAR跑起整个项目，展示效果格外加分。
7. 写在最后的经验补充分享
项目做下来，我最大的体会是：这类全栈项目真正的难点不在某个框架的API怎么调，而是把数据库设计、事务边界、接口规范性、前后端配合这些“工程感”的东西搞明白。你写出一个能跑的项目不算本事，能让别人接手你的代码时不用猜逻辑，答辩时每个表、每个接口、每个状态流转都能讲出为什么，这才叫做完了一个项目。
再分享一个我自己很受用的技巧：每张业务表都加上create_time和update_time字段，MySQL里用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP自动维护，Java实体里对应LocalDateTime。别小看这两个字段，排查数据问题、做数据统计、展示到前端，处处都能用到。
如果你做完这个点餐系统还想继续扩展，方向可以考虑：给购物车换成Redis存储并加个过期时间，订单提交改成RabbitMQ异步处理，菜品图片上传改用OSS对象存储，数据统计加上ECharts图表展示。这些升级方向都不复杂，但对技术成长和简历含金量的提升非常明显。整套流程走下来，我从MySQL建表逻辑到Vue组件设计、从MyBatis动态SQL到SpringBoot打包部署，过了一遍完整的全栈开发链路。希望这篇记录也能让你的项目之路少走几个弯路。
