SpringBoot+Vue美食推荐商城实战：从数据库到推荐算法全解析

这个项目我太熟了。SpringBoot + Vue 前后端分离、Java + MySQL + MyBatis，这套组合在近几年的毕业设计和课程设计里出现频率极高，“美食推荐商城”这个名字则把业务场景落到了具体的餐饮食域。先说结论：这类项目不是单纯写个CRUD那么简单，核心价值在“推荐”两个字——用户进首页该看到哪些美食、按什么规则排、后台怎么维护菜品和标签，这些才是设计的真正难点，也是面试和评委最常追问的地方。

如果你正在做毕业设计、准备Java软件项目，或者单纯想拿一个完整的前后端分离项目来练手，这篇内容应该能帮你少走不少弯路。我会按一个完整项目的推进顺序，从技术选型、数据库设计、后端实现、前端搭建到问题排查，把每个环节的关键决策和不方便写进文档的坑都捋一遍。不同学校、不同导师对系统的要求会有差异，但底层思路是通用的，把“美食”换成“图书”“二手闲置”或者别的品类，架构基本不需要大改。

1. 项目整体设计与技术选型拆解

1.1 为什么是SpringBoot、Vue、MyBatis这套组合

先聊选型，因为很多同学在开题时就被问住了。SpringBoot的核心价值是“少配置、快启动”，内嵌Tomcat，打包成可执行jar后丢到服务器上一条命令就能跑，不需要额外装容器，这对课程设计和中小型项目来说是巨大的便利。早期用SSH（Spring+Struts+Hibernate）或者SSM（Spring+SpringMVC+MyBatis）的年代，光维护一堆XML配置就能让人崩溃，SpringBoot把绝大多数配置变成了约定大于规则，项目里只留一个application.yml就够了。

Vue为什么流行？它的响应式机制让页面状态和DOM自动同步，组件化开发让页面可以拆成卡片、轮播、列表一个个独立模块复用。对一个商城类的系统来说，首页、列表页、详情页、购物车、后台管理，天然适合组件化拆分。Vue的学习曲线比React平缓，中文文档和社区资料极其丰富，遇到问题基本都能搜到答案，所以学校项目选它非常稳。

MyBatis是这套组合里最有争议也最值得聊的一环。它属于半自动ORM，SQL由开发者自己写，不像JPA那样自动生成SQL。推荐类项目恰恰需要大量自定义SQL——按销量排序、按评分排序、按标签交集筛选，这些用JPA的自动查询会写得很别扭，而在MyBatis的XML里就是几条SELECT的事。另外国内不少公司的数据访问层就是MyBatis或MyBatis-Plus，面试聊这个项目时对方不会陌生，交流成本低。MySQL则纯粹是图省心和生态成熟，免费、轻量、资料多，一个中型商城的表量和并发量完全扛得住。

版本上给个实际操作建议：如果环境还是JDK8，老老实实用SpringBoot 2.7.x；SpringBoot 3.x要求JDK17起步，很多实训环境的JDK版本并不支持，一启动就是UnsupportedClassVersionError，这种环境问题排查起来特别浪费时间。数据库连接池用SpringBoot默认的HikariCP就够了，性能好、零配置，没必要再引Druid，除非导师明确要求。

1.2 业务模块划分与前后端分离的架构分层

这个项目从功能上通常拆成前台商城和后台管理两大块。前台面向普通用户：首页推荐位、美食分类、美食列表与详情、标签筛选、购物车、下单结算、订单中心、登录注册、我的评价。后台面向运营人员：菜品管理（增删改查和图片上传）、分类管理、标签管理、订单管理（发货/完成）、用户管理、简单的数据统计看板。

前后端分离的架构下，前端是一个独立的Vue工程，后端是一个SpringBoot工程，两边通过RESTful API通信。后端项目的分包要清晰，我习惯按controller、service、mapper、entity、vo、dto、config、common、utils来组织。很多新手喜欢把entity传到前端直接当返回结果，这个习惯要改：entity对应数据库表结构，不该暴露给前端；接口返回用VO，比如食物实体里没有分类名称和标签列表，但详情页需要，这时候就要建一个FoodDetailVO把categoryName和tags组合进去。

前后端分离还有一个绕不开的话题——跨域。本地开发时前端跑在5173端口（Vite默认）或8080端口（Vue CLI），后端跑在8080端口，两边端口不同就存在跨域。解决方式有两个：前端配proxy代理，或者后端写CORS配置。实战中两者经常同时配置，后面联调章节我会把配置细节完整写出来。

2. 美食推荐商城的数据库设计

2.1 核心表拆分：用户、商品、订单、评价、标签

数据库是这种管理系统项目的灵魂，表设计得好不好，直接决定后端代码是写得顺手还是要天天写兼容逻辑。以美食推荐商城为例，我建议至少设计下面九张核心表：

• t_user：用户表，字段包括id、username、password、nickname、avatar、phone、status、create_time。密码字段建议存加密后的密文，不要明文，课程设计虽然不用上生产，但这个安全意识可以从现在就建立。
• t_category：美食分类表，字段包括id、name、icon、sort、status。分类和食物是一对多关系。
• t_food：美食商品表，字段包括id、category_id、name、description、cover_img、price、stock、rating、sales、status、create_time。字段设计上注意价格用DECIMAL(10,2)，评分用DECIMAL(2,1)，库存用INT，销量用INT。
• t_tag：标签表，字段包括id、name。美食标签可以是“微辣”“清淡”“川菜”“甜品”“适合拍照”这类贴近业务的描述，标签是推荐算法的核心素材。
• t_food_tag：食物与标签关联表，字段包括id、food_id、tag_id。多对多关系必须用关联表，不要在设计食物表时加一个tags字段用逗号拼接，后面推荐查询会非常痛苦。
• t_cart：购物车表，字段包括id、user_id、food_id、quantity、checked、create_time。checked字段用于记录用户是否勾选了该商品参与结算。
• t_order：订单表，字段包括id、order_no、user_id、total_amount、status、receiver_name、receiver_phone、address、remark、create_time。订单号要单独生成，不能用数据库自增ID当订单号，自增ID容易被遍历且不专业。
• t_order_item：订单明细表，字段包括id、order_id、food_id、food_name、food_img、price、quantity。注意这里冗余了food_name和food_img，这是故意的——下单后菜品可能改名或删图，但订单历史必须能还原当时的商品信息。
• t_comment：评价表，字段包括id、user_id、food_id、order_id、rating、content、create_time。评分数据会成为推荐算法的重要输入。

这些表之间用逻辑关联就够，不要建物理外键。外键约束写入数据库后，删除操作会被各种FOREIGN KEY限制卡住，而实际开发中这些约束靠应用层代码保障就足够了。物理外键在分库分表或测试数据清理时还会变成麻烦。

2.2 推荐数据落库：评分、销量与标签怎么设计

美食推荐系统的数据基础其实就三个维度：评分、销量、标签。评分和销量可以直接冗余在t_food表里，下单成功后执行UPDATE t_food SET sales = sales + 1 WHERE id = ?，用户提交评价后重新计算该美食的平均分并写回rating字段。很多人会问为什么不用实时统计，答案很简单：对于课程设计和中小型项目，每次打开首页都去order_item和comment表实时SUM和AVG，数据量小的时候没问题，但没必要，冗余字段用一次事务更新就能保证一致性，查询还快。

标签推荐的数据来源是用户行为。推荐系统要回答“这个用户可能喜欢什么”的问题，基础的思路是：先找到用户最近购买或评价过的美食，从这些美食的标签中统计出高频标签，再去找拥有这些标签的其他美食。实现上和真实的协同过滤还有很大差距，但作为课程设计，这个逻辑既能让评委听懂，又能体现“个性化推荐”的设计思想。

为了支撑这个逻辑，建议在t_comment表里已经能查到用户和食物的关系，如果还想追踪用户的浏览行为，可以加一张t_footprint浏览记录表，字段包括id、user_id、food_id、create_time。有了这张表，即使未购买的用户也能被推荐。

推荐核心SQL的思路大概是这样的——查用户浏览过的高频标签：

SELECT tag_id, COUNT(*) AS cnt FROM t_food_tag WHERE food_id IN ( SELECT food_id FROM t_footprint WHERE user_id = #{userId} ) GROUP BY tag_id ORDER BY cnt DESC LIMIT 3;

再根据这些标签召回候选美食，排除用户已经买过或看过的：

SELECT DISTINCT f.id, f.name, f.cover_img, f.rating, f.sales FROM t_food f INNER JOIN t_food_tag ft ON f.id = ft.food_id WHERE ft.tag_id IN (...) AND f.status = 1 AND f.id NOT IN (...) ORDER BY f.rating DESC, f.sales DESC LIMIT 8;

这个逻辑讲清楚了，推荐模块的架构就有了。

2.3 建表细节与索引设计的实战建议

建表时有一些细节，代码写多了自然能体会到。第一，字符集务必选utf8mb4，排序规则用utf8mb4_general_ci或者utf8mb4_0900_ai_ci。美食名称、昵称、评论内容里经常出现中文和生僻字，老旧的utf8字符集存emoji会报错，连带整个插入事务失败。第二，金额永远用DECIMAL(10,2)，不要用FLOAT或DOUBLE，浮点数在订单金额计算上会有精度问题，两个小数看似差别不大，累计起来账对不上非常麻烦。第三，所有表加上create_time、update_time两个通用字段，后台管理列表按时间倒序排序时就会觉得特别方便。

软删除是另一个值得说的习惯。业务表上最好加一个status或delete_flag字段，正常状态为1，删除状态为0。用户删除一条美食记录时做的其实是UPDATE t_food SET status = 0 WHERE id = ?，而不是DELETE。这样数据不会真正消失，订单历史、评价关联依然能查到，同时也符合电商系统的真实做法。注意所有查询SQL里都要带status = 1条件，漏掉一个都会导致已下架的美食出现在前端页面。

索引设计上不要盲目加索引，但下面这几个场景一定要加：t_food表的category_id和status组合索引，因为分类页的典型查询是WHERE category_id = ? AND status = 1；t_food表的sales和rating字段各建一个普通索引，因为首页推荐和热门排行都用它们做排序；t_order表的user_id字段建索引，因为个人订单中心查的是WHERE user_id = ? ORDER BY create_time DESC。索引建好后，把热门SQL拿到EXPLAIN里扫一眼，能看到key列命中索引就说明没浪费。

3. 后端SpringBoot+MyBatis的实现要点

3.1 后端骨架：统一返回、全局异常、分层分包

后端代码规范要从第一层开始建立。我强烈建议项目里先写一个Result<T>统一返回类，结构就三个字段：code、msg、data。成功时返回Result.ok(object)，失败时返回Result.error("业务提示")。这么做的最大好处是前端axios拦截器可以统一处理返回格式，不用每个接口单独判断成功还是失败。

定义统一返回类：

@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "success"; r.data = data; return r; } public static <T> Result<T> error(String msg) { Result<T> r = new Result<>(); r.code = 500; r.msg = msg; return r; } }

全局异常处理用@RestControllerAdvice加@ExceptionHandler组合，将业务异常统一拦截。比如下订单时库存不足、购物车为空，这些是业务异常，可以直接抛一个自定义的BusinessException，由全局处理器兜底转成Result.error返回前端。这样Controller层方法不需要每次写try-catch，代码干净非常多。

分层上再强调一次：Controller只做参数接收，Service写核心业务，Mapper只负责SQL。不要把Controller写得又臭又长。推荐逻辑放在ForegroundService里，后台管理的增删改查放在AdminService里，用户的登录注册单独拆一个AuthService，模块清晰，评分答辩也方便讲。

3.2 登录鉴权与接口访问控制

这类管理系统一定需要登录鉴权。实现方案上，Session和JWT是两大方向。虽然Session简单，但前后端分离项目里我更推荐用JWT——它天然适合无状态API，前端把token存在localStorage，请求时塞进Authorization头，后端用拦截器统一校验，链路简单。

JWT生成用io.jsonwebtoken:jjwt库，版本注意选0.9.1，这是兼容JDK8的常用版本。生成token的核心代码不复杂，把用户id和用户名作为负载封装进去，设置过期时间（一般24小时），用SignatureAlgorithm.HS256签名，密钥写死在配置文件中就够个人项目用了。

拦截器需要处理两个关键细节。第一个是放行白名单，登录接口、注册接口、首页推荐列表、美食详情这些不需要登录就能访问的路径必须放行，否则用户没登录就访问首页直接被拦了，前端全黑屏。第二个是注意放行OPTIONS请求，浏览器的跨域预检请求如果被拦截器拦截，返回401，前端一样会报跨域错误，排查时非常容易忽略。

跨域配置建议在后端单独建一个CorsConfig类，实现WebMvcConfigurer接口的同时配置拦截器注册和跨域映射，代码大概是这样：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new AuthInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/api/auth/login", "/api/auth/register", "/api/food/**", "/api/category/**"); } @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

注意这里配置了addPathPatterns("/**")，拦截器拿到token后调用JwtUtil.parseToken()解析，失败就抛401。

3.3 推荐逻辑怎么实现：热销推荐、评分推荐、标签推荐

推荐的商业逻辑是整个项目的亮点，也是最容易在答辩时被追问的部分。我把推荐拆成三个维度来落地，复杂度递增，但都有明确的实现路径。

热销推荐最简单，也最实用。首页顶部“今日热门”的定位就是给大多数用户看的，对所有人展示同一批菜品。SQL就是SELECT * FROM t_food WHERE status = 1 ORDER BY sales DESC, rating DESC LIMIT 8。这里把sales放在rating前面，是因为销量代表大众接受度，对一个没有登录的用户来说，“大家都买过的”比“专家评分高的”更有说服力。

评分推荐用于“高分必吃”模块，SQL是ORDER BY rating DESC, sales DESC LIMIT 8。注意排序字段不是单一评分，评分相同的时候销量高的排在前面，避免多道菜并列时排序不稳定，页面上来回刷新顺序会跳。

标签推荐这个是真正的个性化部分。我上面已经给了核心SQL，这里把完整流程理一遍。第一步，从浏览记录表查出用户最近浏览过的一批美食id；第二步，拿这批美食id去t_food_tag关联表里统计高频标签，取前三；第三步，用这些标签召回其它美食，排除用户已经浏览或买过的；第四步，对被召回的候选集按评分和销量再次排序，取前8条。整个过程可以用一个Service方法串起来，前端调用一个/api/recommend/{userId}接口就能拿到数据。

这套推荐逻辑本质上是基于内容的推荐，虽然和工业界的协同过滤差别很大，但在课程设计口径下完全够用，而且每一步SQL都能在答辩现场讲清楚原理，比单纯做增删改查有说服力得多。

3.4 MyBatis高频点：缓存、TypeHandler、配置解析

MyBatis是这套项目里面试官最爱追问的部分，下面这几个高频问题在项目里都有对应的实践场景。

缓存问题永远是第一个。MyBatis的一级缓存是SqlSession级别的，默认开启，同一个SqlSession内执行两次相同的查询，第二次不会查数据库。但Spring整合MyBatis后，每次请求都会重新创建SqlSession，所以一级缓存基本只在事务方法内生效，比如一个@Transactional方法里连续两次查询同一个商品，第二次会走缓存。二级缓存是Mapper级别的，跨SqlSession共享，但这个缓存默认是不建议开的。原因很简单：二级缓存存在脏数据风险，商品的库存、销量这些字段更新极其频繁，如果开了二级缓存，一次UPDATE后旧数据还留在缓存里，用户看到的还是修改前的价格和库存，这个坑我在实际项目里踩过，排查了整整一下午。如果你想让首页的热门推荐列表加速，更靠谱的方案是把热点数据放到Redis里，或者用Spring Cache的@Cacheable注解，设置过期时间，而不是直接开MyBatis的二级缓存。

TypeHandler是个容易被忽视但面试常考的点。它的作用是在JDBC类型和Java类型之间做转换。实际项目里有一个很好用的场景：美食图片的URL在数据库里存的是相对路径/images/xxx.jpg，但前端需要展示完整地址http://ip:8080/images/xxx.jpg，这个拼接工作可以在TypeHandler里完成。自定义TypeHandler需要继承BaseTypeHandler<String>，实现setNonNullParameter和getNullableResult四个方法，然后在Mapper XML的<resultMap>里用typeHandler="com.xxx.handler.ImageTypeHandler"指定。如果你不想这么麻烦，也可以建一个VO层统一拼接，但能讲出TypeHandler的原理，面试官会高看你一眼。

MyBatis的启动流程和配置解析也是高频题。SqlSessionFactoryBuilder读取mybatis-config.xml或Spring Boot配置后，会调用XMLConfigBuilder进行配置解析，最终生成Configuration对象。Configuration里维护了MappedStatement（每条SQL的封装）、MapperRegistry（Mapper接口的注册中心）、Environment（数据源和事务工厂）等核心内容。理解了这个流程，就能明白为什么Mapper接口和XML的namespace必须一致，也就能定位“Invalid bound statement”这类最常见报错。

4. 前端Vue的搭建与前后端联调

4.1 初始化项目与依赖安装

前端部分先从建项目开始。Vue 3项目我建议用Vite作为构建工具，启动速度快，热更新几乎是秒级，开发体验比Webpack好太多。命令很简单：

npm create vite@latest food-mall-front -- --template vue cd food-mall-front npm install npm run dev

如果环境里Node版本比较老，或者是导师要求用Vue 2 + ElementUI的组合，那就用Vue CLI那套老方案。这里有个经验：Vite 4以上版本通常要求Node 14.18+或16+，如果你的电脑装的是老版本Node，项目初始化时会直接报错提示升级，遇到这种情况不要硬刚，按提示升级Node或者换Vue CLI方式创建都能解决。

必装的依赖就四个：vue-router（路由）、axios（HTTP请求）、element-plus（UI组件库）、pinia（状态管理）。个人项目里购物车数量、用户token这类状态用Pinia管理比到处localStorage取值舒服很多。装完依赖后建议把项目目录结构先搭出来：src/router、src/api、src/views、src/components、src/store，每个模块放什么一目了然。

前端页面的组织逻辑是：登录注册页、首页、美食列表页、美食详情页、购物车页、订单确认页、订单中心、后台管理用一套独立布局。后台管理部分可以单独弄一个/admin路由组，用子路由管理菜品列表、分类管理、订单列表等页面，和前台完全分离。

4.2 axios封装与路由守卫

axios封装是前端工程质量的分水岭。不要在每一个页面里直接import axios然后发请求，一定封装一个统一的请求模块。核心配置是三段：baseURL、请求拦截器、响应拦截器。baseURL可以设置为/api，开发时配合Vite代理转发到后端地址。请求拦截器里从localStorage或Pinia取出token，加到headers.Authorization上。响应拦截器统一处理返回结果：

service.interceptors.response.use( (response) => { const res = response.data; if (res.code === 200) { return res.data; } if (res.code === 401) { router.push('/login'); return Promise.reject(new Error(res.msg)); } ElMessage.error(res.msg || '系统繁忙'); return Promise.reject(new Error(res.msg)); }, (error) => { ElMessage.error(error.message || '网络异常'); return Promise.reject(error); } );

这段拦截器代码能帮你省掉90%的重复错误处理逻辑，后端返回非200状态码，前端自动弹提示；后端返回401，前端自动跳登录页。这是很多人容易忽略的细节——如果不做统一拦截，每个页面都要自己判断res.code，维护成本翻倍。

路由守卫的目的是防止未登录用户访问需要登录的页面，比如购物车、个人订单中心、后台管理。在router.beforeEach里判断目标路由的meta.requiresAuth字段，有登录状态就放行，没有就重定向到登录页并带上redirect参数方便登录后跳回原页面。后台管理还需要判断用户角色是否管理员，如果不是就拦截并提示无权限。

4.3 跨域代理与联调细节

前后端联调跨域是出现频率最高的问题。Vite本地开发时只需要在vite.config.js里配置代理：

server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/food/list时，Vite开发服务器会把请求转发到http://localhost:8080/api/food/list，浏览器层面没有跨域，自然就不需要后端配置复杂的CORS了。注意changeOrigin必须设为true，否则后端的反向代理钩子可能识别不了真实来源。

联调时经常遇到下面几个状况。接口404：先检查是前端路径和后端路径不匹配，还是代理规则没生效。路径不匹配常见于前端路径写/food/list而后端接口是/api/food/list，看Network面板的请求URL一目了然。接口返回401：那就不是跨域问题，而是token没传或者过期了，检查请求头里Authorization对不对。ERR_CONNECTION_REFUSED：后端服务压根没启动，先回去java -jar或者启动IDE里的Application类。

生产环境部署就完全不同了，前端构建后产物是dist目录下的静态文件，可以扔到Nginx里做静态资源服务，再配置API反向代理到后端地址；也可以把dist目录直接放到SpringBoot的resources/static里，打成一个包，访问入口变成同一个端口，彻底避开跨域问题。课程设计用第二种方案更省事，答辩演示时只需要一个java进程两个请求入口。

5. 常见问题排查与避坑实录

5.1 MySQL安装与连接踩坑

MySQL相关的问题占了环境报错的大头。安装阶段最常见的坑是忘记初始化数据和设置字符集，Windows环境下用免安装版zip解压后一定要执行mysqld --initialize-insecure，否则后续服务根本启动不起来。连接阶段的高频报错有三个。

第一个是Communications link failure或者SSL connection error：MySQL 8默认开了SSL，而JDBC连接串没配SSL相关参数会出现连接时断时续或者直接拒绝。解决方案是给连接串加useSSL=false&allowPublicKeyRetrieval=true，其中allowPublicKeyRetrieval在MySQL 8里很关键，很多教程里都不提，不加就会报Public Key Retrieval is not allowed。

第二个是The server time zone value ... is unrecognized：MySQL 8的时区设置需要明确指定，连接串上加上serverTimezone=Asia/Shanghai就能解决。顺手把JDBC驱动类名再确认一遍，MySQL 8对应com.mysql.cj.jdbc.Driver，MySQL 5对应com.mysql.jdbc.Driver，用错版本会直接ClassNotFound。

第三个是3306端口被占用。Windows下用netstat -ano | findstr 3306查端口占用，找到进程号后在任务管理器里结束，或者把MySQL的端口改成3307。这种问题几乎每个环境都会遇到一次，记住排查命令比瞎重启有用得多。

5.2 SpringBoot与MyBatis运行期报错

后端运行期最经典的报错是Invalid bound statement (not found)，看到这个报错你的第一反应是去检查Mapper接口和XML的对应关系：Mapper接口的包路径、接口名、方法名和XML里namespace、id是否全对得上。第二反应是检查target目录，SpringBoot打包时经常因为resources过滤配置不对，导致mapper/*.xml没有编译到target/classes下。有个简单的解决办法是在pom.xml的build节点下显式声明把src/main/resources下的XML文件包含进打包列表，或者直接把XML放到底层resources/mapper目录里。

Consider defining a bean of type 'xxxMapper'这个报错多半是忘了加@MapperScan。如果Mapper接口分散在多个包下，逐个加@Mapper注解容易漏，我建议直接在启动类上加@MapperScan("com.xxx.mapper")，一劳永逸。第三类经典问题是端口冲突：Port 8080 was already in use，改application.yml里的server.port换一个端口，或者找到占用进程杀掉。

还有一个隐蔽但高频的问题：application.yml配置文件里数据库连接的driver-class-name、url、username、password四个配置项缺一不可，而且url里如果前面漏了jdbc:mysql://，HikariCP启动时会报一堆看不懂的SQLException，很多人会在这一步浪费大量时间。看一眼配置文件的英文标点是否有中文逗号，也是不可忽视的细节。

5.3 拿到jar包后怎么快速还原项目结构

网上下了个完整源码或者拿到一个可运行的jar包，怎么快速看懂项目结构？很多新手拿到jar包习惯直接双击解压，结果看到一堆class文件傻眼了。正确做法是先看META-INF/MANIFEST.MF里的Start-Class字段，它指向SpringBoot启动类。然后关注三个位置：BOOT-INF/classes下是项目的class文件和resources，BOOT-INF/lib下是全部依赖jar包，application.yml就躺在classes目录里。

想要还原出可阅读的Java源码，可以用IDEA自带的Fernflower反编译器，或者独立的JD-GUI、Luyten工具，把BOOT-INF/classes整体拖进去，class文件会被还原成近似源码的Java代码。之后按照Controller包找接口入口、Service包找业务逻辑、Mapper XML找SQL这个顺序去读，整条链路就能理清楚。这里多提醒一句：反编译得到的代码仅供学习和理解业务，不能直接拿去商业使用或提交成自己的毕业设计，该自己写的代码还是要自己写。

5.4 面试官对项目的高频追问与准备

如果这个项目是你面试时拿来聊的项目，有些问题必须先想好答案。

MyBatis和JPA怎么选？这个问题的关键是说清场景：MyBatis适合自定义SQL多、查询复杂的系统，推荐排行和标签检索这类SQL用MyBatis写起来直观；JPA在简单CRUD上效率高，但遇到复杂查询还是得退回到SQL或者JPQL，学习成本也不低。第二问通常是一级缓存和二级缓存的区别，按我上面说的从SqlSession级别和Mapper级别两个角度回答，顺便提一句二级缓存脏数据风险，就能把这个问题答扎实。

下一问大概率是事务相关。下单接口必须加@Transactional，原理是保证扣库存、创建订单、计算订单明细这几个操作同时成功或同时失败。老练的面试官还会追问事务为什么会失效，列举三种：方法里自己catch了异常导致事务感知不到、同类内部方法自调用导致代理失效、方法不是public。提前把这些坑说出来，面试官会认为你真的写过项目而不是背了理论。

还有一个追问点是你如何防止超卖。顺序执行下单时，如果扣库存直接UPDATE t_food SET stock = stock - 1 WHERE id = ?，并发场景下就会有超卖。正确写法是UPDATE t_food SET stock = stock - 1 WHERE id = ? AND stock > 0，通过受影响行数判断是否成功，没成功就抛“库存不足”。另外还可以提一下乐观锁，在食物表加version字段，更新时校验版本号。这两个方案讲清楚，就比大多数只会说“用synchronized”的候选人有说服力。

对于推荐系统本身，还要准备好“推荐算法还能怎么优化”这个问题。可以回答引入基于用户行为的协同过滤，计算用户间相似度，或者把结果缓存到Redis减少数据库压力。不一定真的做出来，但思路要清晰，这和上面实现的基于标签的内容推荐可以形成递进关系。

把下面这张速查表存一下，基本上能覆盖这个项目的日常运维和答辩问题：

最后分享一个我自己的习惯。每次拿到这类SpringBoot+Vue的项目，我第一件事不是一头扎进代码，而是先跑一遍启动脚本、看一眼数据库ER图和README，把这个链路的入口和出口摸清楚。读别人的代码或者自己重新梳理项目时，从数据库表关系入手往往比从Controller入手快得多。这个习惯帮我避免了很多“代码看了三天，一启动全是环境报错”的无效劳动。今天这篇也算是把这套流程完整走了一遍，希望你在自己的项目上少踩几个坑。