老实说，每年毕设季被问得最多的问题就两个："什么题目好过？"和"什么题目能拿高分？"。膳食营养健康网站平台这个方向，属于那种"看起来不起眼、做起来真香"的题目——业务场景贴近生活，评讲需求时谁都能听懂；技术面又足够典型：SpringBoot做后端、Vue做前端、MySQL做存储，一套标准的前后端分离架构，既撑得起论文的架构设计章节，又踩中了当前就业市场的主流技术栈。这篇文章我从选题、功能拆解、数据库设计、前后端核心实现、部署文档一直讲到论文和答辩准备，完整还原一套可参考的毕业设计项目是怎么从零搭起来的。如果你已经拿到了一套源码但不知道怎么梳理，或者打算自己动手写一个，这份拆解可以直接当路线图用。
1. 选题动机与功能拆解：膳食营养平台到底在做什么
1.1 为什么这个题目"好做又有东西写"
从毕设评审的角度看，一个题目"好"，通常要满足三个条件：需求来源真实、技术实现有纵深、工作量容易被看见。膳食营养健康平台恰好三个都占。
先说需求真实。现代人在"吃"这件事上有两个典型痛点：一是不知道今天吃了多少热量、营养是不是均衡；二是想吃得健康却缺乏可执行的参考方案。一个能看食谱、算热量、记录三餐、生成营养报告的平台，放在任何答辩场景里讲，评委都能一秒理解它的价值，这比那些凭空造的"XX管理系统"好讲太多了。
再说技术空间。这个题目不是表面上的增删改查，它后端要处理营养计算逻辑，比如基础代谢率（BMR）、每日能量总消耗（TDEE）、按日期聚合用户三餐的营养摄入量；前端要处理带筛选条件的列表、表单校验、数据可视化；数据库更是天然的多表关联——用户、食材、食谱、饮食记录、健康档案、收藏、评论，表与表之间的业务关系非常清晰。这些内容恰好是毕业设计评分表里权重最高的几个维度。
最后是工作量显性。功能一拆就是七八个模块，页面一做就是十几个，论文素材多得写不完。相比之下，有的题目看着高大上，但核心功能两三个界面就讲完了，论文憋不出字数，答辩几下就被问穿。
1.2 核心功能模块：用户、饮食、营养三条主线
我把这套系统的功能拆成三条主线：用户线、饮食线、营养线。顺着这三条线，整个系统的脉络就清楚了。
- 用户线：注册登录、个人信息维护、健康档案（性别、年龄、身高、体重、活动水平、健康目标）、密码修改与找回。
- 饮食线：食谱浏览与多条件检索（按分类、按热量区间、按食材）、食材库查看、食谱详情（用料、步骤、营养分析）、三餐饮食打卡（把吃过的食谱记入当天记录）、食谱收藏、评论。
- 营养线：基于健康档案计算BMI与基础代谢，给出每日热量与营养素建议；对用户的饮食记录做按日聚合，展示当天实际摄入的热量、蛋白质、脂肪、碳水化合物，并与建议值做对比。
管理员端则是另外一条线：用户管理、食材管理、食谱管理，以及一些基础数据维护功能。每个模块都不复杂，但合在一起，用户可以从"了解自己"到"吃得健康"形成一条完整的使用路径，这是这个题目在演示环节最能打动评委的地方。
1.3 功能与评分点的对应关系
在写开题报告或者做需求分析的时候，可以先把"功能"和"答辩评分点"做一张映射表，这样后期写论文、做PPT都会轻松很多。
| 功能模块 | 演示效果 | 论文中的对应材料 |
|---|---|---|
| 用户注册登录+JWT鉴权 | 未登录无法访问个人页面和打卡功能 | 安全设计、接口权限控制 |
| 健康档案+BMR/TDEE计算 | 输入身高体重后即时算出代谢值 | 核心算法设计、公式推导 |
| 食谱检索+分页 | 按分类和热量区间筛选 | 查询优化、数据库索引设计 |
| 三餐打卡+营养聚合 | 日历上选定日期，显示当天营养总量 | 多表联查SQL、聚合函数应用 |
| 收藏+评论 | 社交互动数据实时展示 | 关联查询、事务一致性 |
| 后台管理 | 管理员对食谱和用户做审核管理 | 权限设计、RBAC模型 |
我第一次带学弟做这个题目时，就让他先画这张表，后面整个项目基本没跑偏过——毕设最容易犯的错，是功能做了一大堆，但每个功能对应不上论文里的章节，最后答辩只能干巴巴地演示页面。
2. 技术栈选型的三个理由：为什么偏偏是这套组合
2.1 SpringBoot：把后端开发成本压到最低
SpringBoot在这个项目里的作用是"一个能快速启动、易上手、且符合行业主流"的后端框架。它对Spring生态做了大量自动配置，省掉了以前SSM时代繁琐的XML配置；内嵌了Tomcat，打出一个jar包就能跑；加上Spring Data JPA或MyBatis的配合，CRUD接口一个注解就能搞定。
从毕设角度选它还有一个现实因素：市场上关于SpringBoot的学习资料、博客、开源项目数量极大，遇到问题搜索一下通常三分钟内能定位。这对毕设周期紧、又不一定有个大牛随时答疑的同学来说，实在太重要了。我见过不少用冷门框架做毕设翻车的案例，不是框架不行，是出bug根本找不到人问。
2.2 Vue + 前后端分离：演示效果好，开发也顺手
Vue作为前端框架，最直观的优势是组件化和响应式。页面拆成组件后，导航栏、食谱卡片、营养统计面板都能复用，开发效率高；数据驱动视图，用户改了健康档案，页面上的BMI和代谢值立刻联动刷新，这种交互体验在答辩演示时非常加分。
更重要的是"前后端分离"这个架构本身。前端工程和后端工程可以并行开发，接口用JSON对接，部署时可以分开部署，也可以把前端打包产物塞进后端静态目录。在后端接口设计章节，可以理直气壮地写"遵循RESTful风格，前端通过Axios调用后端API"——这句看似简单的话，其实是当前企业级开发的主流模式，写在论文里就是行业前沿性的体现。
2.3 MySQL：做有强关联业务数据的可靠选择
MySQL在这个项目里的角色，是存储所有业务数据和用户行为数据。选它而不是NoSQL，核心原因是这个系统的数据模型是强关联的：一份食谱要关联若干食材，一条饮食记录要关联一个用户和一份食谱，一次营养聚合要join三张表。关系型数据库的ACID事务能保证收藏、评论、打卡这些操作的数据一致性，而且MySQL支持丰富的聚合查询和窗口函数，营养统计可以一条SQL写出来。
至于版本，MySQL 5.7和8.0都可以。8.0对窗口函数、JSON支持更好，但5.7更保守稳定。我一个实际建议：如果用的是MySQL 8.0，注意驱动要配成com.mysql.cj.jdbc.Driver，URL里加上serverTimezone=Asia/Shanghai，这两个小点能省掉一半的连库报错。
2.4 为什么不选别的方案
很多同学会纠结"要不要用SpringCloud""要不要引入Redis"。我的看法很明确：毕设的第一原则是"能稳定跑完，且你自己能讲清楚"。SpringCloud那套微服务治理在这个项目规模下纯属过度设计，Redis缓存加进去如果讲不明白淘汰策略和缓存一致性，答辩反而是扣分项。
同样的道理，用SSM（Spring+SpringMVC+MyBatis）太老，面试官会觉得技术栈停留在五年前；用Python的Django/Flask虽然开发快，但偏离了国内Java岗位的主流体系。SpringBoot+Vue+MySQL这个组合，是"易实现、好讲解、有前景"三者兼得的最优解。
3. 数据库设计：从食物数据到用户行为的完整建模
3.1 核心表设计一览
数据库是整个项目的地基，地基歪了，后面代码写得再好也白搭。我按业务主线设计出以下核心表，分别对应食材、食谱、用户行为、健康数据四类。
| 表名 | 核心字段 | 作用 |
|---|---|---|
| user | id, username, password, nickname, email, phone, avatar, status | 用户基础信息，status控制封禁状态 |
| food | id, name, category, calories, protein, fat, carbohydrate, unit | 食材营养数据，注意是"每100克"口径 |
| recipe | id, name, category, cover_url, steps, description, status, create_by | 食谱基本信息，category区分早/午/晚餐与加餐 |
| recipe_food | id, recipe_id, food_id, quantity | 食谱与食材的多对多关联，quantity单位是克 |
| diet_record | id, user_id, recipe_id, meal_type, record_date, quantity | 用户的三餐打卡记录，quantity是份数 |
| health_profile | id, user_id, gender, age, height, weight, activity_level, goal | 健康档案，活动水平和目标是营养建议的依据 |
| favorite | id, user_id, recipe_id, create_time | 收藏关系表 |
| comment | id, user_id, recipe_id, content, create_time | 评论表 |
这九张表基本构成了系统的完整骨架。设计时有一个关键意识：表要拆开、但要能join回来。比如"食谱和食材"如果图省事塞进同一个字段，那营养计算就写不出干净的SQL了。
3.2 字段类型与口径：细节里全是坑
字段设计看似简单，实际坑不少。我挑几个最容易出问题的地方说。
第一，涉及营养数值的字段，一律用decimal(8,2)，不要用float或double。热量、蛋白质、脂肪这些数据在聚合求和时，浮点类型会产生精度误差，比如0.1+0.2不等于0.3这种经典问题。用decimal加上定长小数位，统计结果才稳定。
第二，营养数据的存储口径要统一。food表里的热量和营养素统一按"每100克"存，食谱用量通过recipe_food关联表用克数表示。这样一份食谱的总热量可以这样算：把关联食材的营养值乘以实际用量再除以100，全部求和。口径统一了，后面写聚合SQL才不会乱。
第三，时间字段用datetime，创建时间统一加DEFAULT CURRENT_TIMESTAMP。饮食记录用record_date存日期，建议用date类型，这样按天分组查询直接GROUP BY record_date，不需要做字符串转换。
3.3 外键、索引与数据安全
关于外键：数据库物理外键我建议不建，而是在业务层维护关联关系。理由很实际：物理外键会让表之间的耦合变强，删除食材时如果正被食谱引用，外键约束会直接抛错阻断操作，这对后台管理体验很不友好。业务层外键配合逻辑判断，效果一样，但灵活得多。论文里可以写一句"通过应用层维护数据完整性"，这也是现代系统设计的主流做法。
索引方面，三个地方必须建索引：user.username（登录查询）、diet_record(user_id, record_date)（个人饮食记录按日期查）、recipe.category（分类筛选）。高并发场景下索引策略很复杂，但毕设场景下的这些高频查询，加索引就是一句话的优化，SQL执行效率差异在演示时可能看不出来，但写在论文的"系统优化"章节非常好用。
另外提一句密码存储，user表的password字段不允许明文。用Spring Security的BCryptPasswordEncoder做哈希，每次注册时加密存储，登录时校验。这条如果做对了，论文安全设计章节立刻有内容；做了明文存储，评委一句"安全性怎么保证"就能把你问住。
4. 后端核心模块实现思路：鉴权、营养计算与推荐
4.1 JWT鉴权：一个接口权限控制的标准答案
前后端分离架构下，传统的Session方案比较麻烦，本项目采用JWT（JSON Web Token）做身份认证，这是当前Java Web项目里最标准的做法。
流程可以这样设计：用户登录成功后，后端用用户ID和角色信息生成一个token返回给前端；前端把它存在本地（localStorage或pinia状态中），每次请求在请求头加上Authorization: Bearer <token>；后端写一个拦截器或Spring Security的OncePerRequestFilter，统一校验token有效性，并把当前登录用户的信息放入请求上下文。未登录用户访问需要权限的接口，直接返回401。
实际编码时有两个容易忽略的点。一是token要设置过期时间，我一般设24小时，搭配一个简单的"登录状态过期提示"，让前端在收到401时自动跳转登录页。二是JWT只做身份认证，不要把用户密码等敏感信息塞进token里，里面放用户ID和角色就够了。
4.2 营养计算：BMR与TDEE的核心算法
营养功能是这个系统的灵魂，也是答辩时最容易被深挖的点，必须把计算逻辑写得清清楚楚。
先算基础代谢率BMR，这里用Mifflin-St Jeor公式，这是目前临床和健身领域认可度较高的公式：
- 男性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5
- 女性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161
然后根据活动水平乘系数得到每日总消耗TDEE：
| 活动水平 | 系数 | 典型人群 |
|---|---|---|
| 久坐少动 | 1.2 | 办公室工作，几乎不运动 |
| 轻度活动 | 1.375 | 每周运动1-3次 |
| 中度活动 | 1.55 | 每周运动3-5次 |
| 高度活动 | 1.725 | 每周运动6-7次 |
| 极高强度 | 1.9 | 体力劳动者或每天训练 |
最后结合健康目标给出建议热量区间：减脂建议在TDEE基础上减300-500千卡；增肌加300-500千卡；维持期就按TDEE。蛋白质建议按体重算，减脂期取1.6-2.0克/公斤，增肌期1.2-1.6克/公斤；脂肪占总热量20%-30%；剩余热量由碳水化合物补充。
这套逻辑完整闭环，写进论文就是"核心业务算法"章节，答辩时从公式到系数到代码，层层都能讲。
4.3 三餐营养聚合：一条SQL讲清楚多表联查
用户打卡一次饮食，diet_record表里多一条记录。但用户真正关心的是"我今天总共吃了多少热量、多少蛋白质"。
这需要跨三张表做聚合：diet_recordjoinrecipe_foodjoinfood，按记录日期分组。核心SQL逻辑类似：
SELECT DATE_FORMAT(dr.record_date, '%Y-%m-%d') AS record_day, SUM(f.calories * rf.quantity * dr.quantity / 100) AS total_calories, SUM(f.protein * rf.quantity * dr.quantity / 100) AS total_protein, SUM(f.fat * rf.quantity * dr.quantity / 100) AS total_fat, SUM(f.carbohydrate * rf.quantity * dr.quantity / 100) AS total_carbs FROM diet_record dr JOIN recipe_food rf ON dr.recipe_id = rf.recipe_id JOIN food f ON rf.food_id = f.id WHERE dr.user_id = #{userId} AND dr.record_date = #{date} GROUP BY dr.record_date;rf.quantity是该食谱中某个食材的克数，dr.quantity是用户吃的份数，两者相乘再除以100，就得到实际摄入量。前端拿到结果后，和4.2计算的建议值做对比，用条形图直接展示差距，这个页面就是整个系统演示的高光时刻。
4.4 食谱推荐与通用接口规范
食谱推荐模块不需要花哨，基于业务规则做筛选就行。根据用户健康目标算出目标热量区间后，把系统里每道食谱的总热量也聚合出来，落在区间内的作为推荐结果，再按"同类中热量从小到大"排序，瘦身减脂场景下这个偏好是合理的。如果想更进一步，可以计算每道食谱的蛋白质供能比，筛掉热量不低但蛋白质占比过低的菜品——这些都写在service层里，代码结构非常清晰。
接口设计上统一走RESTful风格，例如：
POST /api/auth/register、POST /api/auth/loginGET /api/recipes?category=午餐&minCalories=300&maxCalories=600&page=1&size=10GET /api/recipes/{id}获取食谱详情POST /api/diet-records新增打卡记录GET /api/nutrition/daily?date=2025-01-01获取当天营养聚合
统一返回体建议用Result<T>封装，里面放code、message、data三个字段，前端拦截器按code判断业务成败，这样比前端裸接各种状态码干净得多。
5. 前端页面与交互方案：从信息架构到组件设计
5.1 页面信息架构与路由设计
前端工程用Vue 3 + Vue Router + Pinia + Axios这套组合。在动手写页面之前，先把路由结构定下来，整个系统的页面骨架如下：
/login、/register：登录注册/：首页，展示热门食谱和营养小知识/recipes：食谱列表，支持分类和热量区间筛选/recipes/:id：食谱详情，含食材明细、营养分析、收藏、评论/record：三餐打卡页，选择今天吃了哪些食谱/nutrition：营养报告页，展示当日热量与营养素对比/profile：健康档案编辑页，改身高体重立即重算BMI和代谢/admin/*：后台管理，用户、食材、食谱管理
路由守卫要处理权限控制：未登录用户访问/profile、/record等页面，重定向到/login，登录后再跳回来。管理后台额外校验角色字段，非管理员一律拒绝访问。
5.2 Axios封装与拦截器：一次配置省心到底
Vue项目里请求不发散，是所有前端工程的基本功。我在项目里会把Axios实例统一封装在一个request.js文件里：
import axios from 'axios' import router from '@/router' import { ElMessage } from 'element-plus' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) // 响应拦截器：统一处理业务码和过期跳转 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) } return res.data }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.message || '网络异常') return Promise.reject(error) } ) export default request这样所有页面的请求代码都用同一个request，token携带、错误提示、登录跳转都在拦截器里统一完成，业务代码里不需要重复写错误分支。代码量直接减半，而且看起来专业、有工程素养。
5.3 组件拆分：以食谱详情页为例
食谱详情页是这个项目里最复杂的前端页面，很适合用来展示组件化思维。我把页面拆成四个子组件：RecipeBasicInfo（菜名、图片、分类）、RecipeIngredientList（用料清单，数据来自recipe_food关联查询结果）、RecipeNutritionChart（营养分析，用ECharts条形图展示实际营养与建议值对比）、RecipeCommentSection（评论区，含发表评论和评论列表）。
组件拆分的好处在使用Element Plus这类组件库时格外明显——首页的食谱卡片、推荐列表里的食谱卡片、食谱详情里的推荐卡片，全部复用同一个RecipeCard组件，props传数据就行。答辩时如果评委问"谈谈项目中代码复用的实践"，这就是现成的例子。
5.4 表单校验与交互细节
表单校验是前端最容易糊弄但也最容易被点名的部分。注册表单至少校验用户名长度、密码强度、邮箱格式、两次密码是否一致；健康档案表单要校验身高体重是否在合理区间，负数或者超过300斤这种明显错误的数据不能入库。Element Plus内置的校验规则加上自定义validator，几行代码的事，但做没做，演示时一目了然。
交互反馈方面，所有按钮在请求期间要进入loading状态，防止用户重复点击提交造成重复数据；打卡成功后弹一个带营养数据的成功提示，比干巴巴的"保存成功"更有使用感。这些细节不会写进大纲，但答辩演示时拉开差距的恰恰就是这些地方。
6. 从源码到可运行：环境搭建与部署文档的坑
6.1 环境准备清单
这是一份我在实际部署中确认过的环境组合：
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 或 11 | SpringBoot 2.7.x对应的经典版本 |
| Maven | 3.6+ | 依赖管理与打包 |
| Node.js | 16.x 或 18.x | Vue 3 + Vite项目常用的Node版本 |
| MySQL | 5.7 或 8.0 | 注意驱动和时区配置 |
| IDE | IDEA 2022+ | 后端开发 |
| VS Code / WebStorm | 任意 | 前端开发 |
我特别想提醒的是Node版本。如果用了Vite 4+，Node 16以下的版本会直接报错，网上搜"vue安装及环境配置""vue安装依赖"经常看到一堆人卡在这里。另一个高频坑是npm install特别慢或者失败，可以先把镜像切到国内源，再安装依赖。
6.2 数据库初始化与后端配置
拿到源码后，先在MySQL里创建数据库，再用源码自带的SQL脚本导入表结构和初始数据：
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS diet_health DEFAULT CHARSET utf8mb4;" mysql -u root -p diet_health < diet_health.sql然后打开后端工程里的application.yml，改三处：数据库用户名密码、数据库连接URL（如果是MySQL 8.0，URL要带useSSL=false&serverTimezone=Asia/Shanghai）、服务端口（默认8080）。改完直接在IDEA里运行主类，后端启动日志出现"Tomcat started on port(s): 8080"就说明起来了。
6.3 前端启动与前后端联调
前端依赖安装完，启动开发服务器：
npm install npm run serve # 或 npm run dev，取决于工程用的Vite还是Vue CLI联调时最烦的就是跨域。开发阶段有两个简单方案：一是配置Vite的proxy，把/api开头的请求代理到http://localhost:8080；二是后端写一个CorsConfig允许所有来源。我建议用Vite proxy，生产环境更贴近真实的Nginx反代模式，论文里也能多写一句话。
6.4 生产构建两种思路
演示或者交给老师部署时，可以把前端生产构建产物集成进SpringBoot。
第一种是"前端build后放进后端静态目录"：npm run build生成dist目录，把dist里的内容复制到后端的src/main/resources/static下，再重新打包后端jar。这样只启动一个jar，访问http://localhost:8080就是完整系统，最省事。
第二种是"前后端分开部署"：前端dist让Nginx托管，Nginx把/api反向代理到SpringBoot的8080端口。这更接近企业真实部署方式，但需要多配置一台Nginx，毕设现场演示时多了一个环节，容易出岔子。如果时间紧张，我推荐第一种。
6.5 部署文档里的三个经典报错
把这些年在部署环节反复出现的报错整理一下，拿到源码如果卡住，优先查这三处。
- 数据库中文乱码：根源在库表和连接串字符集不统一。建库用utf8mb4，连接URL加
characterEncoding=utf8mb4，前端表单提交时确保页面charset也是UTF-8。 - 数据库连不上/驱动报错：八成是驱动版本和MySQL版本不匹配，或者URL忘记加
serverTimezone。MySQL 8.0的驱动必须是com.mysql.cj.jdbc.Driver。 - 端口被占用：8080被其他程序占用了，后端起不来。要么改
application.yml里的端口，要么找到占用进程释放端口。Windows上执行netstat -ano | findstr 8080，把对应PID的进程结束掉就行。
部署文档要写好，不只是给老师看的，也是给你自己答辩演练用的——现场如果demo出了问题，能照着文档快速恢复，比什么都强。
7. 毕业论文的写作组织与答辩准备
7.1 论文结构：六章走天下
毕业设计论文我建议用这套结构，安全、标准、不踩雷：
- 绪论：写背景与意义、国内外研究现状、论文组织结构。
- 相关技术介绍：SpringBoot、Vue、MySQL、前后端分离架构各自介绍，这章是凑字数的主力，但要注意不能贴大段官方文档，要写"在本项目中承担什么职责"。
- 需求分析：功能性需求（用用例图+用例描述）、非功能性需求（性能、安全、可用性）。
- 系统设计：总体架构图、功能模块划分、数据库设计（ER图+核心表结构DDL）。
- 系统实现：按模块逐项描述，每个模块配"界面截图+核心代码片段+实现思路"，代码不要全贴，贴核心片段即可。
- 系统测试：写测试环境、测试用例表、关键结果。这里用表格列测试用例比单纯写文字效果好得多。
7.2 需求分析怎么写才不空洞
很多同学的需求分析章节就是放一堆用例图然后没下文，评委看了觉得空。我建议每个核心用例都配上用例描述表，包含用例名称、参与者、前置条件、主事件流、异常事件流。举一个例子：健康档案录入这个用例，主事件流是"用户登录→填写身高体重等数据→系统计算BMI并展示→保存"，异常事件流是"数据不合法→提示错误信息→用户修正后重提"。
这样写既充实了篇幅，又让系统的逻辑变清晰。更重要的是，答辩时评委问"你这个需求是怎么分析的"，你能有理有据地讲出用户路径，而不是支支吾吾。
7.3 核心难点在论文里的呈现
答辩时评委最常问的一句是："这个项目里你觉得最难的部分是什么？"回答好了是加分项，答不好就是灾难。我建议把难点定位在营养计算模块：数据口径跨表聚合时的一致性、BMR和TDEE公式的选型与调参、多目标（减脂/增肌/维持）下热量区间的动态计算。
论文里专门用一个小节写这个模块的算法流程和代码实现，展示从公式到SQL再到前端图表呈现的完整链路。这一节写好了，整个论文的技术含金量就立住了。
7.4 答辩现场的高频问题清单
最后列一份我整理的答辩高频问题，提前准备，现场基本稳：
- 为什么选SpringBoot不选SSM？——生态、配置简化、就业主流。
- JWT和Session有什么区别？——无状态、跨域友好、分布式场景适用。
- 密码怎么存储的？——BCrypt哈希，不存明文。
- 营养数据精度问题怎么解决？——用decimal，避免浮点误差。
- 系统有哪些不足？——提前准备两个真实短板，比如"食谱推荐规则简单，后续可引入协同过滤"。
回答问题时记住一个原则：不要背定义，要结合自己的项目讲。比如问JWT，就说"我这个登录模块就是这么设计的，token里放了用户ID和角色，拦截器里校验，过期就弹回登录页"——有代码逻辑支撑的回答，评委挑不出毛病。
做毕设这套项目走下来，我自己最深的体会是：不要等到开题才想架构，也不要拿到源码就急着跑起来。先把数据库的表结构理清楚，把数据流走一遍，哪怕只是一个一个表在纸上画出来，整个项目的进度都会快很多。这套"先建模、后编码、再写文档"的顺序，应付毕业设计绰绰有余，甚至能让你在职场上第一周就被当作"靠谱的人"。手里这套源码和文档如果还没跑通，照着第二章的环境清单一步步来，跑通的那一刻，你才算是真正拥有了它。
