1. 为什么SpringBootVueMySQL是美食推荐商城最稳妥的选择先说结论这套技术组合不是最惊艳的但绝对是最不容易翻车的。我接手过不少课程设计和毕业设计项目也帮朋友救过火发现凡是卡在做不出来跑不起来的项目九成问题都出在技术栈太花哨——有人用Python的FastAPI配了个不知名的轻量前端框架有人后端直接用Node.js写结果部署环境都配不明白。而SpringBootVueMySQL这套组合恰恰是当下Java生态里最主流的路线也是就业市场上最需要的能力。从招聘角度说Java后端开发岗位十个里有八个要求熟悉SpringBoot前端岗位Vue几乎是必考题MySQL更是所有数据库技能的基石。咱们做这个美食推荐商城不单是为了交差更是一次简历技能点的集中修炼。你把这个项目吃透了写进简历里面试官问SpringBoot的自动配置、AOP、事务管理问Vue的生命周期、组件通信、路由守卫问MySQL的索引优化、事务隔离级别你都能拿真实业务场景来回答而不是背八股文。再聊聊为什么选前后端分离。早期那种Thymeleaf模板渲染的服务端渲染模式已经不太符合当前主流前后端分离的核心收益是前端专注页面交互后端专注业务逻辑两边通过JSON格式的数据接口通信互不干扰。这在多人协作时尤其重要——我负责接口你负责页面把接口文档一约定两边可以并行开发。而且Vue开发出来的单页应用后续如果想再做一个微信小程序端的商城直接复用后端接口就行前端只需要新写一套适配小程序UI的代码工作量直接减半。美食推荐商城这个题目本身也选得很有讲究。它不像那种纯论文式的学生管理系统也不像电商平台那么庞大复杂规模正好卡在一个既能展示完整业务闭环又不会写到手酸的区间。涵盖用户注册登录、美食分类浏览、推荐列表、美食详情、购物车、下单结算、评论评分、后台管理业务链路完整该有的技术点全都覆盖到了。还有一点这套源码标了可直接运行这个事在提供给别人参考使用的时候尤其重要。我见过太多同学拿到一个开源项目折腾三天环境都起不来问题一个接一个数据库里没数据、端口被占用、Node版本不兼容、依赖下载到一半失败……最后信心全磨没了。源码可运行意味着其他人拿到手之后能快速看到效果、能动手改代码验证猜想学习效率完全不一样。这也是我整理这套东西时重点打磨的地方。2. 美食推荐商城的核心业务模块与数据库设计2.1 业务模块拆解一个商城需要哪些角色和功能动手写代码之前先把业务想清楚这一步决定了整个系统能不能撑起来。美食推荐商城从使用对象上分核心有三类普通用户、商家或管理员、系统本身。用户端的功能是逛和买管理员端的功能是管和控系统本身要承担的是数据采集和推荐分发。我把整体拆成了这几个业务板块用户模块注册、登录、个人中心、收货地址管理。登录这里我用的JWT做无状态认证后面接口里通过拦截器统一校验用户身份这个设计比传统的Session方案更契合前后端分离的场景。美食内容模块美食分类川菜、粤菜、甜品、饮品这些、美食列表、美食详情、图片展示。这是商城的门面数据质量直接决定用户愿不愿意往下逛。推荐模块商城的灵魂。通过用户的浏览记录、收藏记录、评分行为以及美食本身的分类热门程度、综合评分、浏览热度来计算推荐列表。推荐策略我做了两种新人用户走全局热门榜单老用户走基于分类偏好的个性化推荐。交易模块购物车、订单生成、订单状态流转待付款、已付款、已发货、已完成/已取消。这个模块最容易写出Bug尤其是下单时库存扣减和订单生成这两个操作必须放到同一个事务里不然会出现订单建了但库存没扣或者反过来库存扣了订单却没了的脏数据。互动模块评论评分、收藏。评论会反哺推荐系统里的综合评分收藏行为则是推荐算法的权重信号之一。后台管理模块管理员登录、美食分类管理、美食上下架、订单处理、用户管理。后台和前台共用一套后端服务只是通过角色权限来控制可访问接口。我建议在做的时候把前端路由也按这个维度拆开前台用户端是一套布局后台管理端是另一套布局每个布局下面挂各自的页面和组件。Vue Router里通过路由守卫判断登录状态和角色没登录的跳到登录页非管理员访问管理端直接拦截。2.2 数据库表结构从用户到订单的全链路建模数据库是整个系统的地基建表建得不好后面所有功能都会别扭。我这个系统一共设计了8张核心表按业务域划分的话表名核心字段作用说明userid, username, password, nickname, avatar, role, phone, create_time用户账号信息role区分普通用户和管理员foodid, name, category_id, intro, price, image, stock, sales, rating, status美食信息status控制上架/下架categoryid, name, sort美食分类cartid, user_id, food_id, quantity, checked购物车条目ordersid, order_no, user_id, total_price, status, address, create_time订单主表order_itemid, order_id, food_id, food_name, food_image, price, quantity订单详情快照commentid, food_id, user_id, content, rating, create_time评论和评分favoriteid, user_id, food_id, create_time收藏记录有几点我自己踩过坑值得单独说说订单表里的order_item为什么要冗余保存一份food_name和food_image因为美食信息是可以编辑的商家可能改了菜名、换了图片如果订单详情去关联查询food表那历史订单显示的信息就会被篡改用户看到我买的明明是鱼香肉丝怎么变成宫保鸡丁了这体验太糟了。快照模式虽然多占了点存储空间但能保证历史业务的完整性。orders表的order_no我建议用时间戳加随机序列来生成格式类似20250101120000123456既保证唯一性又方便按时间检索别直接用自增ID做订单号那玩意在外面瞎传容易被恶意遍历而且看不出时间信息。外键我一张表都没用。物理外键会在高并发写入时拖垮性能删除数据时也容易撞上约束报错。我的做法是逻辑上的关联关系通过业务代码来保证例如删除分类之前先检查该分类下是否还有美食而不是靠数据库来硬限制。这也符合目前互联网大厂的通用实践。2.3 推荐模块的数据支撑浏览量、评分与偏好的计算逻辑推荐功能听起来高大上但在这个项目里不用上机器学习那一套核心是数据驱动加简单统计。我建了一张food表里的sales、rating字段又通过favorite和comment表统计收藏数和评价数然后算出一个热度分。热度分我用了这样一个公式热度分 浏览量*0.2 销量*0.3 评分*10 收藏数*2解释一下这样设计的理由。浏览量和销量代表商品的普遍接受度评分代表质量认可度收藏数代表用户愿意留下来再看一眼的意愿。系数是我根据数据反复试出来比较合理的比例——如果浏览量权重太高会出现劣质但刷量的商品霸榜如果评分权重提太高评论基数少又会造成冷门高分商品排得太靠前。个性化推荐则是先统计当前用户历史浏览记录里出现最多的分类给该分类下的美食额外加一个热度加成系数然后重新排序。这种做法虽然朴素但实测效果在小型商城场景下已经足够自然用户看到的推荐列表不再是满屏同一个热门菜而是贴合他自己偏好的组合。数据库层面我在food表的category_id上建了索引在favorite表的user_id food_id上建了联合索引就是为了让这些统计查询跑得快一点。3. SpringBoot后端实现分层架构、接口设计与推荐逻辑落地3.1 项目目录结构与分层思想SpringBoot后端我采用的还是经典的三层架构但做了适度的演进。标准分层是 Controller、Service、Mapper 三层我在此基础上加了 DTO 做数据封装、VO 做返回体封装并单独建了一个config包放跨域配置和拦截器配置。com.example.foodmall ├── controller // 接收请求参数校验返回统一结果 ├── service // 业务逻辑层事务控制基本都在这层 ├── mapper // MyBatis的Mapper接口 ├── entity // 实体类对应数据库表 ├── dto // 前端传参的封装对象 ├── vo // 返回给前端的数据视图对象 ├── config // 跨域配置、拦截器注册、Web配置 ├── common // 统一返回结果、状态码、异常处理 ├── utils // JWT工具类这样的分层最大的好处是各层职责清晰出了问题能快速定位。比如前端告诉你说下单接口报错返回了500你看一下是Controller里参数校验挂了还是Service里事务处理炸了还是Mapper里SQL写错了不用在几百行代码里大海捞针。3.2 统一返回体与全局异常处理所有接口的数据格式约定前后端分离开发接口返回格式一定要统一这是多人协作的底线约定。我用的统一返回结构是public class ResultT { private Integer code; // 200成功400参数错误401未登录500服务器异常 private String message; // 提示信息 private T data; // 具体数据 }所有接口只要成功返回Result.success(data)只要失败抛出业务异常由全局异常处理器统一拦截转换。GlobalExceptionHandler配合RestControllerAdvice注解把异常分为业务异常、参数校验异常、兜底程序异常三类。业务异常是我们在Service里主动抛出new BusinessException(库存不足)这类参数校验异常靠Validated注解配合实体类的NotNull、NotBlank标签捕获兜底异常则记录日志给前端返回一个不暴露内部细节的通用报错。这个设计实际上花不了多少代码量但价值极大。没有统一异常处理的时候你每写一个接口都要自己 try-catch代码里到处是判断返回值的逻辑而且稍不留神就把堆栈信息直接返回给前端了。3.3 登录认证与JWT拦截器用户认证这块我用的方案是用户登录成功后后端生成一个JWT令牌返回给前端前端存储在localStorage里之后每次请求在请求头带一个Authorization: Bearer token。后端定义一个拦截器在WebMvcConfigurer里注册指定哪些路径需要拦截。需要放行的路径包括登录接口、注册接口、美食列表和详情接口、图片访问的静态路径。需要拦截的路径包括购物车相关接口、订单相关接口、收藏接口以及所有后台管理接口。JWT工具类的核心逻辑就是用io.jsonwebtoken这个依赖设置签发时间、过期时间和自定义负载这里我放的是userId和role然后用固定的签名密钥做加密。这里有一个实操细节签名密钥不要写到明文代码里从配置文件读取方便不同环境的切换。拦截器里解析完token之后把userId放到ThreadLocal里面后续Service里需要知道当前操作人是谁直接从工具类取就行。这个做法比把userId一层层从Controller传到Service清爽很多。3.4 推荐接口的代码实现从SQL查询到排序算法推荐接口我大概写了一个FoodService里的方法伪代码如下public ListFoodVO getRecommendList(Long userId, int limit) { // 1. 如果用户未登录直接返回全局热门榜 if(userId null) return recommendByHotScore(limit); // 2. 统计用户浏览和收藏最多的分类 Long favoriteCategoryId favoriteMapper.findTopCategoryByUser(userId); // 3. 查询该分类下美食并对热度分加成按加成后热度降序取前limit条 ListFood foods foodMapper.selectByCategoryOrderByScore(favoriteCategoryId); // 对 foods 做热度分计算与排序 }写这个逻辑时注意一个坑不要图省事把所有美食一次性查出来放内存里排序数据量大了之后性能会很难看。正确做法是用SQL先做初步过滤比如只查上架状态的、只查评分大于一定阈值的然后再拿较小的结果集做排序和截取。Mapper里的SQL我用的是MyBatis的注解版简单高效Select(SELECT * FROM food WHERE status 1 ORDER BY (views*0.2 sales*0.3 rating*10 favorite_count*2) DESC LIMIT #{limit}) ListFood selectHotFoods(Param(limit) int limit);favorite_count这个字段我并不是直接存在food表里的而是通过定时任务每天凌晨统计一次回写到food表。这么做是为了避免用户每次刷新首页时实时去favorite表里count在高并发场景下拉垮查询性能。定时任务用Scheduled注解就搞定了SpringBoot自带能力不需要引入额外的任务调度框架。4. Vue前端实现页面构建、状态管理与前后端联调4.1 前端项目结构与路由设计前端用的Vue 2 Element UI这套成熟组合并没有用Vue 3。原因很实际Element UI对Vue 2的支持最完善网上案例最多遇到问题搜起来最容易找到答案。Vue 3现在虽然已经是主流但配套组件库还在迭代对刚入手项目的人来说坑更多。项目结构大致如下src ├── api // 所有接口请求的封装 ├── assets // 静态资源 ├── components // 公共组件导航栏、菜品卡片等 ├── router // 路由配置 ├── store // Vuex状态管理 ├── views // 页面级组件 │ ├── home // 首页推荐列表 │ ├── category // 分类页 │ ├── detail // 美食详情 │ ├── cart // 购物车 │ ├── order // 订单页 │ ├── login // 登录注册 │ ├── admin // 后台管理路由这块我用的是vue-router的动态路由模式。先说为什么动态后台管理的菜单列表是根据登录用户角色动态生成的普通用户没有管理端路由就算手输路径也进不去配合后端的权限校验双重保护。路由守卫我个人觉得是前端必学的核心点。我在router.beforeEach里做了三件事第一判断目标页面是否需要登录需要的话检查Vuex里有没有用户信息第二如果没有但本地有token尝试调用获取用户信息接口回填第三根据用户角色判断是否有权进入管理页面。4.2 Axios请求封装拦截器、统一错误处理与跨域前端请求我都通过axios实例统一发送基础配置里设置了baseURL然后在请求拦截器里把token放进headers响应拦截器里统一处理后端返回的code。service.interceptors.response.use( response { const res response.data; if(res.code 200) { return res.data; } else if(res.code 401) { // token失效跳转登录页 router.push(/login); return Promise.reject(res.message); } else { Message({ type: error, message: res.message }); return Promise.reject(res.message); } }, error { Message({ type: error, message: 网络请求失败请检查后端服务是否启动 }); return Promise.reject(error); } );这里有一个新手最容易踩的坑响应拦截器里如果把整个res返回那业务代码里拿到的就是{code, message, data}这个壳子每次都要写res.data才能拿到真正的数据。我上面直接把res.data也就是后端Result里的 data 字段返回出去业务组件拿到的直接就是业务数据对象代码干净很多。跨域问题我用的是后端CORS全局配置解决的在SpringBoot的WebMvcConfigurer里重写addCorsMappings方法允许指定来源访问。如果后端配置了跨域前端开发环境就不需要再搞proxy了。但要注意生产环境部署时前端静态资源和后端接口往往不在同一台服务器跨域配置依然需要保留这个别忘。4.3 首页推荐列表与商品详情的组件化实践首页是最能体现前端基本功的页面。顶部是搜索栏下面是轮播图然后就是推荐美食列表的瀑布流。美食卡片组件FoodCard.vue接收一个food对象展示图片、名称、评分、月销量、价格点击跳转到详情页。列表页和推荐列表复用同一个组件只是接口不同这就是组件化的意义。商品详情页有几个细节要注意图片要懒加载用v-lazy指令评分展示用了Element UI的el-rate组件但设置为只读模式评论区域分页加载默认一次加载5条滚动到底部懒加载更多。购物车页我用了Vuex做状态管理。购物车条目增删改不能只改页面展示还要同步后端数据库所以我在Vuex的actions里写的方法逻辑是调接口成功后commit修改state最后页面上所有读取购物车数量的组件都会自动响应。这比用eventBus做组件间通信要可靠得多至少不会出现购物车角标数字没刷新这种尴尬情况。4.4 管理后台的表格与表单联动后台管理页面我用了Element UI的el-table搭配el-dialog美食列表页是典型的CRUD模式表格展示美食信息操作列里有上架/下架、编辑、删除按钮。点击编辑后弹出一个el-dialog里面是美食表单提交时先做前端校验校验通过再调接口。有个经验值得分享后台分类管理时删除分类前一定要二次确认弹窗然后前端先调删除接口成功后刷新列表。但后端也要处理分类下面有美食这种情况我在删除接口里判断了分类下是否存在美食存在就返回提示该分类下存在美食请先转移或删除对应美食。这种前端体验佳 后端兜底校验的双保险模式能避免九成的误删事故。图片上传这块我用的方案是后端提供一个上传接口接收MultipartFile存储到本地目录并把文件路径返回给前端前端把路径存到美食表单的image字段。这里有一个容易踩的坑本地存储要映射一个虚拟路径否则图片从服务器上读不出来。SpringBoot里写个WebMvcConfigurer把本地磁盘路径映射到服务路径/images/**才能正常访问。5. 让源码在你电脑上跑起来环境配置与启动全流程5.1 环境准备清单版本匹配是关键源码要可直接运行环境首要是版本匹配。SpringBoot项目对JDK和Maven的版本并不算敏感但过老的版本也会出问题。我的建议是软件推荐版本说明JDK1.8或11SpringBoot 2.x系列对JDK8支持极佳不用升到17Maven3.63.8版本以上即可MySQL5.7或8.0建议8.0注意驱动配置变化Node.js14或16对应npm 8前端构建稳定前端依赖vue 2.6, element-ui 2.15都是稳定版MySQL 8和MySQL 5.7最大的区别是驱动类名从com.mysql.jdbc.Driver变了com.mysql.cj.jdbc.Driver而且连接URL需要加时区参数serverTimezoneAsia/Shanghai。用8.0的同学如果沿用旧版配置会直接报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized这类问题搜一下就能解决。5.2 数据库导入与后端启动数据库部分我用的是sql脚本直接建库建表的方式脚本里包含了建库语句、建表语句和基础数据。执行步骤是打开MySQL命令行或Navicat执行CREATE DATABASE food_mall DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;创建数据库字符集必须utf8mb4不然中文会乱码运行项目提供的food_mall.sql脚本完成建表和初始数据导入后端启动前需要改配置。application.yml核心配置如下server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/food_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 你的数据库密码改完密码之后在项目根目录执行mvn spring-boot:run或者用IDEA直接运行主类。启动日志出现Tomcat started on port(s): 8080就代表后端起来了。用Postman调一个接口验证是最快的例如刚启动就能请求的推荐列表接口能拿到JSON就说明一切正常。5.3 前端依赖安装与开发服务器启动前端部分先执行npm install安装依赖。这里有一个非常关键的技巧如果你在中国大陆地区直接npm install经常卡在node-sass这类依赖上建议先执行npm config set registry https://registry.npmmirror.com换成镜像源再执行安装速度会快很多成功率也高。依赖装完之后执行npm run serve启动开发服务器默认端口是8080这会和后端端口冲突——所以我在前端vue.config.js里把端口改成了8081开发环境就这样完美错开了。module.exports { devServer: { port: 8081, open: true } }浏览器打开http://localhost:8081就能看到商城首页了。首次访问如果发现页面能打开但数据不显示大概率是后端没启动或者跨域没配置好打开控制台Network面板看一下接口请求的报错信息基本能快速定位。5.4 快速验证一套走完业务闭环的冒烟测试环境跑通之后强烈建议把核心业务链路完整走一遍我称之为冒烟测试。我的顺序是注册一个新账号退出登录再重新登录逛首页随便点开两道美食的详情页收藏其中一道再取消收藏加两道美食进购物车一部在购物车里增加数量修改单价数量后重新计算下单结算确认订单生成到管理后台用管理员账号登录看到这笔订单执行发货切回用户端看到订单状态从已发货变更为已完成完成整个闭环这套流程能在一分钟内验证全部核心功能。如果某一步出问题大概率能直接定位到对应功能模块的日志和报错信息。我打包源码的同时会提供一份纯文本的部署说明文档把上面的步骤原样写进去拿到源码的人照着做就行。6. 开发与维护中的踩坑记录你能想到的和想不到的6.1 数据库连接与字符集的坑第一个坑就是MySQL 8的驱动名和时区参数前面已经提过了这里不重复。第二个坑是配置文件里密码带特殊字符比如密码是abc123直接在yaml里写会报解析错误。解决办法是给连接串加引号或者对特殊字符做URL编码。第三个坑是中文乱码设置库、表、连接串三层字符集一致为utf8mb4才能在看数据库时发现中文不再显示成问号。如果你用8.0以上版本遇到Public Key Retrieval is not allowed这个报错解决方法是连接URL上加一个参数allowPublicKeyRetrievaltrue这是MySQL 8默认加密协议变化导致的问题很多人在这卡过。6.2 前端图片显示不出来的排查链路图片这个问题出现频率超高。排查链路我的建议是三步走第一步打开浏览器按F12看图片请求的网络响应码。如果返回404说明后端存储路径和访问路径不一致。第二步检查后端上传文件时返回的路径是绝对路径还是相对路径如果数据库存的是D:/upload/xxx.jpg通过浏览器访问localhost:8080/D:/upload/xxx.jpg肯定是404。第三步确认静态资源映射配置是否生效。我的方案是后端统一返回/images/20250101/uuid.jpg这种相对路径然后通过配置类把/images/**映射到本地上传目录。Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadPath); }照片上传成功但刷新后消失大概率是没映射成功。6.3 前后端联调时的跨域与参数格式问题跨域问题我曾经遇到过前端请求能发出去后端也正常处理但前端拿到响应体却是空的。原因是后端CORS配置里的allowedHeaders没写全。前端请求会自动带上Authorization头如果这个头不在允许列表里浏览器会在预检请求阶段直接拦截。参数格式问题最常见的坑是前端提交的是JSON串后端实体却用application/x-www-form-urlencoded的方式去接收。我的接口规范是POST请求Body传JSON后端加RequestBody注解接收实体。如果前端用qs.stringify转成了表单格式后端又不匹配接口就报参数错位或者干脆字段全是null。约定必须统一不然来回排查浪费半天。6.4 高并发下单的库存问题与优化思路这个项目在作业或展示场景下流量不大但如果你要把它做成一个简历项目面试官很可能会问下单时库存超卖怎么处理。我当前的代码实现是在Service层用Transactional保证下单事务但扣减库存用的还是先查询再更新Food food foodMapper.selectById(foodId); if(food.getStock() quantity) throw new BusinessException(库存不足); food.setStock(food.getStock() - quantity); foodMapper.updateById(food);这种写法在低并发场景没问题但高并发下两个请求同时读到剩余库存为1就可能双双通过校验最后超卖。优化方案是改成一条原子更新SQLUPDATE food SET stock stock - #{quantity} WHERE id #{foodId} AND stock #{quantity}用受影响行数判断库存是否扣减成功如果返回0说明库存不足直接回滚事务。这个改动很小但能体现你对并发问题的理解深度面试官一般会很加分。6.5 推荐算法的进一步扩展方向当前推荐算法偏简单热度计算你可以在这基础上加一个基于用户行为协同过滤的手动实现。思路是建立用户与美食的评分矩阵用余弦相似度计算用户之间的相似度然后为目标用户推荐与其最相似用户偏好的美食。这个小项目里用几千行代码手动实现一遍协同过滤绝对是简历里的亮点。除此之外还有两个成本低收益高的优化方向一是管理员后台增加人工置顶位让推荐列表可以运营干预二是把浏览和点击行为通过异步队列回写而不是每次请求都直接写库用SpringBoot的Async注解就能实现。我在实际使用中还发现一个提升体验的小细节推荐列表里的美食卡片如果超过24小时没有上新用户很快会产生审美疲劳。所以最好在后台预留一个今日上新的模块运营每天录入几道新菜整个系统的活力立刻就不一样了。做这个项目的过程中我自己也重新梳理了一遍从需求分析到部署上线的完整链路。这套源码我打包了完整的sql脚本、后端工程、前端工程和部署说明所有默认端口、路径、配置都调试到开箱即用的状态。无论你是准备选题做课程设计还是想系统学习一个前后端分离项目的完整写法把这份代码读透、改出自己的功能点得到的收获会远超过跑起来看看效果这一步。