从开始接到这个“Java Web 智能推荐卫生健康系统”项目到现在我前后大概折腾了三周时间。技术栈就是标题里写的那套SpringBoot2 Vue3 MyBatis-Plus MySQL8.0整体做下来给我的感觉是——这套组合确实是当前做毕业设计和中小型全栈项目最稳的选择之一。尤其对于健康饮食推荐这个方向既要处理用户健康数据的建模又要实现推荐算法和后端接口的落地还要把前端页面做得能用、好看技术选型一旦不合适后期返工成本会非常高。我写这篇文章的目的是想把这套系统的从零搭建思路、表结构设计、推荐算法的工程化实现、以及前后端联调和部署过程中遇到的问题一次性讲透。不管你是准备拿它做毕业设计还是想练手全栈开发或者想在SpringBoot2和Vue3这个技术栈上找一套可复用的实现方案这篇文章都能给你省下不少时间。1. 项目全景这套系统到底在做什么1.1 为什么毕业设计和工程实践都爱选这套技术组合先说个很多人没想明白的问题为什么市面上的Java Web项目尤其是健康类、饮食推荐类的系统十个里有八个都是SpringBoot Vue MyBatis-Plus MySQL这套组合答案其实很现实。SpringBoot2把Spring那套复杂的XML配置几乎全干掉了内嵌Tomcat打jar包就能跑这对快速交付项目来说是决定性的优势。Vue3呢组合式APIComposition API让组件的逻辑复用变得非常干净做后台管理系统和业务页面都顺手。MyBatis-Plus解决了MyBatis最烦人的问题——单表CRUD不用写XML代码生成器一键生成实体和Mapper配合条件构造器做动态查询基本不写SQL。MySQL8.0又是现在最主流的关系型数据库网上资料多云数据库也基本都兼容8.0。但这里我建议不要盲目跟风一定要想清楚一个问题推荐系统核心是算法而算法落地最需要的是灵活的数据操作这套技术栈在这一点上恰恰非常合适。比如用户协同过滤需要频繁查用户-食物的交互矩阵MyBatis-Plus的LambdaQueryWrapper可以快速组装条件MySQL8.0的窗口函数可以做推荐结果的批量排序Vue3的前后端分离模式让推荐接口和页面展示各司其职。技术选型不是看谁新而是看谁匹配项目目标。1.2 核心业务模块解构与需求映射这套智能推荐卫生健康系统核心业务并不复杂但模块划分一定要清晰。我个人拆解下来至少要包含以下六大块用户模块注册登录、个人信息维护、密码加密存储。健康档案模块身高体重、年龄、性别、疾病标签如高血压、糖尿病、饮食禁忌这是推荐算法的核心输入。食谱管理模块管理员维护食谱库包含食材、热量、营养成分、适合人群标签。推荐引擎模块根据用户健康档案和行为数据生成个性化食谱推荐列表。收藏与反馈模块用户对推荐结果的收藏、点赞、不喜欢反馈这些数据是推荐模型迭代的依据。健康统计模块用户每日摄入热量统计、推荐历史的健康评估。我当时画模块图的时候最深的体会是健康档案模块千万别做得太简单它直接影响推荐算法的可用性。很多参考项目把健康档案做成可有可无的扩展表最后推荐结果和用户实际情况完全不匹配一眼就能看出是凑数的。卫生健康的“智能”二字恰恰体现在用户特征建模的维度是否足够丰富。2. 数据库先行MySQL 8.0 下的表设计要点2.1 核心表结构设计与字段选取思路数据库设计是这套系统的地基。我强烈建议动手写代码之前先把表结构设计好否则后面改起来真的会想哭。基于MySQL8.0我设计的核心表如下你可以直接参考表名核心字段设计要点userid, username, password, nickname, avatar, create_time密码用BCrypt加密存储字段长度要留余量health_profileid, user_id, height, weight, age, gender, disease_tags, taboosdisease_tags用JSON格式存储多标签taboos存禁忌食材名称示例这是推荐过滤的关键foodid, name, category, calories, protein, fat, carbs, vitamins, suitable_tags营养成分字段统一用decimal(6,1)suitable_tags用JSON存“适合高血压”“高蛋白”等标签recommendation_recordid, user_id, food_ids, reason, score, status, create_timefood_ids用JSON数组存储reason保存推荐解释文本方便前端展示“为什么推荐给你”user_feedbackid, user_id, food_id, action, create_timeaction字段取值like/dislike/collect对协同过滤计算相似度很重要disease_food_mappingid, disease_tag, allowed_foods, forbidden_foods管理员可配置的规则表作为硬过滤条件这里有个关键点MySQL8.0支持JSON字段类型很多人犹豫到底用不用。我的经验是像disease_tags这种固定维度、查询频率不高但需要灵活扩展的字段用JSON很合适配合JSON_CONTAINS可以轻松实现标签匹配。但像food_ids这种如果要频繁关联查询的建议还是单独拆关联表。你在设计时要判断字段是“存储型”还是“查询型”查询型字段尽量别用JSON。2.2 用窗口函数与JSON字段做推荐预处理MySQL8.0比之前的版本强在多了窗口函数这在推荐系统的数据处理上帮了大忙。举个例子当我要给用户推荐食谱时需要按健康评分排序取前10条但不同分类主食、蛋白质、蔬菜需要各保留若干条这种分组内取TopN的需求老版本MySQL写起来非常痛苦8.0里一行窗口函数就解决了SELECT * FROM ( SELECT f.*, ROW_NUMBER() OVER ( PARTITION BY category ORDER BY match_score DESC, calories ASC ) AS rn FROM ( SELECT food.*, compute_match_score(food.id, #{userId}) AS match_score FROM food WHERE JSON_CONTAINS(f.suitable_tags, JSON_ARRAY(健康)) ) f ) t WHERE t.rn 3这只是一个示例实际实现中我会把推荐打分逻辑放进一个独立的存储函数或者Java Service层不要全堆在SQL里。但这段SQL的思路是值得保留的先用子查询算出每个食物的匹配分再用窗口函数做分类内的TopN采样保证推荐结果营养均衡而不是清一色的同一类食物。这种“分类混排”的细节很影响产品体验很多网上参考项目的推荐结果要么全是低热量素菜要么全是高蛋白肉类就是没做这一步。数据库字符集和排序规则也必须注意。MySQL8.0默认是utf8mb4字符集如果建库时不小心选了旧的utf8后面存emoji比如用户昵称带表情会直接报错。我的习惯是建库语句统一写成CREATE DATABASE health_recommend DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;另外MySQL8.0默认的认证插件是caching_sha2_password很多老版本的工具比如某些旧版Navicat和JDBC驱动连不上8.0的数据库就是卡在这里。这个我在后面的部署章节还会专门提到属于必踩的坑之一。3. 推荐引擎从算法到落地的完整链路3.1 基于协同过滤的候选集生成推荐算法是这套系统的灵魂也是答辩时最容易被追问的地方。我用的是经典的基于用户的协同过滤UserCF加基于内容的健康规则过滤的混合推荐策略这样既保证了推荐结果有“个性化”的成分又确保了健康约束不出错。UserCF的核心思想就一句话找到和你口味相似的用户把他们喜欢的而你没见过的食物推荐给你。在代码实现上我分为三个步骤第一步构建用户-食物评分矩阵。评分来源不一定是显式的打分我把用户的收藏、点赞、浏览行为都隐式转化为评分收藏算5分点赞算4分浏览算1分。这个转化逻辑写在UserBehaviorService里public MapLong, Double getUserBehaviorScores(Long userId) { ListUserFeedback feedbackList userFeedbackMapper.selectList( new LambdaQueryWrapperUserFeedback() .eq(UserFeedback::getUserId, userId) ); return feedbackList.stream().collect(Collectors.toMap( UserFeedback::getFoodId, f - collect.equals(f.getAction()) ? 5.0 : like.equals(f.getAction()) ? 4.0 : 1.0, Double::sum )); }第二步计算用户相似度。我用的是皮尔逊相关系数因为不同用户打分的尺度可能不同皮尔逊能消除这种偏差。对行为数据比较稀疏的项目也可以用余弦相似度逻辑更简单public double pearsonCorrelation(MapLong, Double user1Scores, MapLong, Double user2Scores) { SetLong commonItems new HashSet(user1Scores.keySet()); commonItems.retainAll(user2Scores.keySet()); if (commonItems.size() 2) return 0.0; // 计算均值、协方差、标准差得到相关系数 // 实际开发中用Apache Commons Math的PearsonCorrelation类更省事 }第三步生成候选推荐集。找出最相似的N个用户把他们评分高的食物累计加权排除掉当前用户已经消费过的取前K个作为候选。这里有个性能问题需要提前考虑如果用户量大了两两计算相似度是O(n²)的复杂度很慢。我的优化思路是引入“倒排索引”先只计算那些有共同消费行为的用户对而不是全量计算。对于毕业设计这个量级这个方法能省掉90%以上的计算时间。3.2 健康规则过滤与营养匹配协同过滤只解决“用户喜欢什么”的问题但卫生健康场景还有一个底线约束有些东西用户不能吃或者不应该吃。这就需要用基于规则的内容过滤来做硬性筛选。我自己设计了一个三层过滤管道依次执行第一层禁忌食材硬过滤。如果用户的健康档案里有“海鲜过敏”标签那么所有含虾、蟹、贝类的食谱直接排除。这一层用数据库查询就能完成不用等到Java里再判断。注意过敏原匹配不能简单用字符串包含因为“虾仁炒蛋”里的“虾”和“虾米”其实是同类我这边维护了一张forbidden_ingredients表把同一过敏原的不同食材写法都列出来。第二层疾病健康评分过滤。用户有高血压那么盐含量过高的食物降权或排除用户有糖尿病高升糖指数的食物直接排除。这里我做了一张disease_food_mapping规则表管理员可以配置“高血压禁食名单”“糖尿病少食名单”系统启动时加载进Redis或本地缓存推荐时做实时判断。对于不能直接用黑白名单表达的情况我给每个疾病标签配了营养成分的阈值规则比如public double diseaseScore(Food food, HealthProfile profile) { double score 0.0; for (String tag : profile.getDiseaseTags()) { switch (tag) { case 高血压: if (food.getSodium() 400) score - 5; break; case 糖尿病: if (food.getCarbs() 60) score - 4; break; case 肥胖: if (food.getCalories() 300) score - 3; break; default: break; } } return score; }第三层营养均衡混排。这一步就是我在数据库设计那章演示的窗口函数做的事。候选集经过硬过滤和疾病评分后按照主食、蔬菜、蛋白质、水果等类别分组按照综合得分协同过滤分健康规则分各取前几条最后合并成一份营养结构相对均衡的推荐列表。3.3 冷启动与数据稀疏的应对策略做推荐系统的人都知道冷启动是绕不开的问题。新用户没有行为数据协同过滤算不了相似度新食物没有用户反馈也没法进推荐池。这两个问题不解决系统上线第一天推荐接口就直接“傻”了。我对冷启动的处理方案是基于规则推荐兜底。当系统检测到当前用户没有足够的行为数据时我定的阈值是少于5条反馈直接跳过协同过滤采用基于健康档案的规则推荐。比如用户BMI偏高且有“高血压”标签就推荐低盐低热量的食物按健康评分降序排列。这样做的好处是推荐结果虽然“不够个性化”但至少是“健康且合理”的。对于新食物处理方式是给它的初始热度值设一个随机扰动分数让它们有机会在候选集中“露脸”。等用户产生反馈后再用真实的评分数据替代。这是我的一个实操经验初始推荐千万不要“过于正确”必须保持一定的探索率。我在代码里专门写了一个RecommendationService接口签名设计如下你可以参考public interface RecommendationService { ListRecommendationItem recommend(Long userId, int topN); boolean isColdStartUser(Long userId); ListRecommendationItem fallbackRecommend(HealthProfile profile, int topN); void recordFeedback(Long userId, Long foodId, String action); }我把冷启动判断单独抽出来是个很明智的做法因为后续你想优化阈值比如用户行为量从5条变成10条才启用协同过滤只需要改一个常量不需要动推荐链路。另外recordFeedback这个接口一定要独立于推荐接口否则用户每次产生行为都会触发一次全量推荐性能会很难看。4. 后端实践SpringBoot2 MyBatis-Plus 的工程化细节4.1 通用CRUD与条件构造器的高效应用MyBatis-Plus最大的价值在于把单表的CRUD代码量压缩到了几乎为零。你只要建好实体类继承BaseMapperT基础的增删改查、分页查询就全有了不需要写一行XML。这套系统里的user、food、health_profile这些基础表我都用了这个模式。但真正让MyBatis-Plus发挥威力的是LambdaQueryWrapper这个条件构造器。举个例子健康食谱列表页需要根据名称模糊搜索、分类筛选、热量范围过滤用LambdaQueryWrapper写起来非常直观LambdaQueryWrapperFood wrapper new LambdaQueryWrapper(); wrapper.like(StringUtils.isNotBlank(name), Food::getName, name) .eq(category ! null, Food::getCategory, category) .between(minCalories ! null maxCalories ! null, Food::getCalories, minCalories, maxCalories) .orderByAsc(Food::getCalories);注意这里的细节每个条件前面都加了一个布尔判断当用户没传对应参数时这个条件不会拼进去。这个写法能避免大量if-else嵌套代码干净同时安全地防止了空参数导致的全表扫描。分页应该用MyBatis-Plus的分页插件注意一定要配置PaginationInnerInterceptor否则分页查询会失效只要记住实体类有PageT参数就行Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }分页插件的位置很讲究PaginationInnerInterceptor要放在所有拦截器的最后如果后面还有其他自定义拦截器顺序不对会导致分页的count查询出错。这个坑我当时调了一个下午才发现是顺序问题。4.2 推荐接口的核心实现流程推荐接口是后端最核心的接口我把它设计成一个异步任务避免用户请求时同步计算推荐结果导致接口超时。具体流程是这样的用户请求GET /api/recommend?userId1topN10。接口层直接返回立即返回任务已受理同时在后台开启一个异步线程执行推荐计算。异步线程依次执行加载健康档案 - 判断冷启动 - 执行协同过滤/规则推荐 - 三层过滤 - 结果入库recommendation_record表。前端通过轮询或WebSocket获取推荐结果。异步计算的好处显而易见推荐算法涉及多表查询和相似度计算同步执行可能要几百毫秒甚至几秒而接口响应时间如果大于1秒前端体验就很差。用了异步之后接口响应时间稳定在50毫秒以内计算结果稍后推送即可。这个设计我在答辩时也被老师问过解释清楚之后反而是加分项。推荐接口的核心代码简化后大致如下Service public class RecommendationServiceImpl implements RecommendationService { Autowired private FoodMapper foodMapper; Autowired private HealthProfileMapper healthProfileMapper; Autowired private UserFeedbackMapper userFeedbackMapper; Async(recommendExecutor) public CompletableFutureListRecommendationItem recommendAsync(Long userId, int topN) { HealthProfile profile healthProfileMapper.selectOne( new LambdaQueryWrapperHealthProfile() .eq(HealthProfile::getUserId, userId) ); if (profile null) { return CompletableFuture.completedFuture(Collections.emptyList()); } ListRecommendationItem result; if (isColdStartUser(userId)) { result fallbackRecommend(profile, topN); } else { result collaborativeFilterRecommend(userId, topN); } // 记录推荐结果到recommendation_record表 saveRecommendationRecords(userId, result); return CompletableFuture.completedFuture(result); } }这里一定要配置线程池参数别直接用Spring默认的SimpleAsyncTaskExecutor它每次都会新建线程高并发下直接打爆系统。我在recommendExecutor里设置核心线程数8最大线程数16队列容量100拒绝策略用CallerRunsPolicy过载时由调用线程执行任务保证任务不丢失。4.3 分页、缓存与异常统一处理的落地这套系统的数据量虽然不大但缓存的设计理念还是要提前想清楚的。推荐结果这种“读多写少”的数据非常适合缓存。我用的是本地缓存Caffeine因为系统没有引入Redis和微服务没必要为一个单体应用增加部署复杂度。缓存的key设计是recommend:{userId}:{topN}用户行为发生变化时比如产生了新的收藏先删对应key的缓存下次请求再重新生成。如果完全不删缓存用户在收藏了某个食物后下一次推荐还会出现同一个食物体验非常差。过期时间我设置了30分钟既保证数据不过期得厉害又不会因缓存时间太长导致推荐结果一成不变。异常统一处理这块我建议用RestControllerAdvice加ExceptionHandler把业务异常和系统异常分开处理业务异常比如用户不存在、推荐结果为空返回HTTP 200 业务错误码前端根据错误码提示。系统异常数据库连接失败等返回HTTP 500 统一的错误消息避免把堆栈信息直接抛给前端。这个设计完全是工程实践里养成的习惯毕业设计很多参考项目都没有这一步导致前端一旦拿到非200的响应就直接白屏。加了统一异常处理之后前端的错误提示和调试体验好了好几个档次。5. 前端实战Vue3 组合式API下的业务页面搭建5.1 项目初始化与配套环境前端我用的是Vue3 Vite Element Plus Pinia这套组合。Vite的启动速度比Webpack快太多开发体验提升非常明显特别是SPA项目改动后秒级热更新。创建项目的命令很简单npm create vitelatest health-web -- --template vue cd health-web npm install npm install element-plus axios pinia有几个配套环境的细节我必须提醒你。Node版本建议16.14以上太低的话Vite可能跑不起来安装了插件之后如果页面样式不生效大概率是Element Plus的样式没有全局引入需要在main.js里加import ElementPlus from element-plus import element-plus/dist/index.css还有一个Vue3新手极易踩的坑安装依赖后启动报错Cannot find module xxx通常是因为npm install没装全或者node_modules缓存损坏了最简单的解决方法是删掉node_modules和package-lock.json重新执行npm install90%的问题都能解决。5.2 页面路由与状态管理路由我用Vue Router 4按照系统的模块划分设计了以下页面结构登录/注册页独立的布局不嵌套后台框架。首页/推荐页展示推荐食谱卡片支持收藏和点赞。健康档案页表单填写身高体重、疾病标签、饮食禁忌等。食谱管理页管理员维护食谱和营养数据。健康统计页展示热量摄入趋势图和推荐历史。状态管理用Pinia比Vuex清爽很多。我把用户信息和健康档案存到了Pinia里避免多个页面重复请求后端接口import { defineStore } from pinia export const useUserStore defineStore(user, { state: () ({ token: localStorage.getItem(token) || , userInfo: null, healthProfile: null }), getters: { isLoggedIn: (state) !!state.token }, actions: { async login(credentials) { const res await api.post(/api/user/login, credentials) this.token res.data.token localStorage.setItem(token, this.token) }, async fetchHealthProfile() { const res await api.get(/api/health-profile/current) this.healthProfile res.data } } })这里要注意Pinia的getters里用this访问其他状态是可以的但箭头函数不能获取this我开始时就写成了箭头函数结果isLoggedIn怎么都不更新排查了很久才意识到这个语法问题。5.3 与后端联调的关键点前后端联调是整个项目里最容易出bug的环节尤其是请求地址的配置、跨域的处理和响应拦截器的设计。我的做法是在Vite配置里设置server.proxy把开发环境的/api前缀代理到后端的本地端口这样前端代码里请求路径都从/api开始既避免了跨域又方便上线时改环境变量// vite.config.js export default defineConfig({ server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })后端响应拦截器我封装在axios实例里统一处理token附加、错误提示和401跳转const request axios.create({ baseURL: /api, timeout: 15000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer ${token} return config }) request.interceptors.response.use( response response, error { if (error.response?.status 401) { router.push(/login) } ElMessage.error(error.response?.data?.message || 请求失败) return Promise.reject(error) } )有一个关于日期格式的坑要特别提醒后端返回的时间字段如果是LocalDateTime默认序列化格式是2025-02-03T12:00:00前端展示很别扭。要在后端加一个统一的Jackson配置把时间格式化成yyyy-MM-dd HH:mm:ss这样前端直接使用就不用再做字符串处理了。6. 部署上线与问题排查实录6.1 MySQL 8.0 的安装与连接配置MySQL8.0的安装几乎是这套系统绕不开的第一道坎我整理了两种常见路径的具体操作和注意事项。Windows环境用ZIP包安装的方式最干净。下载mysql-8.0.x-winx64.zip后解压到指定目录然后在根目录下新建一个my.ini配置文件这里我提供一个最简配置[mysqld] basedirD:/tools/mysql-8.0.36-winx64 datadirD:/tools/mysql-8.0.36-winx64/data port3306 character-set-serverutf8mb4 default-authentication-pluginmysql_native_password注意最后一行这个default-authentication-plugin的配置直接影响后续JDBC和客户端工具能否连上MySQL8.0。如果你想用旧版的驱动就必须配置为mysql_native_password否则会报Authentication plugin caching_sha2_password cannot be loaded。现在的新版驱动其实已经支持caching_sha2_password但加上这个配置会让连接更稳妥。然后用管理员身份运行cmd依次执行mysqld --initialize-insecure mysqld -install net start mysql--initialize-insecure生成的root账号默认没有密码这个在开发阶段反而方便连上之后再用ALTER USER rootlocalhost IDENTIFIED BY yourpassword;设置密码就行。MySQL8.0里修改root密码的语法和5.7不同不能用UPDATE mysql.user SET Password...网上很多教程是把5.7的方法混进来的照着做会报语法错误。Linux环境下用Docker装更省心前提是已经装好Docker。代码示例docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDroot \ -e MYSQL_DATABASEhealth_recommend \ -v /opt/mysql-data:/var/lib/mysql \ mysql:8.0映射了数据卷/opt/mysql-data之后容器删了数据还在这个习惯一定要养成。但生产环境不要用root账号连业务库应该单独建一个最小权限的业务账号。6.2 常见问题速查表我在这个项目里前前后后踩了不少坑整理成了一张速查表你可以直接保存问题现象可能原因解决方案启动SpringBoot报Access denied for user rootlocalhostMySQL8.0 root默认认证方式或密码错误检查连接URL的user和password或用ALTER USER重新设置密码检查my.ini的认证插件配置启动报Unknown database health_recommend数据库没有创建或application.yml里库名拼错手动CREATE DATABASE health_recommend DEFAULT CHARACTER SET utf8mb4MyBatis-Plus分页查询无效返回全量数据没配置PaginationInnerInterceptor按我4.1节省略的代码加配置类Vue3访问/api接口报404或网络错误Vite代理没生效或后端端口不一致检查vite.config.js的proxy配置确认后端端口是8080检查代理指向的target是否正确推荐接口返回500推荐算法中用户相似度计算出现无穷大检查皮尔逊相关系数分母是否为零即共同评分数为0或标准差为0时需做保护前端登录成功但刷新后状态丢失token没存到localStorage或Pinia没有持久化封装一个localStorage工具类在store的action里同步存取查询结果中文乱码JDBC连接URL缺少characterEncodingutf8数据库字符集不一致连接URL统一加?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai这里最想展开的一个问题是时区配置。MySQL8.0的JDBC连接URL必须带serverTimezone参数否则会报The server time zone value йʱ is unrecognized或是更早的Cannot create PoolableConnectionFactory之类的大串报错问题根源都是因为你本地的MySQL时区不是标准UTC格式。我在application.yml里的配置统一用spring: datasource: url: jdbc:mysql://localhost:3306/health_recommend?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver另一个我需要单独拎出来提醒的经验是数据库连接池配置。毕业设计项目的并发量不高但HikariCP的默认配置有些参数并不适合本地开发环境。连接池最大连接数我设置为20空闲连接超时时间设为30000毫秒防止长时间空闲后被MySQL服务端主动断开导致连接失效。如果项目运行时突然报Connection is not available, request timed out大概率就是连接池参数和MySQL的wait_timeout不匹配调整一下就好。7. 项目扩展与性能优化心得7.1 想做二次开发从哪里入手最划算基础版本跑通之后如果你想让这个项目在毕业答辩或简历上更有竞争力我强烈建议往以下几个方向扩展投入产出比很高。第一个方向是把推荐结果加上“解释引擎”。现在很多推荐结果是直接给用户列出一堆食物用户不知道为什么推荐这个。我在recommendation_record表里设计了reason字段实际上就是用来存储推荐解释的。你可以根据推荐链路的不同阶段生成解释文本例如“因为和你有相似健康档案的用户也喜欢”来自协同过滤阶段“因为低盐适合你的高血压状况”来自规则过滤阶段。这个功能虽然代码量不大但能让整个项目从“功能堆砌”升级为“有思考的系统”答辩时非常有说服力。第二个方向是引入定时统计任务。我用Scheduled注解实现了每日凌晨的任务对所有用户昨天的摄入热量做汇总并生成健康周报用简单的表格和趋势图展示给用户。这个功能对卫生健康系统非常契合而且实现成本很低只需要在SpringBoot启动类上加EnableScheduling再写一个每天执行的定时方法就行。第三个方向是做一个简易的管理后台。管理员可以维护食谱库和疾病规则表前端用Vue3 Element Plus的表格和表单组件即可实现。整个系统的健壮性很大程度上依赖管理后台的可用性如果你只做用户端管理员没法维护数据和规则系统就没法长期使用。7.2 性能优化这套系统值得做的几个点推荐系统性能优化的重点不在数据库索引而在算法计算环节。用户行为数据量上万之后基于协同过滤的用户间相似度计算就会变得很慢。我的优化思路是按用户的健康标签分组只计算同组用户的相似度在保证推荐效果的前提下把计算量缩小到原来的三分之一不到。你可以在健康档案表上建一个性别、年龄段、疾病标签的联合索引然后分组加载用户ID列表再计算组内用户相似度。如果数据量再上一个量级就必须考虑把计算结果缓存起来。我给每个用户保存一份“相似用户TopN列表”缓存时间设为24小时因为用户的相似关系短期内不会剧烈变化没必要每次都全量计算。用户的行为反馈只影响自己的推荐列表缓存不影响相似用户关系。这个设计思路在面试或答辩时提到都会是加分项。MyBatis-Plus的IService批量操作也能派上用场。比如定时把用户行为表的数据批量写入用户-食物评分矩阵的中间表用saveBatch方法一次性插入上千条数据比逐条insert快了不是一个量级boolean saved userScoreService.saveBatch(userScoreList);这里注意saveBatch默认每批1000条如果你的数据量非常大可以通过自定义SqlInjector配置调整批量提交的大小避免单次SQL过长超出MySQL的max_allowed_packet限制。7.3 文档整理与答辩包装的个人建议项目标题里特别提到了【含文档】文档质量对毕业设计的最终评分影响真的很大。我的习惯是把文档分为四份需求规格说明书、数据库设计文档、接口文档、部署手册。需求规格说明书重点描述系统的业务背景、用户角色和核心功能需求画好用例图把健康档案、推荐引擎、用户反馈等核心功能的描述写细致。数据库设计文档要包含完整的E-R图和数据字典所有表字段的中文注释和约束条件都要在SQL里写清楚不要偷懒。接口文档推荐用Apifox自动生成写完接口之后一键导出比手写快而且不会遗漏。部署手册要详细到每一条命令别人按照你的文档能把系统跑起来这才算合格的部署手册。技术选型的理由一定要写在设计文档里要解释清楚为什么选择SpringBoot2 Vue3 MyBatis-Plus MySQL8.0这个组合而不选其他方案。这实际上是展示你对技术栈的理解深度答辩时老师十有八九会问到这个问题。我个人在实际操作中的体会是这套系统最值得骄傲的不是用了多前沿的技术而是把推荐算法真正落地成了一个人人能看懂、能使用的功能。很多网上参考的卫生健康系统项目推荐模块就是简单按热量排序完全没有协同过滤和健康规则过滤的概念这类做法是把项目最重要的灵魂给砍掉了。做任何智能推荐类系统都建议把算法的完整链路走通哪怕是最简单的协同过滤也比“按销量排序”强一百倍。最后再分享一个小技巧做推荐系统的项目一定把用户的每一次行为反馈都记录好哪怕刚开始数据量少效果一般等数据积累到一定程度系统会自己“变聪明”这个变化过程本身就是项目最好的展示材料。