企业官网建设流程全解析

想把这个题目做成一套“拿得出手”的毕业设计，其实并不难。基于Spring Boot + Vue的饮食健康管理系统，属于典型的全栈前后端分离项目，技术上覆盖了后端接口、数据库设计、前端页面、数据可视化、权限校验这些常见考查点，业务上又足够贴近日常生活，讲起来不空洞，扩展起来也有空间。这篇文章我会从选题、技术选型、数据库设计、后端实现、前端联调，一直聊到论文写作和答辩准备，把我实际开发过程中认为最值得注意的地方都过一遍，尽量让你少走弯路。

这个系统主要做的事情也很清晰：用户注册登录后，可以维护自己的身高体重等基础信息，按早中晚餐记录每天吃了什么、吃了多少，系统根据食物营养数据自动计算热量摄入，再结合用户的身体指标和目标（减脂、保持、增肌）给出每日参考摄入热量。管理员可以维护食物营养库、推荐食谱，以及管理平台用户。整条链路功能完整，做出来之后无论是写论文还是做演示，都不会缺素材。

1. 项目整体设计与选题思路

1.1 这个题目为什么适合做毕业设计

先说结论：饮食健康管理系统在计算机毕业设计题目里，属于“难度合适、数据模型完整、可扩展性强”的典型选择。很多同学选题的时候容易走两个极端，一种是纯管理系统的增删改查，显得没有技术含量，答辩时被问几句业务亮点就答不上来；另一种是一上来就搞人工智能、推荐算法、大模型，听起来很唬人，但以毕设周期和自身基础很难真正落地，最后往往是演示效果一塌糊涂。

这套饮食健康管理系统恰好卡在中间。它有三个核心实体：用户、食物、饮食记录。这三者天然构成一对多关系，也就是一个用户可以有多条饮食记录，一条饮食记录对应一种食物。这样就有足够的数据关联去设计表结构、写联表查询、做统计报表，但又不至于复杂到建模困难。同时，系统自带健康管理这个业务方向，热量计算、BMI评估、每日摄入与消耗对比这些都是有明确规则的，不是空泛的概念，答辩时你可以把业务逻辑讲得很清楚。

另一个实际的好处是，这套系统非常容易加“亮点”。比如把每日热量和营养比例做成ECharts图表，比如根据用户目标推荐食谱，比如记录身体指标变化趋势。这些功能可以在基础版本之上逐步叠加，属于典型的“下限不低、上限很高”的题目。时间充裕就多做点，时间紧张就保证核心链路完整。

1.2 系统功能模块划分

我在实际设计的时候，把功能分成了用户端和管理端两条线。

用户端面向普通使用人员，核心功能包括：

• 账号管理：注册、登录、个人信息查看与修改，密码走加密存储
• 身体数据：维护身高、体重、年龄、活动强度、健康目标，系统自动计算BMI和每日推荐摄入热量
• 饮食记录：按早/中/晚餐和加餐记录食物及用量，系统自动计算单条记录热量
• 数据统计：按日、按周查看热量摄入趋势，查看蛋白质、脂肪、碳水占比
• 食谱推荐：根据用户的健康目标，展示合适的推荐食谱
• 历史记录：饮食记录按日期检索，支持修改和删除

管理端则面向系统维护人员，功能相对简单直接：

• 用户管理：查看用户列表、禁用/启用账号
• 食物管理：维护食物营养数据库，包括食物名称、分类、每100g热量、蛋白质、脂肪、碳水含量
• 食谱管理：增删改查推荐食谱

模块划分的原则是“每个模块能讲清楚解决什么问题”。比如食物营养库为什么要单独建表，而不是让用户每次自填热量？因为自填数据无法做统计，也无法做推荐，而且会大量重复录入。这个设计点答辩时很容易得分，因为体现出了你对数据一致性和系统可维护性的思考。

1.3 前后端分离架构下的开发流程

技术架构确定后，开发流程一般是先定接口、再建表、再写后端、再写前端。但实际操作中我建议的节奏是：先把数据库表结构建好，然后搭建后端工程跑通最简单的登录注册接口，前端同时把登录页和主页框架搭起来，最后再逐个模块填充。也就是说先跑通一条“注册 → 登录 → 查看主页”的最小闭环，后面加功能就是复制这条已有的路。

前后端分离带来的最大好处是后端只需要返回JSON数据，不用关心页面长什么样；前端只需要请求数据渲染页面，不用关心数据存在哪。但这种模式也带来一个代价：前后端联调时容易出现字段对不上、跨域请求被拦截、接口路径不一致等问题。这些问题我在第七章会专门展开，现在你只需要在脑子里留个印象：接口文档约定很重要，哪怕只是简单写清楚“路径、请求方式、请求参数、返回结构”四项，就能减少大量联调返工。

2. 开发环境搭建与版本选型

2.1 技术栈选型：版本搭配的避坑思路

这套系统的技术选型，表面上看就是Spring Boot加Vue，但真正决定开发体验的其实是具体版本。我见过不少同学在环境搭建阶段就被卡住，多数原因是版本没搭配好。

先说Spring Boot。目前网上能找到的教程大量集中在2.x版本，而有些同学创建项目时直接选了最新的Spring Boot 3.x，结果发现需要JDK 17起步，原来好用的部分依赖也做了调整，查问题时搜到的解决方案很多都对不上。我的建议是：如果目标是顺利毕业、快速出活，就用Spring Boot 2.7.x配合JDK 8或11，这是最稳的组合。JDK 8到现在依旧是很多企业生产环境的主力版本，你用它写毕设完全拿得出手，不会被挑毛病。如果是SSM框架的老题目，Spring Boot 2.4到2.7区间都可以，但没必要追新。

再说前端。Vue 2配合Element UI和Vue 3配合Element Plus，两者功能上都满足这个系统。如果你之前接触过Vue 2，或者希望出问题时能快速搜到解决方案，那Vue 2 + Element UI依旧推荐；如果你愿意多花一点时间熟悉组合式API，也完全可以选Vue 3 + Element Plus。这两种选择在答辩时都不算扣分项，关键是你自己能把页面逻辑说清楚。我下面讲的开发思路两种版本通用，用到差异点时会单独说明。

数据库方面，MySQL 5.7和8.0都可以，推荐用8.0，字符集记得在创建数据库时指定utf8mb4，避免后面做中文搜索或用户名查询时出现编码问题。连接工具用Navicat或DBeaver都行，DBeaver免费开源，Navicat更常见常用，看自己电脑里有什么就用什么。

2.2 用IDEA创建Spring Boot后端工程

后端工程创建这个环节，我建议直接用IDEA自带的Spring Initializr，不用去网页版手动下载再导入，那样反而多一步。操作路径是：File → New → Project → Spring Initializr，然后按下表填写基础信息：

这里有一个重要的点：MyBatis-Plus不能直接通过Initializr选到，因为它不是Spring官方维护的框架。正确的做法是项目创建成功后，在pom.xml里手动添加它的依赖坐标。我用的是mybatis-plus-boot-starter的3.5.x版本，与Spring Boot 2.7能很好兼容。Lombok如果之前没用过，可以先加上，它能让实体类少写大量getter/setter，但要注意IDEA需要安装Lombok插件，否则编译会报找不到方法。

Maven依赖下载慢是国内开发环境的常态。解决方法是修改Maven的settings.xml，把中央仓库镜像换成阿里云镜像。这一步几乎是必修课，否则创建一个项目等十几分钟依赖都下不下来是常事。具体配置就是把mirror节点指向https://maven.aliyun.com/repository/public。

创建好工程后，先不要急着写业务代码，先跑一次空的main方法，确认启动成功再继续。很多同学喜欢把所有依赖配完再启动，结果报错时根本分不清是哪个环节出了问题。先跑通空的工程，之后再加入配置和代码，这个习惯能帮你把问题范围缩小很多。

2.3 Vue环境安装与项目初始化

前端环境核心就两样：Node.js和npm。Node.js直接去官网下载LTS版本安装即可。这里特别提醒：安装完成后打开命令行执行node -v和npm -v确认版本，能输出版本号才说明环境变量配置成功。有些同学安装时一路点下一步，但安装完发现命令不识别，多半是安装包没勾选“添加到PATH”或者安装异常。

用Vue CLI还是Vite创建项目，我的看法是：如果打算用Vue 2，那就用Vue CLI，执行vue create diet-health-ui，创建过程中选择预设时选Vue 2和Router，其他选项按默认来；如果打算用Vue 3，Vite是更现代的选择，执行npm create vite@latest，然后选择vue模板。考虑到这个系统本身不算复杂，Vue CLI的完整交互和默认配置其实更省心。

项目创建完以后，通常还需要安装axios、vue-router、UI组件库、ECharts。有的依赖在创建项目时已经带上了，比如vue-router在Vue CLI交互选择后会自动配置。安装命令一般长这样：npm install axios element-ui echarts。如果网络较慢，可以先执行npm config set registry https://registry.npmmirror.com把源切到国内镜像。

安装依赖这个过程最容易出问题的就是版本兼容。曾经遇到一个情况，npm安装Element Plus时报错，结果是因为Node版本太低。Element Plus要求Node.js版本不低于某个下限，所以装依赖之前先确认一下Node版本。如果纯粹为了跑毕设，Node 16到20之间的LTS版本基本都够用。

3. 数据库设计与初始化

3.1 从业务需求推导表结构

数据库设计是整套系统最应该花时间想清楚的部分，因为后端接口和前端页面都依赖这张“地基”。我在设计表结构的时候，习惯先罗列业务对象，再看它们之间的关系，最后落到字段。

这个系统里的核心业务对象包括：用户、食物、饮食记录，辅助对象有食谱和身体指标记录。用户和饮食记录是一对多，食物和饮食记录也是一对多，所以饮食记录表要同时存user_id和food_id两个外键字段。这样设计之后，查询某用户某一天吃了什么，只需要通过用户ID和日期过滤饮食记录表，再关联食物表取食物名称和营养数据即可。

这里要解释一个关键的设计决策：为什么饮食记录表要冗余一份total_calories字段？按用户操作习惯，一条饮食记录是“食物 + 用量”的组合，热量等于食物的每100g热量乘以用量再除以100。这个值其实随时可以根据食物表重算出来，那为什么还要存？因为一次饮食记录一旦生成，就代表当时那顿饭的历史事实。如果后来管理员修改了这个食物的营养数据，历史记录的热量不应该跟着变，否则统计结果会和用户当时的认知不一致。所以记录表里冗余存储计算好的热量，既方便查询又保持历史一致性。

食谱表的设计也比较直观，一个食谱对应一个健康目标，通过goal字段区分适用人群。考虑到食谱的食材和步骤是长文本，用TEXT类型存储即可，不需要单独拆表。这个粒度对毕设来说足够。

3.2 核心建表SQL与字段设计说明

下面直接给出建表SQL。这套结构我实际跑过，字段类型和索引设计都够用。

CREATE TABLE `user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称', `gender` tinyint(1) DEFAULT NULL COMMENT '性别：1男 2女', `age` int(11) DEFAULT NULL COMMENT '年龄', `height` decimal(5,1) DEFAULT NULL COMMENT '身高（cm）', `weight` decimal(5,1) DEFAULT NULL COMMENT '体重（kg）', `activity_level` int(11) DEFAULT NULL COMMENT '活动强度：1久坐 2轻度 3中度 4高强度', `goal` int(11) DEFAULT NULL COMMENT '健康目标：1减脂 2保持 3增肌', `role` tinyint(1) NOT NULL DEFAULT 0 COMMENT '角色：0用户 1管理员', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

食物表和饮食记录表是重点，单独说明几个字段的取舍。

CREATE TABLE `food` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `name` varchar(50) NOT NULL COMMENT '食物名称', `category` varchar(20) DEFAULT NULL COMMENT '分类：主食、蛋白质、蔬菜、水果、乳制品、零食', `calories` decimal(8,1) DEFAULT NULL COMMENT '每100g热量（千卡）', `protein` decimal(5,1) DEFAULT NULL COMMENT '每100g蛋白质（g）', `fat` decimal(5,1) DEFAULT NULL COMMENT '每100g脂肪（g）', `carbohydrate` decimal(5,1) DEFAULT NULL COMMENT '每100g碳水（g）', `unit` varchar(20) DEFAULT '100g' COMMENT '单位', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='食物营养数据表'; CREATE TABLE `diet_record` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `user_id` bigint(20) NOT NULL COMMENT '用户ID', `food_id` bigint(20) NOT NULL COMMENT '食物ID', `meal_type` tinyint(1) DEFAULT NULL COMMENT '餐次：1早餐 2午餐 3晚餐 4加餐', `amount` decimal(8,1) NOT NULL DEFAULT 100 COMMENT '食用量（g）', `total_calories` decimal(8,1) DEFAULT NULL COMMENT '实际摄入热量（千卡）', `record_date` date NOT NULL COMMENT '记录日期', `record_time` time DEFAULT NULL COMMENT '记录时间', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_user_date` (`user_id`,`record_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='饮食记录表';

关于字段设计，有几个容易踩的坑。一是数值类型的选择，身高体重和热量都用decimal而不是float或double，因为浮点数在计算时可能产生精度问题，而decimal能精确表示小数。二是日期字段，用户记录饮食是按天查看的，所以record_date必须是date类型，同时和user_id一起建联合索引。三是不建议在饮食记录表里直接存“食物名称”字符串，虽然查询时少一次关联，但一旦食物改名，所有历史记录都跟着错乱，也失去了通过食物分类做统计的能力。

食谱表结构如下，适合做推荐功能的基础。

CREATE TABLE `recipe` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `name` varchar(100) NOT NULL COMMENT '食谱名称', `category` varchar(20) DEFAULT NULL COMMENT '类型', `goal` int(11) DEFAULT NULL COMMENT '适用目标：1减脂 2保持 3增肌', `calories` decimal(8,1) DEFAULT NULL COMMENT '总热量（千卡）', `ingredients` text COMMENT '食材清单', `steps` text COMMENT '做法步骤', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='推荐食谱表';

3.3 初始化数据与建库工具

建库时用一条命令创建并指定字符集，避免后续出现中文乱码：

CREATE DATABASE diet_health DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

饮食健康系统里，食物初始数据非常重要，因为用户用系统第一步就是搜索食物并记录。食物数据可以在网上找中国食物成分表，整理出一批常见食物导入进来，不用贪多，五六十条覆盖主食、肉类、蔬菜、水果、奶制品就够了。导入方式可以用Navicat直接执行SQL，也可以写成INSERT语句。需要注意食物热量单位是“每100g”，录入时换算正确，比如米饭每100g约116千卡，鸡蛋每100g约144千卡，这些是基本常识不能错。

管理员初始化更简单，直接在user表插入一条role=1的记录，密码用后端同样的加密算法生成后存入。或者更省事的方法是，后端注册接口预留一个判断，如果当前用户表为空则自动把第一个注册用户设为管理员，演示时很方便。

4. 后端核心功能实现

4.1 后端工程结构分层与管理

后端代码如果全部堆在几个类里，不仅自己后期维护痛苦，答辩时老师看了也觉得不像工程化开发。我用的分层结构是常见的四层结构：

src/main/java/com/example/diethealth/ ├── controller/ # 接收HTTP请求，返回统一结果 ├── service/ # 业务逻辑层，处理实际业务 ├── mapper/ # MyBatis-Plus数据访问层 ├── entity/ # 数据库实体类 ├── config/ # 配置类（跨域、拦截器、分页插件） ├── common/ # 统一返回结果、异常处理、工具类 └── DietHealthApplication.java

这个分包也对应了答辩时可以讲的三层架构思想：Controller只负责参数接收和结果返回，Service负责业务规则，Mapper负责数据库操作。这样的好处是职责清晰，出现问题时能快速定位。实际上，很多老师在答辩时会问“为什么要把Controller和Service分开”，答案就是解耦和复用。

启动类上除了@SpringBootApplication，通常还要加@MapperScan注解扫描mapper包，不然MyBatis-Plus的Mapper接口不会被Spring容器管理，启动时会报找不到Bean。如果用的是新版MyBatis-Plus，也可以在每个Mapper接口上单独加@Mapper，两种方式任选其一，但不要两种混用。

4.2 统一返回结果与全局异常处理

前后端分离的项目，后端接口的返回格式必须统一，否则前端每个请求都要单独判断数据结构，代码会很乱。我定义了一个简单的Result类：

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

统一返回格式，前端在封装axios拦截器时就能统一处理code，一旦登录失效或者业务异常，弹个提示就行，不需要每个页面重复判断。

全局异常处理同样重要。Spring Boot里可以用@RestControllerAdvice配合@ExceptionHandler统一捕获业务异常和参数校验异常。比如用户传了不存在的食物ID，或者注册时用户名重复，这些都应该在Service层抛出业务异常，由全局异常处理器转成统一的JSON结果返回。不要在任何Controller里用try-catch把异常吞掉，否则前端收到200但data是null，排查问题会很痛苦。

4.3 基于JWT的用户登录鉴权

用户模块是所有功能的前提，所以优先实现。密码不能明文存储，我用的是BCrypt加密方案。引入spring-security-crypto依赖后，只需要一行代码完成加密和校验，比手动写MD5加盐更安全，也更省事。

// 注册时加密 String encodedPwd = new BCryptPasswordEncoder().encode(user.getPassword()); // 登录时校验 boolean matches = new BCryptPasswordEncoder().matches(rawPassword, user.getPassword());

为什么不用原生MD5？因为MD5有彩虹表攻击风险，即使加盐也需要自己实现一套规则，出问题概率不低。BCrypt内置随机盐，每次加密结果不同，校验时也能正确处理，对毕设来说成本低很多。

登录成功后，我生成一个JWT令牌返回给前端。JWT的依赖用jjwt库。生成逻辑很简单：设置用户名、用户ID、角色作为载荷，设置过期时间，用密钥签名。前端拿到后存到localStorage，每次请求在请求头里带Authorization: token，后端写一个拦截器统一校验。

拦截器写法核心是这样的：

public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("Authorization"); // 校验token，失败则返回401，成功则把用户信息放入request return true; } }

然后通过WebMvcConfigurer注册拦截器，并配置放行路径：登录、注册这两个接口必须放行，其他接口都要校验，但管理员接口还需要额外校验角色。这里有个实用细节：拦截器里可以直接用request.getRequestURI()判断请求是否以/admin/开头，是的话再检查JWT里的role字段是否为1，这样就实现了普通用户和管理员的权限隔离，不用单独写一套JWT校验逻辑。

4.4 饮食记录与热量统计的核心业务逻辑

饮食记录模块是整套系统的业务核心。添加记录时，前端传foodId、mealType、amount、recordDate这些参数，后端拿到以后根据食物ID查出该食物每100g的热量，然后计算：

BigDecimal calories = food.getCalories() .multiply(amount) .divide(new BigDecimal("100"), 1, RoundingMode.HALF_UP);

计算时保留一位小数，四舍五入。这个步骤有一个关键点：必须使用BigDecimal而不是double，否则在计算如0.1+0.2这类浮点数时会出现精度问题。我在实际开发中确实遇到过热量算出来多0.0000001的情况，图表显示到小数后N位非常难看，最后全改成BigDecimal才解决。

按日期查询当天记录是第二步。查询条件有三个：当前登录用户ID、日期、以及餐次（可选）。返回的数据需要把食物名称、分类、热量一并带出，所以在service层组装VO（视图对象）返回给前端，而不是直接返回实体类。实体类和VO分离是一个习惯问题，但它能避免一个很实际的问题：比如你想在接口里多返回一个食物分类名，而实体类里没有这个字段，硬加进实体类就会显得结构混乱。

每日推荐热量计算，我用的是Mifflin-St Jeor公式。这是国际上比较常用的基础代谢计算公式：

男性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 + 5 女性：BMR = 10 × 体重(kg) + 6.25 × 身高(cm) - 5 × 年龄 - 161

算出基础代谢之后，乘上活动系数（久坐1.2、轻度1.375、中度1.55、高强度1.725），再根据健康目标调整。减脂目标建议在维持热量基础上减少300千卡，增肌则增加300千卡，保持目标直接用维持热量。这个公式最大的价值是让系统不只是一个记录工具，还能给用户提供“今天还能吃多少”的参考。在首页展示已摄入热量 / 推荐摄入热量的进度条，是答辩时一个很好的演示点。

4.5 MyBatis-Plus增删改查用法要点

MyBatis-Plus最方便的在于单表CRUD基本不用写SQL。继承BaseMapper<T>之后，selectById、insert、updateById、deleteById这些方法直接用就行。但在实际业务中，常用的反而是条件构造器QueryWrapper。

比如按日期查询某用户的饮食记录：

LambdaQueryWrapper<DietRecord> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(DietRecord::getUserId, userId) .eq(DietRecord::getRecordDate, date) .orderByAsc(DietRecord::getMealType);

LambdaQueryWrapper的写法比普通字符串写法更安全，因为字段名是编译期强类型，不会出现把某个字段拼错字符串导致SQL报错的问题。这个习惯建议从一开始就养成，尤其后面要对多个条件做组合查询时，会省很多调试时间。

分页功能在食物管理中需要用到。MyBatis-Plus的分页需要先注册分页插件：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

然后就可以用Page对象接收分页结果：foodMapper.selectPage(page, wrapper)，返回的page.getRecords()是当前页数据，page.getTotal()是总条数，前端分页组件用这两个字段就足够了。这里我踩过一个坑：分页插件没配时，调用selectPage不会报错，但返回的total始终是0，数据也不正确。如果遇到这个问题，第一反应就应该去检查分页插件是否注册成功。

5. 前端页面实现与接口联调

5.1 Vue页面与路由设计

前端工程我把用户端页面拆成了六个主要视图：登录页、注册页、首页仪表盘、饮食记录页、食物库页、统计页、个人中心页。路由配置使用vue-router，关键是要添加一个由登录状态控制的全局守卫。

路由守卫的作用是：用户未登录时，任何页面访问都跳转到登录页；已经登录时，访问登录页会自动跳回首页。实现思路是，在router.beforeEach里从localStorage取出token，有token则放行，没有token则强制跳转登录页。这个功能虽然代码只有几行，但它是前端安全的第一道门槛，答辩时被问“前端怎么控制用户权限”就能直接回答。

页面布局上，我建议用“左侧菜单 + 右侧内容区”的后台管理布局。Element UI有el-container组件，配合el-aside放菜单、el-main放内容区，整体界面干净整洁。菜单项包括首页、饮食记录、食物库、数据统计、个人中心。管理员登录后，菜单额外显示用户管理和食物管理入口。判断方式依然是看本地存储的用户角色字段。

这里提到了一个常见问题：vue-router在4.x版本中，动态路由和路由守卫的写法与2.x略有差异，但整体思路一致。无论用哪套，建议把登录后的用户信息和token统一存到localStorage，刷新后也能保持登录状态，避免每次刷新页面都要重新登录的尴尬。

5.2 Axios请求封装与跨域处理

axios是前端请求后端的主要工具。我建议在src/utils/request.js里做一层统一封装，而不是每个页面直接调用axios。这样做的好处是：所有请求的baseURL、token携带、响应状态处理都能集中维护。

封装的核心逻辑：

import axios from 'axios' import { Message } from 'element-ui' import router from '@/router' const request = axios.create({ baseURL: '/api', timeout: 10000 }) // 请求拦截器：自动携带token request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) // 响应拦截器：统一处理错误 request.interceptors.response.use( response => { const res = response.data if (res.code !== 200) { Message.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') } Message.error('网络异常，请稍后重试') return Promise.reject(error) } ) export default request

关于跨域，前后端分离项目在前端请求后端时必然遇到。我有两种处理方式：一种是在前端vue.config.js里配devServer代理，把/api开头的请求转发到http://localhost:8080，这样开发环境看不到跨域问题；另一种是在后端配置CORS跨域过滤器。两种方式可以同时做，但前后端配置的含义不同：前端代理只影响开发环境，后端统一配置CORS则是让任意来源都能访问接口。实际部署时建议走后端CORS和Nginx反向代理，开发时用前端代理最省事。

5.3 主要页面实现思路

首页仪表盘是整个系统的门面，建议放四块内容：用户基础信息卡片（身高体重年龄BMI）、今日热量摄入进度条（已摄入/目标）、近七日热量趋势图、今日三餐记录摘要。这几块内容覆盖了用户最关心的数据，演示效果也好。在实现时需要注意，页面加载时通过onMounted或created钩子并行请求多个接口，而不是一个一个串行请求，可以提高页面加载速度。这里可以用Promise.all同时发三个请求。

饮食记录页是用户操作频率最高的页面。顶部是日期选择器，可以选择查看任意一天的记录；中间是“添加记录”按钮，点击弹出对话框，选择餐次、搜索食物、输入用量；下方按餐次分组展示当天记录，每条记录显示食物名称、用量、热量，并提供删除操作。为了提升交互体验，食物搜索建议做成输入框带远程搜索，即用户输入关键词后前端调用食物模糊查询接口，下拉展示匹配结果。这个功能对应的是后端食物表的name like '%关键词%'查询，实现不难但很加分。

统计页用ECharts展示数据，这是视觉上最出效果的页面。核心图表有两个：一个是近30天热量摄入趋势折线图，另一个是近7天蛋白质、脂肪、碳水的摄入比例饼图。ECharts在Vue中的使用思路是：定义好option对象，在mounted里拿到DOM元素并初始化图表，然后调用后端接口拿数据填进option，再调用setOption渲染。要注意的是，图表容器需要有明确高度，否则ECharts无法正常渲染。另外，切换路由时记得销毁图表实例，否则可能造成内存泄漏。

5.4 前端打包与部署

开发完成后，需要把前端打包成静态文件，才能和后端一起部署上线。执行npm run build后，会在dist目录下生成静态资源文件。此时有两种常见部署方式。

第一种是直接把dist目录放进Spring Boot的src/main/resources/static下，然后重新打包后端Jar包，这样访问后端地址就能直接看到前端页面，整体变成一个“单应用”。这种部署方式最省事，适合毕设演示和写进论文。但要注意，前端打包时如果接口地址是按开发环境的/api路径请求的，打包后这些请求会指向同一域名下的/api，只要后端接口路径也是/api开头，就能正确访问。

第二种是用Nginx部署前端，Spring Boot单独跑后端端口，通过Nginx配置反向代理转发/api请求到后端服务。这种部署方式更贴近企业实际，但配置工作量更大。如果你希望在答辩时展示“上线部署”能力，或者论文里有一章“系统部署”，那我建议用第二种方式，但至少提前2天开始调试，避免在Nginx配置上卡太久。

6. 毕业设计文档与答辩准备

6.1 论文和系统说明书的章节安排

很多同学开发做完后发现论文才是最耗时间的环节，所以这里建议：开发过程中一定要随手记录笔记，包括每个模块做了什么、遇到了什么问题、怎么解决的。这些内容最后都是论文里“系统实现”和“系统测试”章节的素材。

计算机毕业设计的论文结构一般比较固定，我按照常见模板梳理如下。第一章绪论，包括研究背景、国内外研究现状、研究意义；第二章相关技术介绍，把Spring Boot、Vue、MySQL、MyBatis-Plus的原理和在本系统中的应用说清楚；第三章系统需求分析，包括可行性分析、功能需求分析、用例图；第四章系统设计，包括总体架构设计、功能模块设计、数据库设计；第五章系统实现，每个功能模块配截图加核心代码说明；第六章系统测试，包括测试环境、功能测试用例表、性能测试简述。最后是总结与展望。

有个实际建议是：数据库设计部分画ER图时，用PowerDesigner或draw.io都行，但务必保证表名、字段名和实际数据库完全一致。有的同学论文里写的表结构跟实际代码对不上，答辩时被老师一问就露馅了。ER图建议至少包含用户、食物、饮食记录三张核心表及它们的关系。如果你在后面加了食谱和身体指标表，也要一并画进去。

6.2 答辩高频问题与演示建议

答辩环节能不能顺利通过，很大程度上取决于你对自己项目的熟悉程度和表达是否清晰。我结合自己的经验整理了一些高频问题：

• 为什么选用Spring Boot而不是传统的SSH或SSM框架？
• Vue的路由守卫是怎么实现的？如果用户未登录直接访问某个页面会发生什么？
• 数据库表之间是什么关系？为什么饮食记录表不直接用食物名字段而要存食物ID？
• JWT和Session有什么区别？为什么前后端分离项目推荐JWT？
• 前端跨域是怎么解决的？

这些问题的回答思路，我在前面各个章节里其实都已经讲过。关键是要用自己的话讲出来，不要背理论。比如被问到“为什么用JWT”，你只要说清楚“因为后端不保存用户状态，前端把令牌存下来每次请求带着，服务端验签通过就认为是有效用户”，就已经表达得很准确了。

现场演示的时候，建议准备一份演示数据：一个测试账号，里面预置了2-3天的饮食记录，这样登录后首页和统计页立刻有数据展示，效果远比现场手忙脚乱录一条记录要好。另一个演示技巧是，故意演示一个“异常操作”，比如直接访问一个不存在接口、输入错误密码登录，然后解释后端如何统一处理和返回错误信息，这会让老师觉得你考虑问题比较全面。

7. 常见问题与排查技巧实录

7.1 后端启动与运行问题

后端启动失败是新手遇到最多的报错，归纳起来不外乎三类。

第一类是端口占用。Spring Boot默认端口是8080，如果本机已经启动了其他服务占用了这个端口，启动就会报Port 8080 was already in use。解决办法是在application.yml里换个端口，比如server.port: 8081，或者把占用端口的进程杀掉。Windows下可以用netstat -ano | findstr 8080找到对应的PID，然后在任务管理器里结束进程。

第二类是数据库连接失败。报错信息一般是Access denied for user或Communications link failure。前者说明用户名密码或权限有问题，后者说明MySQL服务没有启动或者连接地址写错。我在开发时习惯把数据库配置单独写在application.yml里：

spring: datasource: url: jdbc:mysql://localhost:3306/diet_health?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码

serverTimezone这个参数很关键，不配的话数据库连接可能会报时区错误。另外，如果MySQL是5.7版本，驱动类要写com.mysql.jdbc.Driver；如果是8.0版本，驱动类是com.mysql.cj.jdbc.Driver，Spring Boot 2.7可以自动识别，不用手动配置。

第三类是依赖问题，比如Cannot resolve symbol或者Package not found。这类问题多数是Maven依赖没下载完整。解决办法是IDEA右侧Maven面板点刷新按钮进行重新导入，或者找到本地仓库把相关依赖目录删掉再重新下载。如果是在学校网络环境，建议换用手机热点或者校园网镜像源，效果立竿见影。

7.2 前端安装与打包问题

前端最大的坑集中在依赖安装和打包资源路径上。

npm安装慢或者失败，前面已经提到用淘宝镜像切换源。如果执行npm install时报ERESOLVE unable to resolve dependency tree这种依赖冲突错误，可以尝试npm install --legacy-peer-deps，这条命令会跳过严格的对等依赖检查，在Vue 2项目配合npm 7以上版本时尤其常见。另外，安装失败后最好删掉node_modules目录和package-lock.json重新装，不要只重试，因为残留的损坏依赖可能会反复报错。

vue打包后布局异常是我在热搜词里看到的高频问题，实际原因通常有三个。第一个是静态资源路径设置不对，部署后样式和脚本404导致页面空白或错乱，这种情况要在vue.config.js里设置publicPath: './'，让打包产物使用相对路径而不是服务根路径。第二个是Element UI图标字体文件加载失败，通常也是路径问题，解决方案同上。第三个是部署环境浏览器缓存了旧的JS文件，可以清一下浏览器缓存，或者在打包配置里给文件名加hash。这个改动我建议在开发完成打包时就顺手做掉，能省掉后面部署时的一堆麻烦。

7.3 前后端联调问题

联调阶段最常见的两个问题：接口404和返回字段对不上。

接口404，通常是因为前后端约定好的路径不一致。比如前端请求/api/user/info，但后端Controller的RequestMapping是/user/info，而且没有统一加/api前缀。我建议在后端所有Controller的类上统一加@RequestMapping("/api/xxx")，保持和前端baseURL一致。另一种情况是后端接口方法写的是POST请求，前端用GET请求调用，返回404或者405，这时需要两边核对请求方式是否一致。

字段对不上，就体现出了实体类和VO分离的价值。比如后端返回的字段名是totalCalories，前端却写成total_calories，自然渲染不出来。解决办法是双方在联调前先定好接口文档，或者用JSON在线解析工具先看一眼返回结构，再写前端代码。我自己的习惯是，后端接口完成后先用Postman跑一遍，确认返回的JSON长什么样，然后前端再按这个结果去写。

另外再提一个容易被忽视的问题：日期格式。后端返回的日期默认可能是2025-01-06T08:30:00这种带T的格式，前端如果不处理直接展示很不友好。可以在后端配置统一的Jackson日期格式，也可以让后端返回字符串字段，比如直接返回recordDate的toString()。考虑到这个系统日期展示频率很高，我会选择在后端实体类的日期字段上加@JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT+8")，一劳永逸。

最后再分享一点我的个人体会。做毕业设计，很多人容易陷入一种“追求新技术和复杂功能”的误区，觉得用到的技术越新、功能越复杂，分数就越高。但实际上，毕业设计考察的核心是：你能否独立完成一个完整的、可运行的系统，能否把每个设计决策背后的理由讲清楚。这套饮食健康管理系统，核心代码量并不大，只要你把用户登录鉴权、饮食记录、热量统计和图表展示这四块做扎实，已经是一个结构完整、能讲出亮点的作品了。遇到问题不要慌，绝大多数问题网上都能搜到答案，关键是要学会描述问题、定位问题、然后精准搜索。如果能把开发过程中的坑都记录下来，那不管是对论文还是对答辩，都是非常宝贵的材料。