做计算机毕业设计，选一个既能覆盖业务复杂度、又能体现技术栈掌握程度、还得有故事可讲的题目，真的比写代码本身更费脑子。我当时定下这个“基于SpringBoot的营养预制菜个性化定制平台”之前，其实也纠结过好几个方向，最后之所以敲定这个，是因为它本质上是一个“膳食半成品智能推荐与订购系统”，也就是在Java Web架构下做一个健康速食个性化搭配服务平台，既有传统电商的订单闭环，又有推荐系统可以深挖，还有健康营养这个当下热度很高的业务场景可以包装。这篇博文就把我这套系统从选题、建模、编码到答辩的完整思考过程写出来，如果你也在做类似毕业设计，或者刚入门想做一套能拿得出手的Java Web项目，可以直接参考我的设计思路和代码片段。先说一个很现实的点：毕设项目最怕的不是功能少，而是“没有逻辑”。CRUD谁都会写，但为什么这样建表、为什么这样设计接口、推荐算法为什么不直接套一个深度学习模型，这些问题才是答辩时老师真正关心的。我这篇文章会尽量把每个关键决策背后的理由都讲清楚，而不是给你一堆能跑但解释不了的代码。1. 为什么选这个题目：预制菜赛道下的真实需求拆解1.1 从“今天吃什么”到平台价值如果你每天中午打开外卖软件，发现翻了二十分钟还不知道点什么，你就知道“膳食半成品个性化定制”这个需求有多真实了。半成品预制菜这两年已经渗透进普通家庭的冰箱，但用户面临的问题是：菜品种类多、营养信息不透明、搭配全靠感觉。所以这个平台的核心价值不是卖货，而是替用户做“吃什么”的决策。我把这个问题拆成三层：第一层是“食材与菜品匹配”，用户输入自己的忌口、目标热量、偏好口味，系统帮他过滤出合适的半成品；第二层是“组合搭配”，单买一包酸菜鱼不算健康餐，系统应该能推荐“酸菜鱼 + 杂粮饭 + 白灼时蔬”这种组合；第三层是“持续追踪”，用户这周吃了几次高油高盐菜品、蛋白质摄入够不够，需要平台用数据告诉他。这三点就是我整个毕设的顶层需求，后面所有的表设计、推荐逻辑、页面交互都是围绕它们展开的。一个能落地的系统，必须有这种递进式的价值逻辑，不然就是一个普通的商城壳子。1.2 目标用户与业务边界我不建议在毕设里把用户角色设计得过于复杂。这个平台我只做了三类角色：普通用户、营养师、管理员。普通用户负责浏览、定制、下单、查看营养报告；营养师可以维护菜品库和营养标签，相当于内容运营；管理员管用户状态、订单状态、基础数据字典。单看角色数量，这个设计中规中矩，但业务边界很清晰——所有核心功能都围绕“个性化推荐”和“半成品订购”两条主线。我没有去做社区、评论、积分商城这些容易让项目失去焦点的功能。整个系统的业务闭环是：用户完善偏好画像 → 平台推荐菜品/套餐 → 用户调整定制内容 → 生成订单 → 支付模拟 → 订单状态流转 → 营养数据回写画像。这个闭环的每一环都能在答辩时讲出设计意图，而且每一环都对应一个具体的数据表或算法逻辑，这就是我要的效果。1.3 功能清单：没必要一次性做全毕设有半年时间，但你不能真的按商业产品去做。我列功能清单时的原则是：核心链路必须完整，边缘功能可以忍痛放弃。最终确定的功能包括：用户注册登录、偏好画像维护、菜品/套餐浏览、基于标签和画像的智能推荐、个性化定制（替换配菜、调整分量）、购物车、订单提交与状态跟踪、营养报告统计、后台菜品管理和订单管理、营养师对菜品标签的审核维护。被砍掉的功能有：优惠券、秒杀、实时物流追踪、在线支付对接。这些功能要么需要外部接口，要么对答辩加分有限。支付我用了模拟支付开关处理，物流只更新状态点，不接第三方API，因为真实支付和物流接口的审核流程会占用大量时间，而且出了问题很难在演示现场兜底。2. 技术选型：SpringBoot 3 + MyBatis-Plus + Vue3 的取舍逻辑2.1 后端为什么是SpringBoot 3.x标题里已经写死了SpringBoot，这个没有太多悬念。但我要说的是选SpringBoot 3.x而不是2.x的理由。SpringBoot 3.x 基于Jakarta EE 9规范，默认内置了GraalVM原生镜像支持的方向，更重要的是它强制要求Java 17以上版本。用新版本的好处是，答辩时你可以主动说“我使用的是SpringBoot 3.1，Java 17的虚拟线程在某些IO场景下有优化尝试”，这个话术比“我用了SpringBoot 2.7”听上去更有技术敏感度。实际开发中，SpringBoot 3.x对日常CRUD、事务管理、参数校验这些操作和2.x差别不大，甚至大部分代码可以直接平移。真正需要注意的是一些第三方starter的兼容性，比如某些旧版分页插件、代码生成器可能不支持SpringBoot 3.0，我后面会在防坑部分专门讲。不过我不建议纯粹为了“新版”去用新版本，一个稳定跑通的2.7项目，比一个到处报依赖冲突的3.1项目更适合毕业答辩。我当时选择3.x是因为前期调研发现主流starter基本都完成了适配，风险可控，而且这样可以在简历里写“熟悉SpringBoot 3.x生态”。2.2 ORM：MyBatis-Plus还是JPA这是很多同学纠结的地方。我的答案是MyBatis-Plus，原因是这个项目的查询场景非常碎片化，尤其是推荐模块需要频繁按动态条件组合查询菜品标签、热度、库存，而MyBatis-Plus的LambdaQueryWrapper能够非常方便地拼接条件，不用写大量@Query注解或者XML。举个例子：推荐接口要根据用户画像筛选“口味偏辣+高蛋白+价格低于30元”的菜品。在JPA里这可能要写一个方法名很长的派生查询，或者JPQL字符串；用MyBatis-Plus就是三行代码的事。另外一个隐藏优势是MyBatis-Plus的代码生成器，能根据表结构快速生成实体、Mapper、ServiceImpl，虽然毕设要自己写核心逻辑，但那些重复性的CURD（增删改查）代码交给生成器能省出一周时间，这部分时间拿来研究推荐算法不香吗。当然，JPA也不是一无是处。如果你的系统实体关系极其复杂，嵌套层级很深，JPA的级联操作确实省事。但像这种电商属性较强的系统，我还是更倾向于控制SQL的可预测性，用MyBatis-Plus加少量自定义XML最稳。2.3 前端：Vue3还是服务端模板考虑到毕设的时间成本，我选了前后端分离，前端Vue3 + Element Plus，后端纯RESTful接口。前端用Vite搭建，Axios统一封装请求，状态管理直接用Pinia。为什么不上服务端模板？因为模板渲染的方案（比如Thymeleaf）虽然开发快，但有两个问题：一是页面交互复杂时，AJAX片段更新会让代码非常混乱；二是答辩时如果老师问“你的系统前后端怎么分离的”，你会很难讲清楚。相反，前后端分离项目能展示的知识点更丰富：跨域处理、JWT存储与刷新、接口统一响应结构、Vue路由守卫。这些都是Java Web岗位面试真会问的东西。但前提是你得把前端工程控制在一个能维护的复杂度内，我自己的经验是：页面数量控制在15到20个以内，组件复用优先，不要过度封装，否则调样式的时间比写后端还多。2.4 缓存：Redis在这里不是必须但很加分我确实在菜品热榜、推荐结果缓存、验证码存储三个场景用了Redis。你可以说它是“可替换的”——因为纯用MySQL也能实现这些功能，但加入Redis之后，整个系统的层次感就出来了。比如首页的“本周热销半成品”接口，如果每次都去订单表做聚合查询，一旦数据量上来响应就会变慢，而缓存10分钟一次热榜数据，性能是肉眼可见的。Redis在毕设里的另一个好处是能展示“缓存穿透/缓存雪崩”的防护思路。我用了空值缓存加随机过期时间，虽然系统量级很小，但这个设计思路在答辩时非常加分。你甚至可以主动说“虽然目前没有并发压力，但我预留了缓存防穿透处理”，老师一听就知道你不是只写了一堆CRUD。基础设施选型上说一句题外话：MySQL版本我选了8.0，因为json字段类型、窗口函数这些特性很实用。比如统计用户蛋白质摄入趋势，用窗口函数可以在数据库层解决，而不是捞到Java内存里慢慢算。3. 数据库设计：先聊订单结构，再说推荐表3.1 主表结构：用户、菜品、食材与标签这个平台的主表并不复杂，核心是用户表、菜品表（预制菜表）、食材表、标签表、用户偏好画像表。这里我重点说一下菜品表的设计，因为它是整个推荐和推荐逻辑的基石。t_dish（菜品/半成品表）我设计了如下字段：dish_id、dish_name、main_category（属于哪条产品线）、price、stock、calories_per_100g、protein、fat、carbohydrate、sodium、spicy_level、cooking_time_minutes、status、sale_count、create_time。注意，我把六大营养素核心指标做成了冗余字段直接存在菜品表里，而不是单独建一张营养明细表。这样做确实不够范式化，但对于这个系统来说，推荐算法需要快速读取营养指标，多表联查会把性能拖垮，而且营养数据本身是相对静态的，冗余的代价可控。标签表存的是“低脂”“高蛋白”“适合减脂”“重辣”“儿童友好”这类业务标签，菜品和标签之间是多对多关系。你一定会上演一个经典操作：用中间表把菜品和标签关联起来，推荐时通过标签匹配做召回。3.2 订单与订单项：半成品的特殊性订单表的设计和普通电商基本一致：order_id、user_id、total_price、status、address_snapshot、pay_type、create_time。订单项表里我多加了一个字段叫meal_plan_id，用来关联“用户定制的套餐组合”。为什么强调这个字段？因为普通购物车订单只需要记录“买了哪道菜、数量多少”，但这个平台的订单项可能是“用户把一份单人餐里的酸菜鱼换成了水煮牛肉，主食从米饭换成杂粮饭”。这种动态搭配如果不用定制方案相关的字段接住，后面的营养报告和推荐画像就没法追溯。我的方案是设计一个custom_spec字段，用JSON记录当前菜品的替换明细，快照式保存到订单项里，避免之后菜品表修改导致历史订单对不上。订单状态我用一个整数字段表示：0待支付、1已支付待处理、2备货中、3已配送、4已完成、5已取消。每个状态迁移都会写入一张t_order_log操作日志表。这个日志表在答辩演示时会成为你的“表演点”——随便点几下订单流程，日志记录一条条蹦出来，系统“活了”。3.3 推荐相关表：记录画像来源推荐系统最怕的是“不知道为什么推荐了这个”。所以我在数据库里设计了用户偏好标签表（user_preference）、用户行为记录表（user_behavior_log）、推荐结果记录表（recommend_record）。user_preference不仅存“用户喜欢什么”，还存“来源类型”：是用户主动勾选的，还是从历史订单里算出来的。这个细节帮助你复盘推荐效果，也能让推荐代码分工清晰。user_behavior_log记录浏览、收藏、点击推荐等行为，字段有behavior_type、target_id、detail_json、create_time，这个表是推荐离线计算的核心数据源。recommend_record表在推荐接口执行时写入，记录为用户推荐了哪些菜品、召回候选集多大、最终展示排序如何。有了它，答辩时被问“推荐结果可解释性”就非常稳，你可以直接查库找出一条记录，说明这条推荐来自哪几个标签的加权计算。3.4 一段可用的建表SQL为了不让设计只停留在概念上，这里放两个我用到的关键建表语句。菜品表精简版如下：CREATE TABLE t_dish ( dish_id BIGINT PRIMARY KEY AUTO_INCREMENT, dish_name VARCHAR(64) NOT NULL, main_category VARCHAR(32) NOT NULL, price DECIMAL(8,2) NOT NULL, stock INT NOT NULL DEFAULT 0, calories_per_100g INT NOT NULL, protein DECIMAL(5,1) NOT NULL, fat DECIMAL(5,1) NOT NULL, carbohydrate DECIMAL(5,1) NOT NULL, sodium INT, spicy_level INT DEFAULT 0 COMMENT '0不辣 1微辣 2中辣 3重辣', cooking_time_minutes INT, status TINYINT DEFAULT 1, sale_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_category (main_category), KEY idx_sale (sale_count) );用户偏好标签表如下：CREATE TABLE user_tag_preference ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, tag_id BIGINT NOT NULL, weight DECIMAL(5,2) NOT NULL DEFAULT 1.00 COMMENT '标签权重', source_type VARCHAR(20) NOT NULL COMMENT 'INIT/ORDER/BEHAVIOR', source_data VARCHAR(128), update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_tag (user_id, tag_id) );说明一下weight字段，它是整个推荐算法的“旋钮”，用户主动选择的标签权重高，行为积累的标签权重会随次数递增，后台运营可以通过调整基础权重来干预推荐倾向，这就是可解释的推荐依据，而不是黑盒。4. 推荐引擎不是玄学：标签召回与加权排序的实现细节4.1 冷启动：没有历史数据怎么召回推荐模块最先遇到的问题就是冷启动。新用户注册进来后没有任何行为数据，这时候如果推荐算法直接根据行为记录来算，结果就是空集。我的方案是：引导用户在注册流程里完成一个“饮食偏好问卷”，选项包括口味、忌口、目标（减脂/增肌/维持体重）、每餐预算，然后把这些选项映射为标签，写进user_tag_preference表，source_type标记为INIT。有一说一，冷启动效果的天花板取决于标签映射表的丰富度。比如问卷里选“减脂目标”，系统就要清楚地把“低脂”“高蛋白”“低卡”这三个标签打上位。我预留了一个配置表tag_rule_config，专门做这种规则映射，维护好这个表，冷启动召回就不会出大错。这个阶段召回用的是经典标签匹配：计算用户标签集合和每个菜品标签集合的Jaccard相似度，把相似度大于阈值（我定为0.3）的菜品作为候选集。虽然是老方法，但好在逻辑透明、效果稳定、代码量小，作为毕设完全够用。4.2 画像更新：从订单和收藏中学习用户用了几天系统之后，画像就不能停留在问卷答案了。我在订单完成事件和用户收藏事件里都埋了画像更新逻辑。核心思路很朴素：用户完成一笔订单，包含的菜品标签就计数加一；用户把某个菜品加入收藏夹或者反复浏览三次以上，同样给标签加分。这里需要做的就是权重归一化，防止热门标签无限涨分。我用的方法是加滞衰减：更新时间越久，历史贡献权重越低。具体公式是：标签权重 = 历史权重 * 0.9 ^ (距离上次更新的天数) + 本次增量。这个参数调参很简单，0.9是我们模拟数据下效果最平滑的值，你可以根据自己的测试调整。关键点在于，画像更新必须和推荐逻辑解耦。我没有在推荐接口里更新画像，而是通过Spring事件机制，在订单状态变成“已完成”时发布一个事件，监听器异步去更新标签权重。这样即使画像计算慢一点，也不影响用户下单主链路。4.3 打分排序：营养搭配公式召回到候选集之后，下一步是打分排序。打分公式是我自己设计的，综合考虑营养匹配度、价格、热度、库存四个因素：score = 0.45 * nutrition_match + 0.25 * user_tag_match + 0.2 * popularity + 0.1 * price_penalty先看nutrition_match，它衡量半成品与用户目标的匹配程度。举个例子，用户目标是减脂，那么低热量、高蛋白、低脂肪的菜品得分高。部分匹配计算方式为：/** * 减脂目标下，蛋白占比越高分越高，热量与脂肪越低分越高 */ public double computeNutritionMatch(Dish dish, UserGoal goal) { if (goal == UserGoal.FAT_LOSS) { double proteinScore = Math.min(dish.getProtein() / 20.0, 1.2); double calorieScore = 1.0 - Math.abs(dish.getCaloriesPer100g() - 180) / 180.0; double fatScore = 1.0 - dish.getFat() / 15.0; return Math.max(0, proteinScore * 0.5 + calorieScore * 0.3 + fatScore * 0.2); } // 其他目标类似，每个目标的参考指标从配置中心读取 return 0.5; }这里只是一个简化版本，但不能直接用固定值去卡，因为每个人的基础代谢和训练频率不一样。所以我从用户表里读取了goal配置，之后把目标参数化存储在hash map里。具体实践时，你可以把这组权重放到配置表里，随时调整，这不是算法炫技，但体现的是一个“平台”的系统思维。4.4 一个可落地的“召回-过滤-排序”流程推荐接口实际执行的流程是：读取用户标签 → 构建菜品候选集（排除下架、库存为0）→ 用规则过滤掉用户明确不吃的食材（比如用户偏好表里有“过敏原-花生”，候选集里的花生类菜品全部删除） → 计算得分排序 → 返回Top10 → 写入recommend_record表。排序之后的推荐不再直接展示，我还会加一个“重排”逻辑：连续给用户推同品类菜品不好看，所以同类菜品最多出现两个，保证推荐列表的多样性。这个逻辑很简单，但是用户体感提升非常明显，很多现成的推荐系统都会做多路召回与多样性打散，你在答辩时多提这个细节会让老师对你刮目相看。代码结构上，我把推荐分成了三个独立接口：RecommendService负责召回与排序，TagProfileService负责画像管理，RuleFilterService负责硬性过滤。三者之间不互相调用重逻辑，方便后来扩展新的推荐策略，比如你想做基于协同过滤的接口，只需要新增一个CallaborativeRecommendService实现同一个接口即可。5. 个性化定制与下单链路：前后端配合最容易漏掉的校验5.1 定制流程：四步交互与后端校验点定制页面我设计了四个步骤：选择套餐原型 → 调整配菜/主菜 → 确认营养指标预览 → 加入购物车或直接下单。这种引导式的交互，比用户自由搭配的体验更友好，因为完全自由搭配容易让用户选择困难，原型套餐则给了用户一个起点。这里最容易漏掉的后端校验点是“替换约束”：不是随便哪道菜都能互相替换。比如用户想把套餐里的汤品换成甜点，但是甜点的制作时间更长，可能与出餐时间冲突，系统需要给出提示。我在菜品表里加了一个replace_group字段，只有处在同一替换组的菜品才允许替换。后端在提交定制配置时，必须校验替换前后是否属于同一个replace_group以及分量是否匹配（大份/小份不能混换）。后端校验链我放在定制接口的service层，没有用分散的前端校验。因为前端校验再完善，恶意请求依然可以绕过，而且集中式校验方便单测覆盖。每一次校验失败都会返回统一的Result对象，里面带一个errorCode和前端提示文案，前端根据errorCode展示对应的弹窗提示。5.2 价格计算与库存扣减定制之后，价格需要实时重新计算。我的算价策略并不复杂：套餐原型有一个基础价，替换菜品时用“替换差价”来完成加减。举例来说，套餐E的原价是29.9元，用户把默认的鸡胸肉换成三文鱼，差价是+8元，最后定制价就是37.9元。这里需要注意精度问题，金额类型必须用BigDecimal而不是double，经典面试考点，同时也能避免数据库小数精度陷阱。我在前端展示价格时也会统一保留两位小数，防止出现“37.9000000001”这种尴尬画面。库存扣减我选择了“下单预占、支付确认、超时释放”的流程。订单提交时将所涉菜品的库存做原子扣减，如果任何一道菜库存不足，整个订单直接失败，并把之前已经扣减成功的库存回补。这里一定要在事务里操作，回补是自动的，否则并发情况下容易出现库存超卖。虽然毕设没有高并发环境，但订单一致性的代码逻辑写对了，老师问起来你就能说得头头是道。5.3 订单的防重与状态流转给订单做幂等是个很值得写的点。用户在前端快速点击两次“提交订单”，如果后端没有防重逻辑，就会产生两笔相同订单。我的做法是前端生成一个requestNo传给后端，后端把request_no作为唯一索引存进订单表，提交时一旦插入冲突就回滚，并返回“订单正在提交或已提交”。很多同学会在这一环节纠结“分布式锁”，其实不是必要。对于单机部署的毕业设计来说，唯一索引+事务是最简单最有力的方案。你可以在答辩时说清楚：如果未来需要拆分为微服务或提升并发，会引入Redis分布式锁来标记请求状态，但现在的数据一致性完全由数据库保证。订单状态流转我不建议做太灵活，否则每个状态都有一段不可控的代码逻辑。我的做法是定义一个状态机类，集中管理状态迁移规则。比如“待支付”只能走到“已取消”或“已支付待处理”，“已完成”之前必须经历“备货中”和“已配送”，任何非法状态迁移直接抛异常，从代码层面杜绝脏数据。5.4 关键Controller示例为了更直观，这里摘一段提交订单的Controller代码，注意接口的职责切分和参数校验：@RestController @RequestMapping("/api/order") public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping("/submit") public Result<Long> submit(@RequestBody @Valid OrderSubmitRequest request) { Long orderId = orderService.submitOrder(request); return Result.success(orderId); } }你可能觉得这段代码太简单了，但这就是正确职责切分该有的样子。Controller只负责接收请求和初步校验，事务、库存扣减、状态机逻辑全部下沉到OrderService，将来无论怎么改页面，后端逻辑都能稳定复用。我在OrderSubmitRequest里用了Hibernate Validator的注解，比如@NotNull、@Min(value = 1)，这些是SpringBoot集成非常好的一个点，能写进技术方案中。6. 毕业设计防坑指南：从本地开发到答辩演示6.1 本机部署的几个实测坑每个项目都免不了踩环境坑。我先把SpringBoot 3.x最大的坑放在前面：很多第三方starter还在用javax.*包，而SpringBoot 3.x选择了jakarta.*包。如果项目里意外引入了旧依赖，启动时就会报ClassNotFoundException或者NoSuchMethodError。解决思路很简单：尽量用官方starter和已经适配SpringBoot 3的版本（比如MyBatis-Plus版本至少3.5.3.1以上）。我当时就是被某个小工具库卡了整整一个晚上，最后发现只是一个旧版本依赖没升级。Redis这一环也需要提醒，Windows本地用的Redis版本和项目配置必须一致。如果你使用自带的配置，默认端口6379和密码为空，那么代码里不要多余配置密码字段，否则启动时认证失败；生产环境则建议设置密码，并用环境变量注入。至于连接池，SpringBoot默认自带Lettuce连接池，不需要额外引入，别画蛇添足。数据库连接串里需要开启useSSL=false，因为本地MySQL一般没配证书，如果不关闭SSL，启动经常会报警告甚至连接失败。还有时区的坑，连接串后面加上serverTimezone=Asia/Shanghai，不然时间字段会比实际少8小时，你查订单时间会觉得系统“穿越了”。6.2 演示数据要“看起来像真数据”毕业答辩演示最尴尬的瞬间是什么？是老师凑过来看屏幕，发现用户列表里只有“user1”“user2”，菜品只有“菜A”“菜B”。要让系统显得扎实，演示数据必须足够真实和丰富。我花了大概一个晚上造数据：用户用中文姓名加常见手机号，菜品名像“孜然鸡胸肉健身餐”“泰式酸辣魔芋结”“番茄牛腩低卡套餐”，营养数据按真实食物大致填，订单时间分布在最近两周，状态覆盖从待支付到已完成完整链路，用户收藏和浏览记录也导了一百多条。这些数据能让推荐算法跑起来，也能让订单统计图表有故事可讲。造数据的另一个作用是验证推荐效果。如果发现某个标签权重的用户推荐出来的菜品完全不合理，就要回头调整打分公式的阈参数。这个调试过程本身就是很好的答辩素材，你可以展示“为了让减脂用户优先看到高蛋白低卡产品，我对营养匹配部分的权重做了调整，最终观察推荐列表分布趋于合理”。6.3 答辩高频问题与回答框架根据我自己的答辩体验，老师对毕设的提问一般集中在三块：技术选择的合理性、业务设计的完整性、项目中的难点亮点。第一个问题往往是“为什么选这个技术栈？”回答框架是：面向场景、对比分析、总结取舍。比如SpringBoot是因为自动配置够快、生态完整；MyBatis-Plus是为了动态条件查询；Vue3是为了组件化交互。不要背官方定义，你只要说明这几个技术组合在这个业务场景里的适配性就够了。第二个问题是“推荐系统怎么实现的？”回答框架是：分模块、按流程、强调可解释性。我通常从冷启动开始讲，说明标签召回，然后讲用户画像更新，最后讲加权排序和多样性打散。主动说出“推荐结果表记录可回溯”，老师就明白你不是随手写个排序。第三个问题是“订单并发下库存怎么控制？”问这个概率极高。回答框架是：事务内先扣库存、失败回滚、落库唯一约束。如果你能顺手画出状态机的流转逻辑，这个问题基本就稳了。被问到不会的问题也别慌，坦诚说目前系统的设计边界在哪里，以及你计划的改进路径是什么，这个态度比背答案更能拿到分。6.4 还能往哪些方向扩展虽然毕设不需要真的做到上线，但你可以在结尾给老师展示“这个系统的未来”会更有竞争力。我总结过几个自然的扩展方向，每个都和现有代码结构衔接顺畅：第一是接入真实在线支付和物流服务。系统现在已经预留了支付渠道字段和物流单号字段，接第三方渠道只是补一个实现类的事，不用改流程。第二是升级推荐算法，现阶段的画像是标签矩阵+加权得分，可以平滑替换为基于协同过滤或者简单的内容向量的实时通道，再对两个通道的结果做加权融合。第三是做营养报告的可视化分析，目前后台已经有用户营养摄入趋势统计数据，可以继续接ECharts展示每周蛋白质、脂肪、碳水的变化，这个功能在答辩演示时视觉效果会很好。其实毕设项目做完之后，我最大的感受是：这套系统并不算复杂，但每个模块的设计都是围绕“这个业务为什么需要这个功能”去展开的，所以不管是写代码、调算法参数还是准备答辩，思路一直很顺。最后再分享一个经验：动手写代码之前，先把业务边界和推荐流程在纸上画清楚，数据库表和接口文档一起设计，后端的效率会翻倍；别一上来就写Controller，等你写完了一看，发现核心逻辑全堆在Controller里，那就真的返工了。
做计算机毕业设计，选一个既能覆盖业务复杂度、又能体现技术栈掌握程度、还得有故事可讲的题目，真的比写代码本身更费脑子。我当时定下这个“基于SpringBoot的营养预制菜个性化定制平台”之前，其实也纠结过好几个方向，最后之所以敲定这个，是因为它本质上是一个“膳食半成品智能推荐与订购系统”，也就是在Java Web架构下做一个健康速食个性化搭配服务平台，既有传统电商的订单闭环，又有推荐系统可以深挖，还有健康营养这个当下热度很高的业务场景可以包装。这篇博文就把我这套系统从选题、建模、编码到答辩的完整思考过程写出来，如果你也在做类似毕业设计，或者刚入门想做一套能拿得出手的Java Web项目，可以直接参考我的设计思路和代码片段。先说一个很现实的点：毕设项目最怕的不是功能少，而是“没有逻辑”。CRUD谁都会写，但为什么这样建表、为什么这样设计接口、推荐算法为什么不直接套一个深度学习模型，这些问题才是答辩时老师真正关心的。我这篇文章会尽量把每个关键决策背后的理由都讲清楚，而不是给你一堆能跑但解释不了的代码。1. 为什么选这个题目：预制菜赛道下的真实需求拆解1.1 从“今天吃什么”到平台价值如果你每天中午打开外卖软件，发现翻了二十分钟还不知道点什么，你就知道“膳食半成品个性化定制”这个需求有多真实了。半成品预制菜这两年已经渗透进普通家庭的冰箱，但用户面临的问题是：菜品种类多、营养信息不透明、搭配全靠感觉。所以这个平台的核心价值不是卖货，而是替用户做“吃什么”的决策。我把这个问题拆成三层：第一层是“食材与菜品匹配”，用户输入自己的忌口、目标热量、偏好口味，系统帮他过滤出合适的半成品；第二层是“组合搭配”，单买一包酸菜鱼不算健康餐，系统应该能推荐“酸菜鱼 + 杂粮饭 + 白灼时蔬”这种组合；第三层是“持续追踪”，用户这周吃了几次高油高盐菜品、蛋白质摄入够不够，需要平台用数据告诉他。这三点就是我整个毕设的顶层需求，后面所有的表设计、推荐逻辑、页面交互都是围绕它们展开的。一个能落地的系统，必须有这种递进式的价值逻辑，不然就是一个普通的商城壳子。1.2 目标用户与业务边界我不建议在毕设里把用户角色设计得过于复杂。这个平台我只做了三类角色：普通用户、营养师、管理员。普通用户负责浏览、定制、下单、查看营养报告；营养师可以维护菜品库和营养标签，相当于内容运营；管理员管用户状态、订单状态、基础数据字典。单看角色数量，这个设计中规中矩，但业务边界很清晰——所有核心功能都围绕“个性化推荐”和“半成品订购”两条主线。我没有去做社区、评论、积分商城这些容易让项目失去焦点的功能。整个系统的业务闭环是：用户完善偏好画像 → 平台推荐菜品/套餐 → 用户调整定制内容 → 生成订单 → 支付模拟 → 订单状态流转 → 营养数据回写画像。这个闭环的每一环都能在答辩时讲出设计意图，而且每一环都对应一个具体的数据表或算法逻辑，这就是我要的效果。1.3 功能清单：没必要一次性做全毕设有半年时间，但你不能真的按商业产品去做。我列功能清单时的原则是：核心链路必须完整，边缘功能可以忍痛放弃。最终确定的功能包括：用户注册登录、偏好画像维护、菜品/套餐浏览、基于标签和画像的智能推荐、个性化定制（替换配菜、调整分量）、购物车、订单提交与状态跟踪、营养报告统计、后台菜品管理和订单管理、营养师对菜品标签的审核维护。被砍掉的功能有：优惠券、秒杀、实时物流追踪、在线支付对接。这些功能要么需要外部接口，要么对答辩加分有限。支付我用了模拟支付开关处理，物流只更新状态点，不接第三方API，因为真实支付和物流接口的审核流程会占用大量时间，而且出了问题很难在演示现场兜底。2. 技术选型：SpringBoot 3 + MyBatis-Plus + Vue3 的取舍逻辑2.1 后端为什么是SpringBoot 3.x标题里已经写死了SpringBoot，这个没有太多悬念。但我要说的是选SpringBoot 3.x而不是2.x的理由。SpringBoot 3.x 基于Jakarta EE 9规范，默认内置了GraalVM原生镜像支持的方向，更重要的是它强制要求Java 17以上版本。用新版本的好处是，答辩时你可以主动说“我使用的是SpringBoot 3.1，Java 17的虚拟线程在某些IO场景下有优化尝试”，这个话术比“我用了SpringBoot 2.7”听上去更有技术敏感度。实际开发中，SpringBoot 3.x对日常CRUD、事务管理、参数校验这些操作和2.x差别不大，甚至大部分代码可以直接平移。真正需要注意的是一些第三方starter的兼容性，比如某些旧版分页插件、代码生成器可能不支持SpringBoot 3.0，我后面会在防坑部分专门讲。不过我不建议纯粹为了“新版”去用新版本，一个稳定跑通的2.7项目，比一个到处报依赖冲突的3.1项目更适合毕业答辩。我当时选择3.x是因为前期调研发现主流starter基本都完成了适配，风险可控，而且这样可以在简历里写“熟悉SpringBoot 3.x生态”。2.2 ORM：MyBatis-Plus还是JPA这是很多同学纠结的地方。我的答案是MyBatis-Plus，原因是这个项目的查询场景非常碎片化，尤其是推荐模块需要频繁按动态条件组合查询菜品标签、热度、库存，而MyBatis-Plus的LambdaQueryWrapper能够非常方便地拼接条件，不用写大量@Query注解或者XML。举个例子：推荐接口要根据用户画像筛选“口味偏辣+高蛋白+价格低于30元”的菜品。在JPA里这可能要写一个方法名很长的派生查询，或者JPQL字符串；用MyBatis-Plus就是三行代码的事。另外一个隐藏优势是MyBatis-Plus的代码生成器，能根据表结构快速生成实体、Mapper、ServiceImpl，虽然毕设要自己写核心逻辑，但那些重复性的CURD（增删改查）代码交给生成器能省出一周时间，这部分时间拿来研究推荐算法不香吗。当然，JPA也不是一无是处。如果你的系统实体关系极其复杂，嵌套层级很深，JPA的级联操作确实省事。但像这种电商属性较强的系统，我还是更倾向于控制SQL的可预测性，用MyBatis-Plus加少量自定义XML最稳。2.3 前端：Vue3还是服务端模板考虑到毕设的时间成本，我选了前后端分离，前端Vue3 + Element Plus，后端纯RESTful接口。前端用Vite搭建，Axios统一封装请求，状态管理直接用Pinia。为什么不上服务端模板？因为模板渲染的方案（比如Thymeleaf）虽然开发快，但有两个问题：一是页面交互复杂时，AJAX片段更新会让代码非常混乱；二是答辩时如果老师问“你的系统前后端怎么分离的”，你会很难讲清楚。相反，前后端分离项目能展示的知识点更丰富：跨域处理、JWT存储与刷新、接口统一响应结构、Vue路由守卫。这些都是Java Web岗位面试真会问的东西。但前提是你得把前端工程控制在一个能维护的复杂度内，我自己的经验是：页面数量控制在15到20个以内，组件复用优先，不要过度封装，否则调样式的时间比写后端还多。2.4 缓存：Redis在这里不是必须但很加分我确实在菜品热榜、推荐结果缓存、验证码存储三个场景用了Redis。你可以说它是“可替换的”——因为纯用MySQL也能实现这些功能，但加入Redis之后，整个系统的层次感就出来了。比如首页的“本周热销半成品”接口，如果每次都去订单表做聚合查询，一旦数据量上来响应就会变慢，而缓存10分钟一次热榜数据，性能是肉眼可见的。Redis在毕设里的另一个好处是能展示“缓存穿透/缓存雪崩”的防护思路。我用了空值缓存加随机过期时间，虽然系统量级很小，但这个设计思路在答辩时非常加分。你甚至可以主动说“虽然目前没有并发压力，但我预留了缓存防穿透处理”，老师一听就知道你不是只写了一堆CRUD。基础设施选型上说一句题外话：MySQL版本我选了8.0，因为json字段类型、窗口函数这些特性很实用。比如统计用户蛋白质摄入趋势，用窗口函数可以在数据库层解决，而不是捞到Java内存里慢慢算。3. 数据库设计：先聊订单结构，再说推荐表3.1 主表结构：用户、菜品、食材与标签这个平台的主表并不复杂，核心是用户表、菜品表（预制菜表）、食材表、标签表、用户偏好画像表。这里我重点说一下菜品表的设计，因为它是整个推荐和推荐逻辑的基石。t_dish（菜品/半成品表）我设计了如下字段：dish_id、dish_name、main_category（属于哪条产品线）、price、stock、calories_per_100g、protein、fat、carbohydrate、sodium、spicy_level、cooking_time_minutes、status、sale_count、create_time。注意，我把六大营养素核心指标做成了冗余字段直接存在菜品表里，而不是单独建一张营养明细表。这样做确实不够范式化，但对于这个系统来说，推荐算法需要快速读取营养指标，多表联查会把性能拖垮，而且营养数据本身是相对静态的，冗余的代价可控。标签表存的是“低脂”“高蛋白”“适合减脂”“重辣”“儿童友好”这类业务标签，菜品和标签之间是多对多关系。你一定会上演一个经典操作：用中间表把菜品和标签关联起来，推荐时通过标签匹配做召回。3.2 订单与订单项：半成品的特殊性订单表的设计和普通电商基本一致：order_id、user_id、total_price、status、address_snapshot、pay_type、create_time。订单项表里我多加了一个字段叫meal_plan_id，用来关联“用户定制的套餐组合”。为什么强调这个字段？因为普通购物车订单只需要记录“买了哪道菜、数量多少”，但这个平台的订单项可能是“用户把一份单人餐里的酸菜鱼换成了水煮牛肉，主食从米饭换成杂粮饭”。这种动态搭配如果不用定制方案相关的字段接住，后面的营养报告和推荐画像就没法追溯。我的方案是设计一个custom_spec字段，用JSON记录当前菜品的替换明细，快照式保存到订单项里，避免之后菜品表修改导致历史订单对不上。订单状态我用一个整数字段表示：0待支付、1已支付待处理、2备货中、3已配送、4已完成、5已取消。每个状态迁移都会写入一张t_order_log操作日志表。这个日志表在答辩演示时会成为你的“表演点”——随便点几下订单流程，日志记录一条条蹦出来，系统“活了”。3.3 推荐相关表：记录画像来源推荐系统最怕的是“不知道为什么推荐了这个”。所以我在数据库里设计了用户偏好标签表（user_preference）、用户行为记录表（user_behavior_log）、推荐结果记录表（recommend_record）。user_preference不仅存“用户喜欢什么”，还存“来源类型”：是用户主动勾选的，还是从历史订单里算出来的。这个细节帮助你复盘推荐效果，也能让推荐代码分工清晰。user_behavior_log记录浏览、收藏、点击推荐等行为，字段有behavior_type、target_id、detail_json、create_time，这个表是推荐离线计算的核心数据源。recommend_record表在推荐接口执行时写入，记录为用户推荐了哪些菜品、召回候选集多大、最终展示排序如何。有了它，答辩时被问“推荐结果可解释性”就非常稳，你可以直接查库找出一条记录，说明这条推荐来自哪几个标签的加权计算。3.4 一段可用的建表SQL为了不让设计只停留在概念上，这里放两个我用到的关键建表语句。菜品表精简版如下：CREATE TABLE t_dish ( dish_id BIGINT PRIMARY KEY AUTO_INCREMENT, dish_name VARCHAR(64) NOT NULL, main_category VARCHAR(32) NOT NULL, price DECIMAL(8,2) NOT NULL, stock INT NOT NULL DEFAULT 0, calories_per_100g INT NOT NULL, protein DECIMAL(5,1) NOT NULL, fat DECIMAL(5,1) NOT NULL, carbohydrate DECIMAL(5,1) NOT NULL, sodium INT, spicy_level INT DEFAULT 0 COMMENT '0不辣 1微辣 2中辣 3重辣', cooking_time_minutes INT, status TINYINT DEFAULT 1, sale_count INT DEFAULT 0, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_category (main_category), KEY idx_sale (sale_count) );用户偏好标签表如下：CREATE TABLE user_tag_preference ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id BIGINT NOT NULL, tag_id BIGINT NOT NULL, weight DECIMAL(5,2) NOT NULL DEFAULT 1.00 COMMENT '标签权重', source_type VARCHAR(20) NOT NULL COMMENT 'INIT/ORDER/BEHAVIOR', source_data VARCHAR(128), update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_user_tag (user_id, tag_id) );说明一下weight字段，它是整个推荐算法的“旋钮”，用户主动选择的标签权重高，行为积累的标签权重会随次数递增，后台运营可以通过调整基础权重来干预推荐倾向，这就是可解释的推荐依据，而不是黑盒。4. 推荐引擎不是玄学：标签召回与加权排序的实现细节4.1 冷启动：没有历史数据怎么召回推荐模块最先遇到的问题就是冷启动。新用户注册进来后没有任何行为数据，这时候如果推荐算法直接根据行为记录来算，结果就是空集。我的方案是：引导用户在注册流程里完成一个“饮食偏好问卷”，选项包括口味、忌口、目标（减脂/增肌/维持体重）、每餐预算，然后把这些选项映射为标签，写进user_tag_preference表，source_type标记为INIT。有一说一，冷启动效果的天花板取决于标签映射表的丰富度。比如问卷里选“减脂目标”，系统就要清楚地把“低脂”“高蛋白”“低卡”这三个标签打上位。我预留了一个配置表tag_rule_config，专门做这种规则映射，维护好这个表，冷启动召回就不会出大错。这个阶段召回用的是经典标签匹配：计算用户标签集合和每个菜品标签集合的Jaccard相似度，把相似度大于阈值（我定为0.3）的菜品作为候选集。虽然是老方法，但好在逻辑透明、效果稳定、代码量小，作为毕设完全够用。4.2 画像更新：从订单和收藏中学习用户用了几天系统之后，画像就不能停留在问卷答案了。我在订单完成事件和用户收藏事件里都埋了画像更新逻辑。核心思路很朴素：用户完成一笔订单，包含的菜品标签就计数加一；用户把某个菜品加入收藏夹或者反复浏览三次以上，同样给标签加分。这里需要做的就是权重归一化，防止热门标签无限涨分。我用的方法是加滞衰减：更新时间越久，历史贡献权重越低。具体公式是：标签权重 = 历史权重 * 0.9 ^ (距离上次更新的天数) + 本次增量。这个参数调参很简单，0.9是我们模拟数据下效果最平滑的值，你可以根据自己的测试调整。关键点在于，画像更新必须和推荐逻辑解耦。我没有在推荐接口里更新画像，而是通过Spring事件机制，在订单状态变成“已完成”时发布一个事件，监听器异步去更新标签权重。这样即使画像计算慢一点，也不影响用户下单主链路。4.3 打分排序：营养搭配公式召回到候选集之后，下一步是打分排序。打分公式是我自己设计的，综合考虑营养匹配度、价格、热度、库存四个因素：score = 0.45 * nutrition_match + 0.25 * user_tag_match + 0.2 * popularity + 0.1 * price_penalty先看nutrition_match，它衡量半成品与用户目标的匹配程度。举个例子，用户目标是减脂，那么低热量、高蛋白、低脂肪的菜品得分高。部分匹配计算方式为：/** * 减脂目标下，蛋白占比越高分越高，热量与脂肪越低分越高 */ public double computeNutritionMatch(Dish dish, UserGoal goal) { if (goal == UserGoal.FAT_LOSS) { double proteinScore = Math.min(dish.getProtein() / 20.0, 1.2); double calorieScore = 1.0 - Math.abs(dish.getCaloriesPer100g() - 180) / 180.0; double fatScore = 1.0 - dish.getFat() / 15.0; return Math.max(0, proteinScore * 0.5 + calorieScore * 0.3 + fatScore * 0.2); } // 其他目标类似，每个目标的参考指标从配置中心读取 return 0.5; }这里只是一个简化版本，但不能直接用固定值去卡，因为每个人的基础代谢和训练频率不一样。所以我从用户表里读取了goal配置，之后把目标参数化存储在hash map里。具体实践时，你可以把这组权重放到配置表里，随时调整，这不是算法炫技，但体现的是一个“平台”的系统思维。4.4 一个可落地的“召回-过滤-排序”流程推荐接口实际执行的流程是：读取用户标签 → 构建菜品候选集（排除下架、库存为0）→ 用规则过滤掉用户明确不吃的食材（比如用户偏好表里有“过敏原-花生”，候选集里的花生类菜品全部删除） → 计算得分排序 → 返回Top10 → 写入recommend_record表。排序之后的推荐不再直接展示，我还会加一个“重排”逻辑：连续给用户推同品类菜品不好看，所以同类菜品最多出现两个，保证推荐列表的多样性。这个逻辑很简单，但是用户体感提升非常明显，很多现成的推荐系统都会做多路召回与多样性打散，你在答辩时多提这个细节会让老师对你刮目相看。代码结构上，我把推荐分成了三个独立接口：RecommendService负责召回与排序，TagProfileService负责画像管理，RuleFilterService负责硬性过滤。三者之间不互相调用重逻辑，方便后来扩展新的推荐策略，比如你想做基于协同过滤的接口，只需要新增一个CallaborativeRecommendService实现同一个接口即可。5. 个性化定制与下单链路：前后端配合最容易漏掉的校验5.1 定制流程：四步交互与后端校验点定制页面我设计了四个步骤：选择套餐原型 → 调整配菜/主菜 → 确认营养指标预览 → 加入购物车或直接下单。这种引导式的交互，比用户自由搭配的体验更友好，因为完全自由搭配容易让用户选择困难，原型套餐则给了用户一个起点。这里最容易漏掉的后端校验点是“替换约束”：不是随便哪道菜都能互相替换。比如用户想把套餐里的汤品换成甜点，但是甜点的制作时间更长，可能与出餐时间冲突，系统需要给出提示。我在菜品表里加了一个replace_group字段，只有处在同一替换组的菜品才允许替换。后端在提交定制配置时，必须校验替换前后是否属于同一个replace_group以及分量是否匹配（大份/小份不能混换）。后端校验链我放在定制接口的service层，没有用分散的前端校验。因为前端校验再完善，恶意请求依然可以绕过，而且集中式校验方便单测覆盖。每一次校验失败都会返回统一的Result对象，里面带一个errorCode和前端提示文案，前端根据errorCode展示对应的弹窗提示。5.2 价格计算与库存扣减定制之后，价格需要实时重新计算。我的算价策略并不复杂：套餐原型有一个基础价，替换菜品时用“替换差价”来完成加减。举例来说，套餐E的原价是29.9元，用户把默认的鸡胸肉换成三文鱼，差价是+8元，最后定制价就是37.9元。这里需要注意精度问题，金额类型必须用BigDecimal而不是double，经典面试考点，同时也能避免数据库小数精度陷阱。我在前端展示价格时也会统一保留两位小数，防止出现“37.9000000001”这种尴尬画面。库存扣减我选择了“下单预占、支付确认、超时释放”的流程。订单提交时将所涉菜品的库存做原子扣减，如果任何一道菜库存不足，整个订单直接失败，并把之前已经扣减成功的库存回补。这里一定要在事务里操作，回补是自动的，否则并发情况下容易出现库存超卖。虽然毕设没有高并发环境，但订单一致性的代码逻辑写对了，老师问起来你就能说得头头是道。5.3 订单的防重与状态流转给订单做幂等是个很值得写的点。用户在前端快速点击两次“提交订单”，如果后端没有防重逻辑，就会产生两笔相同订单。我的做法是前端生成一个requestNo传给后端，后端把request_no作为唯一索引存进订单表，提交时一旦插入冲突就回滚，并返回“订单正在提交或已提交”。很多同学会在这一环节纠结“分布式锁”，其实不是必要。对于单机部署的毕业设计来说，唯一索引+事务是最简单最有力的方案。你可以在答辩时说清楚：如果未来需要拆分为微服务或提升并发，会引入Redis分布式锁来标记请求状态，但现在的数据一致性完全由数据库保证。订单状态流转我不建议做太灵活，否则每个状态都有一段不可控的代码逻辑。我的做法是定义一个状态机类，集中管理状态迁移规则。比如“待支付”只能走到“已取消”或“已支付待处理”，“已完成”之前必须经历“备货中”和“已配送”，任何非法状态迁移直接抛异常，从代码层面杜绝脏数据。5.4 关键Controller示例为了更直观，这里摘一段提交订单的Controller代码，注意接口的职责切分和参数校验：@RestController @RequestMapping("/api/order") public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService = orderService; } @PostMapping("/submit") public Result<Long> submit(@RequestBody @Valid OrderSubmitRequest request) { Long orderId = orderService.submitOrder(request); return Result.success(orderId); } }你可能觉得这段代码太简单了，但这就是正确职责切分该有的样子。Controller只负责接收请求和初步校验，事务、库存扣减、状态机逻辑全部下沉到OrderService，将来无论怎么改页面，后端逻辑都能稳定复用。我在OrderSubmitRequest里用了Hibernate Validator的注解，比如@NotNull、@Min(value = 1)，这些是SpringBoot集成非常好的一个点，能写进技术方案中。6. 毕业设计防坑指南：从本地开发到答辩演示6.1 本机部署的几个实测坑每个项目都免不了踩环境坑。我先把SpringBoot 3.x最大的坑放在前面：很多第三方starter还在用javax.*包，而SpringBoot 3.x选择了jakarta.*包。如果项目里意外引入了旧依赖，启动时就会报ClassNotFoundException或者NoSuchMethodError。解决思路很简单：尽量用官方starter和已经适配SpringBoot 3的版本（比如MyBatis-Plus版本至少3.5.3.1以上）。我当时就是被某个小工具库卡了整整一个晚上，最后发现只是一个旧版本依赖没升级。Redis这一环也需要提醒，Windows本地用的Redis版本和项目配置必须一致。如果你使用自带的配置，默认端口6379和密码为空，那么代码里不要多余配置密码字段，否则启动时认证失败；生产环境则建议设置密码，并用环境变量注入。至于连接池，SpringBoot默认自带Lettuce连接池，不需要额外引入，别画蛇添足。数据库连接串里需要开启useSSL=false，因为本地MySQL一般没配证书，如果不关闭SSL，启动经常会报警告甚至连接失败。还有时区的坑，连接串后面加上serverTimezone=Asia/Shanghai，不然时间字段会比实际少8小时，你查订单时间会觉得系统“穿越了”。6.2 演示数据要“看起来像真数据”毕业答辩演示最尴尬的瞬间是什么？是老师凑过来看屏幕，发现用户列表里只有“user1”“user2”，菜品只有“菜A”“菜B”。要让系统显得扎实，演示数据必须足够真实和丰富。我花了大概一个晚上造数据：用户用中文姓名加常见手机号，菜品名像“孜然鸡胸肉健身餐”“泰式酸辣魔芋结”“番茄牛腩低卡套餐”，营养数据按真实食物大致填，订单时间分布在最近两周，状态覆盖从待支付到已完成完整链路，用户收藏和浏览记录也导了一百多条。这些数据能让推荐算法跑起来，也能让订单统计图表有故事可讲。造数据的另一个作用是验证推荐效果。如果发现某个标签权重的用户推荐出来的菜品完全不合理，就要回头调整打分公式的阈参数。这个调试过程本身就是很好的答辩素材，你可以展示“为了让减脂用户优先看到高蛋白低卡产品，我对营养匹配部分的权重做了调整，最终观察推荐列表分布趋于合理”。6.3 答辩高频问题与回答框架根据我自己的答辩体验，老师对毕设的提问一般集中在三块：技术选择的合理性、业务设计的完整性、项目中的难点亮点。第一个问题往往是“为什么选这个技术栈？”回答框架是：面向场景、对比分析、总结取舍。比如SpringBoot是因为自动配置够快、生态完整；MyBatis-Plus是为了动态条件查询；Vue3是为了组件化交互。不要背官方定义，你只要说明这几个技术组合在这个业务场景里的适配性就够了。第二个问题是“推荐系统怎么实现的？”回答框架是：分模块、按流程、强调可解释性。我通常从冷启动开始讲，说明标签召回，然后讲用户画像更新，最后讲加权排序和多样性打散。主动说出“推荐结果表记录可回溯”，老师就明白你不是随手写个排序。第三个问题是“订单并发下库存怎么控制？”问这个概率极高。回答框架是：事务内先扣库存、失败回滚、落库唯一约束。如果你能顺手画出状态机的流转逻辑，这个问题基本就稳了。被问到不会的问题也别慌，坦诚说目前系统的设计边界在哪里，以及你计划的改进路径是什么，这个态度比背答案更能拿到分。6.4 还能往哪些方向扩展虽然毕设不需要真的做到上线，但你可以在结尾给老师展示“这个系统的未来”会更有竞争力。我总结过几个自然的扩展方向，每个都和现有代码结构衔接顺畅：第一是接入真实在线支付和物流服务。系统现在已经预留了支付渠道字段和物流单号字段，接第三方渠道只是补一个实现类的事，不用改流程。第二是升级推荐算法，现阶段的画像是标签矩阵+加权得分，可以平滑替换为基于协同过滤或者简单的内容向量的实时通道，再对两个通道的结果做加权融合。第三是做营养报告的可视化分析，目前后台已经有用户营养摄入趋势统计数据，可以继续接ECharts展示每周蛋白质、脂肪、碳水的变化，这个功能在答辩演示时视觉效果会很好。其实毕设项目做完之后，我最大的感受是：这套系统并不算复杂，但每个模块的设计都是围绕“这个业务为什么需要这个功能”去展开的，所以不管是写代码、调算法参数还是准备答辩，思路一直很顺。最后再分享一个经验：动手写代码之前，先把业务边界和推荐流程在纸上画清楚，数据库表和接口文档一起设计，后端的效率会翻倍；别一上来就写Controller，等你写完了一看，发现核心逻辑全堆在Controller里，那就真的返工了。