去年帮一位准备毕业设计的朋友把关选题他列了一串备选题目我建议他做“基于SpringBootVue的美食推荐商城”。原因很简单这个题目把后端框架、持久层框架、前端工程化和一个推荐功能全串起来了既没有像纯电商系统那样大到失控也不是没有业务逻辑的玩具项目。做完之后回头看SpringBoot整合MyBatis、Vue3组件化开发、以及一个轻量级推荐模块的落地在这个项目里都能练得特别透而且整套代码和思路可以直接复用到其他管理系统类项目里。这个项目整体就是一套典型的前后端分离架构后端用SpringBoot提供RESTful接口MyBatis负责数据库操作MySQL存数据前端用Vue实现页面和交互。业务上包含两条线用户端是逛美食、加购物车、下单支付、写评价管理员端是菜品管理、分类管理、订单处理和用户管理。所谓的“美食推荐商城”就是在这个基础上加了一个推荐模块根据用户的收藏和评分行为从菜库里捞他大概率感兴趣的菜。这套项目最合适的受众有两类一类是正在做毕业设计或课程设计的学生需要一套结构完整、注释清楚、能跑通的参考实现另一类是刚学完SpringBoot和Vue基础、想通过一个完整项目把前后端技术串起来的人。如果你是这两类人之一这篇文章值得仔细看完我会把设计思路、数据库结构、关键代码细节和部署步骤都拆开讲包括那些常规文档里不会写的坑。1. 项目整体设计与核心思路拆解1.1 这套技术栈为什么这么组合先说技术选型。SpringBoot MyBatis MySQL Vue这套组合放在今天依然是Java web领域最主流、简历上露面最多的搭配之一。SpringBoot解决了传统SSH时代配置地狱的问题内嵌Tomcat、自动装配、起步依赖三板斧下来一个可运行的服务几分钟就能拉起来。MyBatis则胜在SQL可控性电商项目里经常有复杂查询比如多条件组合筛选菜品、统计销量排行这种场景下MyBatis的XML映射比JPA的自动SQL要直观得多排查问题时直接把SQL拿出来就能分析。前端这块虽然项目和部分教程还在用Vue2但新项目建议直接上Vue3 Vite Element Plus组合式API配合setup语法糖代码组织确实比Options API要清爽。Vite的冷启动速度那叫一个快改完代码秒级热更新开发体验比webpack时代强太多。这套组合有个容易被忽视的优势前后端可以完全分离开发。我写好接口文档实际上用一个Swagger配置就够前端同学按文档并行开发页面两边最后联调。对于一个人独立完成项目的学生来说先跑通后端接口再写前端页面遇到的问题能精准定位到后端还是前端不用在乱七八糟的耦合代码里猜。1.2 功能模块拆解与商城业务闭环很多刚接触这类项目的同学拿到“美食推荐商城”的第一反应是“这不就是个点餐系统嘛”。实际拆开看它比单纯点餐要复杂一层因为多了一个“推荐”的维度而且管理员端和用户端是完全不同的两套界面体系。用户端模块大致分为五块账号模块注册、登录、个人资料查看登录后签发token后续接口凭token访问。浏览模块首页展示推荐美食列表、按分类查看菜品、搜索、点进菜品详情页看评分与评价。交易模块购物车、确认订单、提交订单、查看订单状态。互动模块收藏菜品、对已完成的订单菜品打分评论。推荐模块基于用户历史行为生成个性化菜品列表这是项目的亮点功能。管理员端模块分四块仪表盘统计总订单量、用户数、热门菜品、菜品管理增删改查、上下架、库存调整、分类管理、订单管理查看订单详情、修改状态。这两条线通过数据库层面的外键关系和用户角色字段串联起来。用户表里一个role字段区分“ROLE_USER”和“ROLE_ADMIN”后端的拦截器只对需要管理员权限的接口做校验逻辑清晰。1.3 推荐功能怎么定位不做花哨算法做业务闭环一提“推荐”有同学动辄就想上深度学习模型或者上协同过滤矩阵分解。实际在一门课程设计或毕业设计里这既没必要也不现实。我更建议做一个轻量级的推荐模块把业务闭环做完整就好。这个项目里我的做法是两路推荐逻辑结合一路是基于内容热度统计各分类下收藏量和销量最高的菜品作为“热门推荐”一路是基于用户相似行为的简单协同过滤找到和你收藏过同一道菜的其他用户看看他们还收藏了什么。这个思路用SQL加简单的Java逻辑就能实现但已经是一个有完整推荐链路的功能了。这种定位还有一个好处答辩或汇报的时候你能把推荐逻辑用几分钟讲清楚而不是一句“模型太复杂没法解释”带过。面试官或老师更看重的是你有独立设计业务模块的能力这比堆一个调包出来的黑盒模型得分要高得多。2. 数据库设计与MyBatis持久层实现2.1 六张核心表的字段与关系设计数据库设计是整个项目的地基表结构设计好后面写代码会非常顺。美食推荐商城我最终设计了六张核心表用户表、分类表、菜品表、订单表、订单明细表、评论/收藏相关表实际上可以细分但为了控制复杂度我把收藏和评论拆成两张独立表总共七张。用户表tb_userid、username、passwordBCrypt加密存储、nickname、avatar、phone、role、status、create_time。userId是其他业务表的外键来源。分类表tb_categoryid、name、sort、status。这里不要小看sort字段美食分类需要控制展示顺序比如“热菜”排前面“凉菜”排后面。菜品表tb_dishid、category_id、name、description、price、stock、image、sales、status。status用于上下架sales字段用于热门排序。注意菜品价格我用decimal(10,2)不要用float精度问题在大项目里很要命。订单表tb_orderid、order_no、user_id、total_amount、status、create_time。status枚举值待付款、待发货、已完成、已取消。order_no用时间戳加随机数生成不要用数据库自增ID裸奔这是规范层面的习惯。订单明细表tb_order_itemid、order_id、dish_id、dish_name、price、count、amount。这里冗余了dish_name和price为什么因为菜品改名或价格调整后历史订单里的信息不能被改掉。收藏表tb_favoriteid、user_id、dish_id、create_time唯一索引user_id, dish_id防止重复收藏。评论表tb_reviewid、user_id、dish_id、order_id、rating、content、create_time。rating用于算菜品平均分。这几张表的关系一句话概括用户下单产生订单订单包含多个明细用户收藏菜品形成行为数据用户评论菜品形成评分数据评分和销量共同输入到推荐模块。2.2 MyBatis XML的动态SQL与多表联查很多新手喜欢把MyBatis的SQL直接写在注解里比如Select。简单接口没问题但凡查询条件多一点注解那一坨字符串拼接能把人看吐调试维护都麻烦。这个项目我全部走XML文件映射理由只有一个SQL清晰可控。菜品分页查询是一个典型的多条件动态SQL场景。前端传过来可能有关键字、分类ID、价格区间、上下架状态任何一个条件都可能为空。XML里用 和 标签可以优雅解决select idselectDishPage resultTypecom.example.entity.Dish SELECT d.*, c.name AS category_name FROM tb_dish d LEFT JOIN tb_category c ON d.category_id c.id where if testkeyword ! null and keyword ! AND d.name LIKE CONCAT(%, #{keyword}, %) /if if testcategoryId ! null AND d.category_id #{categoryId} /if if testminPrice ! null AND d.price gt; #{minPrice} /if if testmaxPrice ! null AND d.price lt; #{maxPrice} /if if teststatus ! null AND d.status #{status} /if /where ORDER BY d.create_time DESC /select这里有三个细节容易踩坑。第一小于号“”在XML里必须转义成否则解析报错第二LIKE查询用CONCAT拼接而非直接写%#{keyword}%这样才能走索引第三LEFT JOIN关联查询出的category_name字段需要在实体类里额外加一个非表字段的属性并标记为不参与基础映射否则结果集映射会报错。多表联查在推荐模块里用得更多。比如要查用户收藏的所有菜品及其分类名称一条JOIN就能搞定查热门菜品的销量排行用SUM(order_item.count)配合GROUP BY和ORDER BY。2.3 事务配置和批量插入的坑下单流程涉及用户表、订单表、订单明细表和菜品表四张表的写操作这必须放在同一个事务里任何一个环节失败都要整体回滚。SpringBoot里我直接在Service方法上标注Transactional(rollbackFor Exception.class)这里的rollbackFor一定不要省因为默认情况下RuntimeException才回滚而捕获CheckedException后事务会失效。事务还有一个隐藏知识点由于Spring事务是基于代理的如果在同一个类里A方法调用B方法B上的Transactional不会生效称之为事务自调用失效。我的解决方法是把下单这种强一致操作单独放到一个OrderService里避免这种问题。批量插入订单明细时网上很多教程在for循环里一条一条insert性能很差。我会用MyBatis的 标签一次性批量插入insert idbatchInsertOrderItems INSERT INTO tb_order_item (order_id, dish_id, dish_name, price, count, amount) VALUES foreach collectionlist itemitem separator, (#{item.orderId}, #{item.dishId}, #{item.dishName}, #{item.price}, #{item.count}, #{item.amount}) /foreach /insert注意MySQL的max_allowed_packet参数默认比较小如果一次插入的行数特别多可能报“Packet for query is too large”错误。日常量级没问题但你要知道有这么回事大数据量时几百条一批分次插入更稳妥。3. SpringBoot后端接口与业务流程实现3.1 项目分层与统一返回结构后端代码我按Controller、Service、Mapper、Entity四层结构组织这是SpringBoot项目的标准姿势。Entity对应数据库表每张表一个实体类字段和表列一一对应Mapper是接口方法名和XML里的id对应Service写业务逻辑Controller只做参数接收和结果返回里面不要写任何业务代码。Controller层有几个习惯值得一提统一的RESTful路径设计比如GET /api/dish/{id}取详情、POST /api/order创建订单语义清晰参数校验用javax.validation注解比如NotNull、NotBlank既干净又省去手写一堆if判断这种垃圾代码。统一返回结构我会定义一个Result类public class Result { private Integer code; private String message; private Object data; // 省略构造器和getter/setter }所有接口返回Result对象code为200表示成功401未登录500系统异常。为什么这么设计前端拦截器只看code不用关心data的具体类型。一旦接口返回错误前端弹toast提示message即可解耦非常清晰。同时配合一个全局异常处理器RestControllerAdvice把业务异常和系统异常统一转成Result返回不用在每个Controller里写try-catch。3.2 下单与库存扣减的并发控制下单是整个系统里最需要严谨处理的业务。如果两个用户同时买同一道菜而菜的库存只有一份不加控制的话就会出现超卖问题。很多课设代码里都是“先查库存再更新库存”的两步操作这在高并发下一定会出问题查库存时都看到还有1份两个请求都通过判断然后一起扣减库存变成-1。处理这个问题有悲观锁和乐观锁两种路线。悲观锁用SELECT ... FOR UPDATE简单粗暴但锁表时间较长我更推荐使用乐观锁的思路用一条UPDATE语句完成库存扣减判断UPDATE tb_dish SET stock stock - #{count} WHERE id #{id} AND stock #{count}这条SQL的意思很直白只有库存充足时才更新MySQL会通过行锁保证同一时刻只有一个事务能成功更新这条记录。Java代码里判断影响行数如果影响行数为0说明库存不足直接抛出业务异常“库存不足”事务回滚。这种方式既没有显式加锁又不会超卖是实际项目中很常见的做法。下单完整流程是先检查用户登录状态再校验菜品是否存在然后计算订单总金额这里我强调必须用数据库里的实时价格计算不能信任前端传过来的价格否则用户改一下请求就能低价购买扣减库存生成订单号和订单实体插入订单明细。整套流程在Transactional下执行任何一步异常都会回滚。3.3 推荐接口的数据组装逻辑推荐模块在Service层实现核心是两个方法。第一个是getHotDishes统计销量和收藏量的加权得分SQL大概长这样SELECT d.id, d.name, d.price, d.image, IFNULL(SUM(oi.count), 0) AS sales_count, COUNT(f.id) AS fav_count FROM tb_dish d LEFT JOIN tb_order_item oi ON d.id oi.dish_id LEFT JOIN tb_favorite f ON d.id f.dish_id GROUP BY d.id ORDER BY (sales_count * 0.6 fav_count * 0.4) DESC LIMIT 10这里不需要太纠结权重怎么算出来的实际上0.6和0.4就是一个可调的系数体现了销量比收藏更重要这个业务判断。你完全可以按自己的理解调整。第二个是getRecommendForUser思路是先找出当前用户收藏过的所有菜品分类再找“收藏了这些分类下菜品”的其他用户最后把这些人收藏的、但当前用户没收藏过的菜品推荐出来。用SQL和Java组合实现其实关键词就是几个关联查询加一个去重。这个逻辑不算复杂但它完整跑通了一个“用户行为 → 相似用户 → 推荐结果”的链路在报告中能写清楚就是加分项。推荐接口写完之后一定要做一件事查出来的结果极大概率包含已下架的菜品所以最后要用permission和status字段过滤一遍。这是从运营角度需要考虑的细节也是我和很多初学者做法不一样的地方。3.4 登录鉴权与安全细节对于这类系统我不会上一整套Spring Security或Shiro来做权限框架因为配置成本高对项目体量来说属于杀鸡用牛刀。更实用的方案是用JWT实现无状态认证用户登录成功后后端生成一个包含用户ID和角色的token返回前端把token存在localStorage里每次请求通过Authorization请求头带回后端写一个拦截器HandlerInterceptor解析token并放行。拦截器里需要区分哪些接口游客也能访问比如首页菜品列表和菜品详情哪些接口必须登录购物车、下单、收藏哪些接口必须管理员权限菜品管理、订单管理。我的做法是定义一个白名单列表然后对未放行的接口解析tokenif (token null || !jwtUtil.validate(token)) { response.setStatus(401); return false; }密码存储用BCrypt加密。明文密码存数据库是安全隐患也是评审时一定会被问的问题。SpringBoot集成spring-security-crypto依赖可以单独使用BCryptPasswordEncoder不引入完整的安全框架这就够用。4. Vue3前端开发与前后端联调4.1 项目初始化与路由设计前端用npm create vuelatest这个命令初始化项目它会引导你选择TypeScript、Vue Router、Pinia等选项。我的建议是如果课程设计要求里没有明确必须用TypeScript直接选JavaScript因为上手和调试的成本更低。路由抓好两个页面层级就够了。登录注册页和主页是顶层路由主页面下用children嵌套路由来做内容切换比如首页推荐、美食分类、购物车、我的订单、个人中心。嵌套路由的好处是主页框架只渲染一次切换子页面时公共的顶栏和侧边栏不会重新加载。路由守卫是权限控制的关键一步。在路由配置文件里给需要登录的页面加上meta字段标记然后在beforeEach全局前置守卫里判断tokenrouter.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } })4.2 核心页面与组件拆分前端的重点在设计组件化思维。美食商城页面里最简单的做法是建几个关键的Vue组件分而治之。美食卡片是一个高频复用组件包含菜品图片、名称、价格和收藏按钮在有菜品列表的页面里循环渲染它数据从父组件通过props传入子组件通过emit事件通知父组件收藏操作。首页推荐页面逻辑比较简单调用后端的推荐接口拉数据渲染成美食卡片列表。菜品详情页展示大图、描述、价格、评分分布和评论列表用户可以在这里加入购物车、下单或收藏。购物车页面我用了Pinia来管理购物车状态。相比在组件里用ref硬存一份数据用Pinia的好处是多个页面菜品详情页、购物车页、顶栏购物车图标之间共享状态时不需要逐层传递事件。购物车里的增删改操作全部走store里的action组件只负责调用和渲染。管理员端的菜品管理页面用了Element Plus的el-table组件配一个新增编辑用的el-dialog弹窗。表格列里渲染操作按钮点击编辑时把当前行数据传给弹窗表单保存后调用接口刷新列表。这套交互是后台管理页面最常见的模式学会一次就能到处复用。4.3 Axios封装与跨域处理前端请求统一用axios但直接在每个组件里写axios.get会非常散乱。我习惯先在src/utils/request.js里做一层封装核心功能有三点baseURL统一设置为/api请求拦截器自动从localStorage取token加到Authorization头响应拦截器统一处理后端返回的Result对象code为200时返回data给业务代码code为401时清掉token并跳转登录页service.interceptors.response.use( response { const res response.data if (res.code 200) return res.data if (res.code 401) { localStorage.removeItem(token) router.push(/login) } ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } )跨域问题是每个前后端分离项目的必答题。开发环境最简单的方式是配置Vite的代理在vite.config.js里server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/dish/list会由Vite开发服务器转发到8080端口不需要后端开启CORS。注意这里和后端接口实际路径的映射关系前端统一带/api前缀后端接口路径不带/api也行代理转发时会保留/api前缀所以后端配置里context-path通常就这样设。生产环境部署时用Nginx把前端打包出来的dist目录配成静态站点同样用location /api { proxy_pass http://127.0.0.1:8080; }做反向代理思路和开发阶段完全一致。5. 本地启动部署与实战问题排查5.1 从零到跑通环境准备与启动步骤按我从零搭起这个项目的经验把整个启动流程完整列一次每一步都别跳。第一步是环境准备。JDK要用8或11建议8兼容性最好MySQL用5.7以上8.0需要注意认证插件问题Maven用3.6以上前端Node.js要14.18以上建议用16或18的LTS版本。第二步是初始化数据库。执行项目里提供的schema.sql和data.sql脚本先建库建表再插入基础的分类和菜品数据。这一步常见的坑是字符集建库时指定utf8mb4来支持emoji和特殊字符。第三步是改后端配置。打开application.yml核对数据库账号密码spring: datasource: url: jdbc:mysql://localhost:3306/food_shop?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456第四步是启动后端。直接在IDE里运行Application主类看到“Started Application”日志说明启动成功。要验证接口是否正常浏览器访问http://localhost:8080/api/dish/list能返回JSON数据就通了。第五步是启动前端。在项目前端目录下依次执行npm install和npm run devVite会打印一个本地访问地址。开发模式下看到页面能正常加载出菜品列表说明前后端联调没问题。第六步是管理员账号验证。用初始化的admin账号登录进到管理员页面试一下修改菜品价格再刷新用户端页面看数据是否同步更新。这个验证看起来简单实际上把全链路都跑通了。5.2 六个高频报错的排查记录我把自己在实际部署过程中遇到的、也是很多同学反复问的问题整理成一个速查表报错现象根本原因解决办法Cannot load driver class: com.mysql.cj.jdbc.Driverpom里没引入mysql-connector-java或版本不兼容在pom.xml添加MySQL驱动依赖8.x版本对应com.mysql.cj.jdbc.DriverAccess denied for user rootlocalhost数据库密码错误或MySQL8用了caching_sha2_password认证检查密码或在MySQL里ALTER USER改用mysql_native_passwordCommunications link failureMySQL服务没启动或URL端口写错确认mysql服务已运行netstat检查3306端口前端接口404或504代理没生效或后端接口路径不匹配确认Vite代理target为后端地址核对接口访问路径Invalid bound statement (not found)Mapper接口和XML文件没对应上或namespace写错检查XML里的namespace和接口全限定名是否一致ID和方法名是否一致前端页面白屏控制台报错组件导入路径错或编译依赖冲突先看编译报错具体行再检查import路径和依赖版本数据库连接串里一定要加useSSLfalse和serverTimezoneAsia/Shanghai这个不加的话MySQL8连接时会出现SSL警告时间字段还会差8小时差。前者是性能隐患后者是业务数据错乱都不该忽略。还有几个和MyBatis相关的坑初学者特别容易碰。第一个是实体类里写了数据库不存在的字段结果查询报映射异常我用TableField或查询SQL里别名控制映射第二个是resultType和resultMap混用如果字段名和列名不一致宁可显式写resultMap别偷懒第三个是XML文件放在src/main/resources下但没被编译进target目录检查pom里resource配置有没有把resources目录包含进去。5.3 后续扩展方向与个人经验项目跑通、功能完善之后这套代码有很多值得继续扩展的方向。第一个方向是推荐系统的深化我现在的协同过滤还是一个简单版本你可以把Jaccard相似度算出来做成真正的基于用户的协同过滤推荐结果会更个性化。第二个方向是引入缓存把首页热点数据和高频访问的分类列表放到Redis减少数据库压力这一步能让项目在性能层面又上一个档次。第三个方向是分布式会话和文件存储把图片用MinIO或云OSS存储替换本地文件存储更接近企业级应用。如果是为了面试或答辩准备我强烈建议你把项目里为什么用某个技术、为什么不用另一个技术这类问题想透。比如被问到“为什么推荐模块不用Redis存结果”时可以回答“当前数据量小直接查库足够支撑但代码里已经预留了缓存接口后续可以方便替换”。这比背概念、背理论要有说服力得多因为面试官能感觉到你是真的把这个系统跑过、想过的。5.4 最后再分享两个小技巧第一开发阶段建议后端启动时把MyBatis的SQL日志打印打开。在application.yml里加一行mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样控制台会直接输出每个Mapper执行的SQL和参数排查问题效率会大幅提升一个量级。我记得第一次做项目时查一个数据查不出来的问题靠这个日志几分钟就定位到是参数传递的类型不对省了接近半个小时的排查时间。第二前后端联调阶段给接口设置一个合理的响应超时时间不然某个接口卡住了前端会一直转圈。在axios封装里timeout设置10秒就够。同时前端全局统一拦截后端返回的500异常弹出明确的错误提示而不是把控制台的英文报错直接曝露给用户。这个细节会让整个系统的完成度和可用性高一个层次。这套项目做完之后我对SpringBoot MyBatis的理解明显比只看文档时要深刻得多尤其是事务边界怎么切分、SQL怎么组织才能兼顾可读性和性能、前后端数据格式怎么约定这些经验说实话不亲手踩一遍坑很难有真实的体感。如果你正在做同类项目建议别照抄代码把我上面讲的这些设计思路和问题案例代入你自己的需求从头梳理一遍收获会大得多。