1. 项目全貌与设计思路拆解1.1 这个“家乡美食推荐”到底在做什么毕业设计里“家乡特色美食推荐系统”这类题目属于典型的“业务型算法型”混合项目表面看是一个美食信息管理平台但实际上它背后考查的是三件事第一你能否把SSM和Vue这套主流前后端分离架构完整落地第二你能否设计出一套合理的推荐逻辑而不是随便按时间倒序排个列表就交差第三你能否把“家乡特色”这个场景融进业务模型里让系统看起来是真的为这个需求而设计而不是套了个通用管理系统改个名字。我见过不少同学拿到这个题目后的第一反应是把系统做成一个“美食展示后台管理”的CRUD首页放一排菜品卡片点进去看详情管理员在后台增删改查然后交差。这种作品不是不能用但答辩时大概率会被问住因为评委一定会问“你的推荐功能体现在哪里推荐逻辑是什么凭什么给用户推这几道菜”所以拿到这个标题第一步不是建工程而是把需求拆明白。系统要解决的核心问题不是“展示美食”而是“帮用户从海量的家乡美食中找到他可能喜欢的那几道”。这就决定了数据模型、算法设计、页面结构都要围绕“用户偏好”展开。1.2 技术选型为什么是SSMVue而不是别的组合SSM是Spring Spring MVC MyBatis的简称Vue则负责前端页面渲染再加上Axios做前后端交互这是目前Java方向毕业设计里最常见的组合之一。选它的理由很实际第一SSM足够经典学校课程基本都讲过答辩时被问到底层原理不会心虚第二前后端分离比传统的JSP模式更接近企业开发习惯简历上写“前后端分离项目”含金量高一些第三SSM相比Spring Boot虽然配置繁琐但正因为繁琐更能体现你对框架原理的掌握包括装配机制、拦截器、过滤器、AOP这些知识点都有地方展开讲。不过说句实在话如果从纯开发效率角度Spring Boot会比SSM省掉大量XML配置。但毕业设计题目里写了SSM你硬改成Spring Boot除非你有充分理由并且能把新旧框架的关系讲清楚否则不建议冒险。我的建议是题目怎么写就怎么做但代码结构上可以把MyBatis的Mapper层写得干净规范Controller保持轻量把业务逻辑下沉到Service层——这样即便将来你想换成Spring Boot迁移成本也很低。前端方面Vue建议用Vue 2 Element UI原因有两个一是Vue 2的资料最多遇到问题一搜就能解决对毕设党来说省时间就是省命二是Element UI的组件风格非常适合后台管理类界面表格、表单、分页、弹窗这些组件开箱即用能让你把主要精力放在业务逻辑而不是样式调试上。1.3 推荐系统的定位轻量级但不敷衍既然是“推荐系统”核心亮点就要落在推荐算法上。但毕业设计不建议一上来就搞深度学习或者复杂协同过滤模型因为数据量和场景根本撑不起来。更合理的做法是设计一套“基于用户偏好标签 基于相似用户的协同过滤”的混合推荐策略算法不复杂但逻辑清晰、可解释性强答辩时能讲明白每一步的输入输出。具体思路是这样用户注册时填写口味偏好标签比如偏辣、偏甜、偏好面食、偏好肉类每个美食条目也有自己的标签集合比如“鲜香”“麻辣”“苏式糕点”“宴席菜”。系统先用基于内容的推荐计算用户偏好与美食标签的匹配度给出第一版候选集再记录用户的收藏和评分行为找与他行为最相似的其他用户把他们喜欢而他还没看过的美食也拉进推荐池最后用一个加权得分公式把内容匹配分、相似用户权重分、基础热度分组合在一起按总分从高到低输出推荐列表。这套方案的优点是每个分数都有明确的业务含义既能说明你理解了推荐系统的经典思路又能在有限的毕设数据量下跑出合理结果不会因为数据稀疏导致推荐结果全是乱猜。2. 数据库模型与核心表设计2.1 数据表结构六张表搞定主业务数据库是整个系统的地基设计得好后面写代码顺手得多。按我的习惯这套系统的核心表分成六张用户表、美食表、美食分类表、地区表、收藏表、评分表。看需求是否要扩展可以再补一张标签表或偏好表但主流程六张表足够。用户表除了常规的id、用户名、密码、昵称、头像、角色管理员/普通用户之外一定要加一个“preference”字段用来存用户的偏好标签ID集合格式可以简单用逗号分隔的字符串比如“1,3,5”。毕业设计阶段不用强求范式这种冗余字段能极大简化推荐逻辑的SQL查询。注册时让用户勾选偏好标签存进这个字段就行不要单独建一张关联表去搞多对多否则查询时多表关联写起来累答辩也未必加分。美食表是核心表字段包括美食名称、所属分类ID、所属地区ID、封面图URL、简介、详细描述、特色标签也是逗号分隔、基础热度值、创建时间。热度值可以由收藏量和评分量动态计算出来也可以设计一个定时任务定期更新但注意别有太重的实时计算压力毕设系统数据量小直接用SQL的COUNTAVG算就行。地区表和分类表是字典表结构几乎一样id、名称、排序值。这两张表的作用是给首页筛选和搜索用的比如用户想找“苏州地区的苏式面点”就需要按地区、分类做条件组合查询。收藏表和评分表的区别一定要设计清楚。收藏代表“我想吃/我感兴趣”评分代表“我吃过了给个分”。这两种行为信号在推荐算法里的权重不同收藏是强正向信号评分则能体现偏好强弱。如果能把这两种行为分开记录推荐算法的输入特征就有两个维度比单纯只做一个收藏表更能体现设计深度。2.2 为什么用逻辑外键而不是物理外键很多同学建表时喜欢用数据库的物理外键约束这个习惯在ACM或课程作业里没问题但在实际开发里——包括毕业设计——我建议尽量别用物理外键。原因很实际物理外键会让插入、删除操作的顺序变得非常严格比如删除一个分类时如果该分类下有美食数据数据库会直接报错或需要先处理关联数据这在你做数据维护时会非常痛苦。正确做法是表与表之间用逻辑外键也就是在子表中存父表的ID字段但不在数据库层面声明FOREIGN KEY约束。关联关系完全由应用层通过SQL JOIN来控制这样既保证了业务上的关联性又避免了物理外键带来的维护负担。更重要的是你用MyBatis写动态SQL时JOIN语句的灵活性会大很多。另外提醒一个细节所有表的主键ID统一用自增整数类型用BIGINT别用INT。数据量虽然不大但BIGINT的容量更宽裕而且有些框架映射的时候对INT和LONG的处理要求统一BIGINT能避免映射类型不一致的坑。时间字段建议用DATETIME统一存服务器本地时间别用字符串存日期否则排序和比较大小都是隐患。2.3 初始化数据的技巧让系统跑起来就像真的答辩效果好不好很大程度取决于演示时页面有没有“内容感”。一个空荡荡的系统从首页到后台都只有几条测试数据评委一眼就觉得敷衍。所以务必要在数据库初始化脚本里塞几十条高质量的家乡美食数据包含完整的简介、标签、地区归属、封面图和评分。数据从哪里来真实来源有很多渠道但不要直接用网上别人整理好的大段文本最好自己仿写精简版。每条美食数据要写清楚特色标签比如“松鼠桂鱼”标签是“苏菜、酸甜、宴席”“螺蛳粉”标签是“桂菜、酸辣、街边小吃”这样推荐算法才有有效输入。封面图可以去免费图库网站找对应风格的图片下载后放到项目的静态资源目录下路径存相对路径别存完整网络地址否则部署后图片挂掉就非常尴尬。3. 后端接口设计SSM框架下的分层实现3.1 项目目录结构与依赖配置先看项目目录的规划思路。SSM项目建议按以下分包结构组织这也是最常见的约定俗成规范controller接收前端请求做参数校验和结果封装service写业务逻辑事务控制在这一层mapper定义MyBatis的接口方法entity数据库实体类字段与表结构对应vo视图对象专门用于向前端返回数据避免把实体直接暴露出去common统一返回结果、异常处理、工具类config配置类比如拦截器、跨域配置写代码之前先在pom.xml里把依赖加全否则后面缺包报错会让你怀疑人生。核心依赖包括Spring相关、Spring MVC相关、MyBatis核心包、MyBatis-Spring整合包、MySQL驱动、Druid连接池、Jackson处理JSON、Lombok减少getter/setter模板代码。特别注意Lombok在使用JDK新版的时候容易遇到注解处理器不兼容的问题如果编译报错找不到getter方法先把Lombok版本升级到最新再检查IDE的注解处理开关是否打开。还有一个经常被忽略的问题SSM项目如果用Maven打包成war包部署在Tomcat要把Tomcat的Servlet依赖作用域设为provided否则打包时会和Tomcat自带的Servlet API冲突导致启动时报错。这些细节看起来不起眼但踩到一次就是半小时起步。3.2 统一返回结果与全局异常处理前后端分离的项目最忌讳每个接口的返回格式各写各的。前端拿到一个接口返回数组、另一个接口返回{data: xxx}判断逻辑就得写一堆if分支特别容易出bug。建议从第一天就定一个统一的返回结构比如这样{ code: 200, message: success, data: { ... } }在后端定义一个Result类所有Controller方法的返回类型都用它内部通过静态方法快速生成成功或失败的结果。这样前端用Axios的时候只需要拦截response判断code是否为200就能决定走成功逻辑还是错误逻辑Axios的响应拦截器里统一写一次就够代码会干净很多。全局异常处理同样重要。Controller里不需要到处写try-catch只需要实现一个全局异常拦截器用RestControllerAdvice注解标注配置ExceptionHandler来处理不同异常类型。这样做的好处是Service层抛出业务异常时比如“资料不存在”或者“参数非法”全局拦截器会统一捕获返回一个业务码和错误信息前端能直接弹提示后端代码也不会被异常处理淹没。3.3 JWT登录鉴权的实现与原理登录鉴权是答辩必问点也是做这部分时需要重点理解的内容。SSM项目里传统的做法是用Session但前后端分离后推荐使用JWTJSON Web Token。原理是用户登录成功后后端生成一个包含用户ID、用户名、过期时间的Token字符串返回给前端前端把Token存在本地存储中后续每次请求都在请求头里带上Authorization字段。后端在服务端过滤器中校验Token的签名和有效期通过则放行不通过则返回401。JWT的核心价值在于无状态服务端不需要存储Session因此很方便做横向扩展。毕业设计阶段可以把JWT工具类写在common包里封装生成和校验两个方法。校验逻辑用拦截器实现路径上配置多个拦截规则例如用户相关的接口需要登录才能访问管理员相关接口需要校验角色。要注意的坑有两个第一前端拿到Token后每次请求都必须在Axios的请求拦截器中把它添加到请求头如果忘了配置后端会一直401排查时很容易走弯路。第二Token过期时间别设太短建议24小时否则演示到一半过期了那场面相当尴尬。还有一个细节修改密码或者管理员封禁用户时只更新数据库状态是不够的因为旧的Token可能还在有效期内更适合的做法是把用户的Token版本号写入数据库中校验时做对比版本不一致就拒绝这样才算是真正实现了强制下线。3.4 美食模块的查询与分页搜索实现美食列表接口是访问最频繁的接口支持按地区、分类、关键词、标签条件组合筛选并且要做分页返回。MyBatis里最方便的做法是使用PageHelper插件只需简单的几行代码就能完成物理分页PageHelper.startPage(pageNum, pageSize); ListFoodVO list foodMapper.selectFoodList(query); PageInfoFoodVO pageInfo new PageInfo(list);PageHelper的原理是拦截即将执行的SQL自动拼接LIMIT语句所以使用时要特别注意startPage之后紧跟的那条查询必须是你需要分页的查询中间不能穿插其他查询否则分页会作用在错误的SQL上导致数据混乱。还有一种常见的坑是在循环里调用分页查询由于PageHelper存在线程复用问题上一次分页参数会意外地带入下一次查询中导致结果异常。如果不想额外引入一个插件也可以手动编写分页通过查询总记录数和LIMIT两个参数算出分页结果用Map封装返回。这个方法虽然代码多一些但不容易出隐含问题对掌握基础SQL更有利。考虑到答辩时可能被问“分页是怎么实现的”建议两者都懂至少能讲清楚LIMIT offset, size的含义。搜索功能在美食名称和简介字段上使用LIKE模糊查询关键词用前端传来的query参数拼接。如果希望搜索更“智能”一点可以加一个简单的分词逻辑把关键词按空格拆成多个词每个词分别在所有字段里做LIKE匹配以OR条件连接匹配条件越多排序时权重越高。这种方案不需要引入搜索引擎就能给人一种“搜索还考虑了相关性”的感觉答辩时是个加分项。4. 推荐算法的设计与实现细节4.1 基于内容匹配的推荐从标签相似度开始内容推荐是整套推荐策略的第一层也是最容易解释、最不容易出逻辑错误的一层。核心思想很简单用户注册时选了偏好标签系统把这些标签与美食特征标签做匹配匹配越多得分越高。比如用户偏好是“辣、肉、面食”那么“重庆小面”标签是“辣、面食”匹配了两个标签得分2而“松鼠桂鱼”标签是“酸甜、苏菜”匹配零个得分0推荐排序时自然落在后面。实现上推荐得分可以按以下公式计算contentScore (用户偏好集合与美食标签集合的交集大小 / 用户偏好集合大小) * 40这公式本质是相似度偏好标签参与匹配的命中率越高得分越高。计算时用户偏好和美食标签都以逗号分隔字符串存在字段中在Java里拆分成数组再取交集纯内存计算速度快也不用写复杂SQL。数据量在几千条以内的时候直接全量遍历计算完全没问题。这个方案的优点是逻辑透明答辩时评委问“为什么给这个用户推荐这道菜”你能直接回答出“因为他的辣和面食偏好与重庆小面的标签匹配”有具体依据而不是说“算法算出来的”。4.2 基于用户的协同过滤找口味相近的人单靠内容推荐有个明显缺陷它只会推荐用户已知类型的食物缺少意外惊喜。协同过滤的价值就是引入“其他人的选择”来做推荐核心逻辑是找到与当前用户行为最相似的一批用户看看这批人还喜欢什么但当前用户没吃过就把它们挖出来推荐。行为相似度的计算基础是收藏和评分数据。先取出当前用户的收藏美食ID集合和评分记录再找出收藏过相同美食的其他用户再以Jaccard相似度公式或余弦相似度计算两个用户的相似程度。Jaccard相似度公式是交集元素数除以并集元素数。比如用户A收藏了{x, y, z}用户B收藏了{y, z, w}交集是{y, z}大小为2并集是{x, y, z, w}大小为4相似度就是2/40.5。计算量不大但逻辑严谨。得到相似用户集合后把他们收藏的美食汇总去掉当前用户已经收藏过的按相似度加权累加得分得到协同过滤部分的推荐得分。这里要注意一个细节只计算相似用户收藏而当前用户没收藏的美食权重是“相似度 × 该美食的收藏人数”避免某些过于热门的美食在推荐池中喧宾夺主导致推荐结果全是大众菜而失去个性化。4.3 混合推荐加权融合与冷启动处理将内容匹配分和协同过滤分结合最终推荐得分为finalScore contentScore * 0.5 collaborativeScore * 0.3 baseHotScore * 0.2三项权重加起来为1其中内容匹配分权重最大原因在于冷启动阶段用户几乎没有收藏和评分数据协同过滤得分几乎为零更多要依靠内容匹配与基础热度来兜底。基础热度分可以按以下公式估算baseHotScore (收藏量 * 0.6 平均评分 * 0.4) / 10 * 30这段公式的含义是用收藏量表示受欢迎程度用平均评分表示质量口碑两者合成一个0~30的分数。因为评分一般按5分制来算所以用除以10缩放到0~30。如果你的评分总分是10分制那这里要相应地调整分母这是答辩时一个值得明确说明的细节。冷启动是推荐系统绕不开的话题。新用户没有行为数据协同过滤失效这时推荐结果主要靠内容匹配和热度兜底相当于一个“热门家乡美食榜单”。为了缓解冷启动问题可以在注册环节让用户选择偏好标签并且给用户推荐几道标签匹配度最高的代表性美食引导用户产生第一批收藏行为。这套设计虽然朴素但很好地体现了“冷启动”意识答辩时能体现系统性的思考。4.4 推荐接口实现与排序策略后端推荐接口建议放在一个独立的FoodRecommendController中路径为 /api/recommend/list。接收当前登录用户的ID以及可选的地区ID、分类ID参数返回列表。实现的步骤比较清晰先取出用户偏好标签再计算内容匹配分再取出相似用户计算协同过滤分再取出基础热度分最后按finalScore倒序排列取前20条返回。前端拿到推荐结果后在首页推荐区域进行渲染。注意一下用户体验每次刷新页面重新请求推荐接口而我建议给推荐结果加一个简单的缓存比如用户在同一会话内第一次请求时计算并存储后续直接从缓存读取。实现的方式很多最简单的就是用HashMap以用户ID为key存结果设置有效期5分钟。这样既能控制数据库压力也能避免刷新太快导致推荐内容剧烈跳动用户在页面上的体验会更稳定。排序策略上还有一个细节值得注意如果两道菜的finalScore非常接近比如差距小于0.5分就应该用基础热度值更高的那个排前面这样会让推荐列表看上去更合理。这个排序权重调整的逻辑在答辩时随口讲出来会让人感觉你真的考虑过这些问题而不是只背了算法名字。5. Vue前端页面的核心实现5.1 前端项目结构与路由设计Vue项目用vue-cli或Vite初始化建议采用以下基础目录结构views页面组件每个路由对应一个页面router路由配置与导航守卫api接口请求封装按模块拆分store客户端状态管理用户登录信息components公共组件如导航栏、美食卡片等路由设计要区分用户端和管理员端。用户端页面包括首页推荐列表、美食列表页、美食详情页、个人中心我的收藏、我的评分、个人信息修改。管理员端包括登录页、数据概览页、美食管理、分类管理、地区管理、用户管理。前端实现上有几个重点细节。第一登录状态通过router.beforeEach导航守卫控制路由此为受保护的路由则检查store里是否有Token没有就跳转到登录页。第二管理员路由需要在导航守卫中加一层角色判断因为用户和管理员登录后看到的界面完全不同。第三Axios统一在src/api/request.js封装创建实例时配置baseURL和请求拦截器使用响应拦截器统一处理错误码。这样做的好处是如果后端把接口地址统一加前缀不用改任何页面组件。5.2 美食卡片组件与首页推荐展示首页是最容易让人眼前一亮的部分。整个页面结构建议从上到下顶部导航栏、地区/分类筛选栏、推荐区块标题写“为你推荐”、热门美食榜单区块、最新上架区块。美食卡片组件是首页的核心复用组件属性包括美食对象数据展示封面图、名称、分类、地区标签、评分和收藏按钮。收藏按钮的交互要注意点击后立刻调用收藏接口成功则把按钮状态切换为已收藏并且做一次动画反馈。如果未登录则弹出登录确认框引导用户跳转到登录页不能只是静默失败。推荐结果的展示建议加一点“个性化”的提示文案比如进入首页时显示“根据你的口味偏好为你精选以下家乡美食”。这个小细节在答辩时效果非常直接评委能一眼看出推荐是关联了用户偏好来个性化的。反之如果接口返回的结果跟游客看到的热门列表一模一样就很难体现系统的推荐能力就是一个硬伤。5.3 后台管理页面列表、表单与图片上传后台管理页面虽然业务功能简单但页面交互要做好因为这是展示你“工程能力”最好的地方。美食管理页面用Element UI的el-table展示数据配合el-pagination分页每个记录提供编辑和删除按钮。删除操作必须用弹窗二次确认不要直接删除一方面是防止手误另一方面这也是一个容易被问到的交互设计点答“防止误操作造成不可逆数据损失”就够了。美食管理的新增/编辑表单字段比较多建议用el-form配合表单验证规则。特别指出编号旁边做图片上传控件使用Element UI的el-upload组件action属性指向后端图片上传接口。上传成功后接口返回图片路径前端把路径存进表单字段提交时和表单其他数据一起发送。图片预览功能可以通过on-success回调中刷新图片列表来实现。这里有一个很关键的坑后端的图片上传接口通常要求请求头带有Token才能通过登录拦截器而el-upload组件默认不会自动附带自定义请求头。解决办法是在组件里使用:headers属性动态绑定一个对象把Token带上去。否则一定会出现上传401或者权限错误这是前端联调阶段最常见的坑之一。6. 常见问题与排查技巧实录6.1 跨域、图片404与页面白屏前后端分离项目联调时跨域问题会第一个找上你。推荐的做法是在后端写一个跨域配置类实现WebMvcConfigurer接口重写addCorsMappings方法把所有路径都允许跨域访问并且允许携带Token的自定义请求头。也可以使用CORS过滤器两种方式二选一效果一样。配置好跨域后再遇到接口返回不了数据可以按以下顺序排查前端F12打开Network面板看请求是否已发出→看状态码是404还是500→看响应内容是否是预期的JSON结构→看Console有没有报错信息。404通常是路径写错500通常是后端代码抛异常响应内容不对则是前后端字段字段不匹配。有一种非常隐蔽的坑后端实体类里用了Lombok的Data注解但前端要求返回的字段名是驼峰命名而数据库字段是下划线命名如果MyBatis没有开启mapUnderscoreToCamelCase配置返回的JSON字段会变成下划线形式前端el-table的prop就取不到值表格一片空白。解决办法是在MyBatis全局配置中开启驼峰映射或者在SQL里为字段起与实体相对应的别名。页面白屏的另一个常见原因是静态资源路径有问题。Vue打包后部署到Tomcat的webapps/ROOT目录下如果访问页面时CSS和JS加载不出来多半是publicPath配置错误。在vue.config.js里把publicPath设为‘./’相对路径这样打包后的资源路径就能适配不同部署目录而不是写死绝对路径。6.2 JWT过期、权限不足与登录态失效演示现场突然弹出登录过期是每个做这种项目的人最怕遇到的事故。Token过期时间是后端设置的如果设太短现场出问题的概率就高建议把过期时间设置为24小时以上演示前后再重新登录一次确保Token是新的。还有一个容易被忽视的权限控制问题普通用户直接手动输入管理员页面的URL如果后端没有做角色校验他也能访问到管理接口这是重大的安全隐患。后端的做法是在WebMvcConfigurer里注册拦截器时配置路径规则除了排除登录、注册、首页浏览等公共接口外所有 /api/admin/ 开头的接口必须有管理员角色才能访问。前端也要同步处理在导航守卫里判断store中保存的角色信息非管理员跳转到首页并弹提示。前后端双重校验才算是把权限控制做好了。排查登录态失效时我的经验是先看请求头的Authorization有没有正确携带再看后端拦截器里有没有排除路径的Bug最后检查JWT密钥是否一致。如果前端所有请求都成功但页面数据不更新可以优先考虑是不是缓存问题刷新浏览器或清除本地存储再试一次。6.3 数据库乱码、时区错误与连接数不足数据库相关的问题在SSM项目中也非常常见。第一类是中文乱码。出现乱码时按三层排查数据库连接URL是否配置了characterEncodingutf-8MySQL数据库本身的默认字符集是否是utf8mb4以及前端页面声明和响应头Content-Type是否正确。有时候前端显示正常但数据库存的是乱码多半是连接URL没加参数或表是latin1字符集这是最需要一劳永逸解决的问题。第二类是时区问题。MySQL 8.x版本对时区比较敏感如果连接URL没有serverTimezone参数驱动会默认使用服务器系统时区可能产生8小时偏差或者直接报错。推荐在连接URL中明确指定serverTimezoneAsia/Shanghai同时数据库字段用DATETIME类型前后端时间传输统一以字符串格式处理避免JS的Date对象和Java时间戳互转时出现时区混乱。第三类是连接池配置。Tomcat默认的并发线程数可能不够用大量并发请求同时进来后数据库连接会被打满报错信息类似“Too many connections”。解决办法是在Druid配置里把最大连接数调大同时设置合理的等待超时时间。虽然毕设系统的实际并发量不会高到触发这个问题但答辩时问到性能测试能答出这个层面的调优思路总比一问三不知强。6.4 推荐结果不理想时的调试思路如果你的推荐接口返回的数据看起来不合理比如用户偏好是“辣”却推荐了甜点不要急着怀疑算法按以下顺序排查。先看用户偏好字段是否真的存进去了注册时勾选偏好后到数据库里查一眼许多所谓“推荐结果不对”的问题其实根源是用户根本没有写入偏好标签一看字段是空的那算法自然也就无从算起。其次检查美食的标签字段是否为空。后台新增的大多数美食可能都忘了填标签而标签为空的美食在内容匹配阶段得分为0最后排到很后面甚至不出现这会让推荐列表显得很奇怪。为美食条目补全可靠的高质量标签是推荐效果变化最明显的手段。最后检查协同过滤部分是否拿不到相似用户。新系统一开始没有收藏数据协同过滤得分显然始终是0。调试时可以先用一个测试账号手工收藏和评分十道菜再去看推荐接口的输出确认协同过滤真的起了作用。给测试账号制造足够的反馈数据再调试算法才能判断是哪一层的逻辑出了问题。7. 安全加固与部署注意事项7.1 密码存储与低代码安全隐患密码不能明文存数据库这是毕业设计要求里最基础的规范。用BCrypt哈希算法对密码做加密处理是合适的做法加密后的密码即使数据库被拖库也无法反推出原始密码这是它比特定加密算法的优势所在。思路是用户在注册时系统把用户明文密码交给BCrypt生成一个带随机盐的哈希字符串之后存储这个哈希值登录时用相同算法重新计算哈希值匹配才允许通过。由于是带盐的哈希即使两个用户密码一样存储的哈希串也不同破解成本也大大增加。请注意避免一种低级的“加密”实现在Java代码里写一个固定的字符串拼接方式去“混淆”密码比如密码前后加个固定前缀再去Base64编码。这类方式本质上是可逆的而且哈希思路也站不住脚答辩时被问到“安全性怎么设计”就只能尴尬。BCrypt的依赖引入和用法都很简单网上有大量针对当前项目依赖体系的示例自己改造并理解其中的安全价值即可。另一个常见安全隐患是SQL注入。MyBatis使用#{}占位符时MyBatis会把它编译成预处理语句的占位符参数值被视为纯数据因此是安全的。但如果你图方便在SQL里用了${}来拼接参数那参数就会直接拼进SQL语句存在SQL注入风险。项目中一定要检查所有Mapper XML和动态SQL写法如果发现某处用了${}要么改成#{}要么对传入参数做白名单校验把可枚举的值限制在安全集合内。7.2 XSS防御与前端输入校验前后端分离之后XSS攻击的风险主要来自两个方面一是用户提交的内容没有做HTML标签转义就直接存库二是前端渲染时直接把用户提交内容当HTML插入了。防范的办法不复杂后端在接收请求参数时统一做HTML字符转义把、、等特殊字符转成实体格式前端Vue默认的插值语法本身就做了转义处理只要你不是故意用v-html渲染用户提交的内容大多数XSS都不会成立。登录注册等表单场景也需要在前端做输入校验比如用户名长度限制、密码强度校验、手机号格式校验等使用Element UI自带规则即可。但后端不能依赖前端校验接口层面仍然要做非空和长度校验这样即使有人绕过页面直接调用接口也无法写入脏数据。这一点在所有项目中都是一条通识规则你在给某个模块写校验逻辑时不妨多花几分钟做一套一致的后端校验答辩时讲“前后端双重校验”很有说服力。7.3 部署流程从本地到服务器的完整步骤部署阶段建议把项目打包成war包部署到Tomcat因为SSM默认就是war模式步骤简单、问题少。在pom.xml里把打包方式配置为war并设定项目最终名称为food然后执行mvn clean package生成war文件。把war文件扔到Tomcat的webapps目录下启动Tomcat时它会自动解压。前端部分需要先执行npm run build进行打包生成dist目录把dist下的所有文件上传到Tomcat的webapps/ROOT目录下或者放在与后端同域名的某个路径下。后端接口地址取决于你打包时配置的baseURL如果前端和后端不在同一个端口要在Vue环境变量里配置好后端服务地址并在开发时通过代理的方式解决跨域。数据库部署很关键的一点是字符集。在服务器上创建数据库时建议指定utf8mb4字符集因为utf8mb4能完整覆盖emoji和生僻字等特殊字符而utf8mb3不支持。导入sql脚本前务必确认脚本内的表结构和数据都使用utf8mb4否则上服务器后又会冒出一堆乱码。7.4 日志记录与异常信息脱敏日志的作用平时不起眼但排查问题时价值极高这不是可有可无的点位。推荐用Slf4j加上一个日志实现来统一管理日志配置把框架启动信息、SQL执行记录、业务操作记录分目录输出。具体到本项目用户登录成功/失败、管理员增删改美食、用户收藏美食这些关键操作都建议打上日志格式包含操作者ID和操作时间。演示现场如果真出了什么异常看一眼日志就能定位到具体接口和数据比在代码里一点一点加System.out.println高效太多。日志输出时还需要注意隐私脱敏问题。用户手机号、邮箱、密码加密串这类敏感字段在日志里要么不输出要么做掩码脱敏比如把手机号中间四位用*号代替。这不是过度设计而是把自己当成一位真正在做项目的工作人员来考虑问题会自然注重的细节写文档和答辩都会更有说服力。8. 答辩准备与项目亮点提炼8.1 如何用“问题-方案-效果”结构讲项目答辩时最忌讳照着代码从头讲到尾页面密密麻麻的操作演示评委很容易听烦躁。更好的结构是“问题—方案—效果”先讲这个系统要解决什么问题用户面对海量家乡美食缺乏个性化和高效的发现途径再讲你用什么方案解决搭建了基于标签与评分行为数据的混合推荐机制、管理后台操作更清晰高效最后用演示或者数据说明效果推荐列表会根据用户偏好变化收藏和评分越多推荐越准确。这种讲述方式有强烈的逻辑主线评委可以很自然地抓住你的设计思路不会迷失在代码细节里。每个页面、每张表、每个算法都可以对应到这个框架下去回答整个汇报就会非常有层次感。记住毕业设计答辩真正考查的是你“能不能把事情讲清楚”而不是你“写了多少行代码”。8.2 三个评委会追问的高频问题与标准回答第一个问题一定是“为什么选择SSM而不选Spring Boot”。回答时不要贬低Spring Boot而要说SSM是经典的Java Web技术栈能更好地展示你对核心框架原理的理解同时SSM的配置过程让我熟悉了Spring核心装配机制在这种传统XML配置方式下的运作将来切换到Spring Boot时对它的起步依赖和自动配置也会有更直观的体会。这样回答既客观又显得你有技术深度。第二个问题是“推荐算法如果数据量大后性能下降怎么办”。回答思路是现阶段数据规模下全量内存计算成本可接受但为了可扩展性可以把推荐结果缓存到Redis并设计定时任务每日离线计算一次用户推荐结果在线推荐时直接读缓存。这个回答展示了性能意识和工程化思维。哪怕你实际没做Redis这么回答也完全OK因为这是合理的演进方向。第三个问题是“这个系统和普通美食展示网站的区别在哪里”。这个问的是差异化。回答要点是本系统有完整的用户行为链路收藏、评分和有机结合两种推荐策略的混合推荐机制不只是展示美食而是让系统主动理解用户的口味偏好并随着用户行为越来越懂用户。最好能把先做出来的推荐结果图表展示给评委比如不同偏好用户的首屏推荐是不同的这个实证远比空讲区别更有说服力。8.3 上线前最后检查清单快交稿前按这份清单再从头检查一遍能避开很多低级失误。数据库初始化脚本能否一键执行成功服务器上一个干净环境能否顺利跑起来包括新注册用户能否正常登录、首页是否正常出推荐、能否收藏和评分、管理员的增删改操作是否正常、推荐结果是否与用户偏好匹配、刷新后状态是否一致。再看安全方面密码是否加密存储、接口是否有权限控制、SQL是否使用预处理参数。再看代码细节是否有硬编码数据库连接信息、是否有未处理的异常直接抛给了前端、控制台是否还有一堆System.out.println。如果每一条都过审了这个系统基本就算立住了。最后建议给自己的系统录一段5分钟以内的演示视频覆盖注册、浏览、收藏、评分、管理后台操作、推荐结果变化这条完整链路。这份视频跟部署文档一起放进项目压缩包里无论是老师检查还是自己临时补交材料都会留一份非常周全的印象。9. 扩展方向从毕业设计到真实作品这部分内容其实是被很多同学忽略但最有价值的延伸思考。如果你想让项目在分组答辩中显得不一样或者毕业之后想把这段经历写进简历可以在这几个方向里选一个做深。第一推荐算法升级为实时反馈机制。目前用户对推荐结果的反馈只有收藏和评分可以增加“浏览时长”“点击率”这类隐式反馈信号在食物详情页停留超过一定时间就自动增加对应标签的权重。这个思路实现难度不高但效果显眼因为它把推荐系统的数据来源从单一行为变成了多样化用户反馈能发现有趣的口味倾向。第二引入基于协同过滤的“相似菜”功能。在美食详情页下方增加“喜欢这道家乡菜的常人也喜欢”区块逻辑就是协同过滤的结果单独呈现。这样做的好处是在详情页体现推荐算法的存在感而不是只在首页展示一个推荐列表技术深度看起来立刻丰富了一档。第三补充基于地区维度的统计分析。系统已经有了地区表和地区ID字段完全可以增加一个地区特色统计接口按地区汇总美食数量、平均评分、热门标签然后用图标插件展示“家乡美味地图”。从应用角度看这让系统从“导游工具”升级为“家乡文化数据看板”从数据看也有更多可展示的价值与趣味性。我个人在实际带这类项目时的体会是一个毕业设计最终拿到多少分往往不取决于它用了多少新技术而取决于你对“自己写的东西”理解有多深。如果你能指着推荐结果随口说出它的设计逻辑、指着某个异常报错说出根因和修复思路那评委心中的印象分就已经上去了。这套“家乡特色美食推荐系统”的好处恰恰在于它的业务场景亲切、技术链路完整特别容易做出既有温度又有亮点的作品。希望这轮拆解能给你实际动手过程省些事也祝你答辩顺顺利利、一问一个准。