1. 项目从选题到落地一篇美食推荐小程序毕业设计的完整拆解每年的毕业季计算机专业的同学都会面临同一个灵魂拷问毕业设计到底做什么题如果去翻一下过去几届的选题表你会发现一个常年霸榜的方向——微信小程序。再往细了分美食推荐、外卖点餐、校园服务、二手交易这类“生活服务类小程序”又是出镜率最高的一批。为什么大家都爱选这个方向说白了就三个字好落地。微信小程序生态成熟前端界面用组件堆叠就能完成后端可以选Spring Boot、Node.js甚至直接用微信云开发数据量不大但能体现完整的业务逻辑评阅老师想考察的知识点——增删改查、接口设计、数据库建模、权限控制——全都能覆盖到。更重要的是答辩演示的时候拿着手机就能操作比在电脑上敲命令行的项目直观太多。这个题目我前前后后带过不少学生做过也帮人改过不少“跑不起来”的源码。今天这篇就把我实际操盘过程中的经验完整的梳理一遍。我会按一个真实项目的推进节奏来写从需求拆解和文档撰写方法到技术选型为什么这样定再到小程序端各个页面的实现细节、后端接口如何设计、数据库字段如何规划最后把答辩时最容易翻车的几个问题也一并列出来给你打个预防针。先说清楚这个东西到底能做什么、适合谁。一套完整的基于微信的美食推荐小程序核心用户是两类角色普通用户和平台管理员。普通用户打开小程序可以看到推荐的美食列表按分类浏览搜索店铺或菜品查看详情收藏心仪的店铺也可以对吃过的店铺做评价管理员端则负责审核店铺信息、管理分类、处理用户反馈、维护推荐位的内容。听着好像功能不多但真正把它拆开涉及的技术点包括小程序页面生命周期、组件通信、缓存策略、后端接口的路由与鉴权、MySQL表结构合理性、图片上传与回显、列表分页与搜索关键字匹配等等。任何一个环节偷工减料都会在答辩演示或者代码审查环节被逮住。所以这个题目真正适合的人群是有一定编程基础至少能独立写出一个完整前后端交互流程的同学想通过一个综合性项目来验证自己的工程能力。如果你真的是零基础想混一个毕设那这篇文章可能救不了你但你至少能看懂我后面说的每一步知道哪些坑是绝对不能踩的。这篇文章的信息密度会比较大我会直接把我在实际开发中摸索出来的细节、参数、避坑经验都摊开讲。有些地方我会直接给出表结构定义和接口路径设计你可以直接抄作业。但我也坦白讲代码层面的具体每一行不会全部贴出来真照着敲完工作量太大我会把最关键的逻辑和容易写错的点拿出来说透。2. 需求拆解与方案选型为什么你的小程序“一看就是毕设”2.1 功能需求的优先级划分很多人拿到这种题目第一反应就是打开微信开发者工具开始敲代码。这是最致命的错误。我见过太多学生花了两个月写代码最后写出来的东西逻辑一团糟文档更是无从下笔。正确的顺序是先把需求理清楚再谈技术实现。美食推荐小程序的需求按照优先级可以这样划分第一优先级必须有否则功能不完整是用户端的信息浏览链路。也就是说小程序能打开、能加载列表、能看详情、能搜索。这一条链路把前端页面、后端接口、数据库三块串起来了是整个系统的主干。第二优先级必须有但可以简化实现是用户互动功能比如收藏、点赞、评论、个人中心。这些功能是体现“用户体系”的证明答辩时老师几乎一定会问到“用户登录后有什么个性化功能”。第三优先级加分项有时间和精力再做是推荐逻辑的差异化比如根据用户的收藏偏好做推荐排序、根据浏览历史打标签。这里我建议的划分方式不是功能多少而是业务闭环。美食推荐小程序本质上是“找店”的工具所以用户从打开到找到心仪的店铺这一整条路径必须畅通。你看那些高分毕业设计往往不是功能堆得最多的而是主干功能做得最扎实的。2.2 技术选型的三个关键决策技术选型是整个项目里最值得花时间想清楚的部分因为它直接决定了你后面编码的难度和文档的篇幅。我先说结论小程序端用原生微信小程序框架后端用Spring Boot加MyBatis Plus数据库用MySQL 8.x这是目前最主流的组合也是答辩老师最熟悉的组合。为什么不建议用uniapp如果你已经熟练掌握了uniapp那你用它没问题。但如果你是为了毕设临时去学我劝你慎重。uniapp的跨端能力是它的卖点但跨端也意味着你要额外处理各端差异的兼容性问题而且原生小程序里很多api直接用就行uniapp里要绕一层封装。毕业设计追求的是“在有限时间内把系统做扎实”不是展示你掌握多少框架。原生小程序的学习资料最多报错搜索引擎上一查就有答案这是最大的隐性优势。后端为什么选Java而不是Node.js答案很简单计算机专业的课程体系里Java是主语言评阅老师默认你Java学得比Node.js好。你用一个冷门技术栈除非做到惊艳否则在评分上吃亏。Java后端配上Spring Boot的自动配置开发效率并不低而且Spring Boot全家桶的知识点写在论文里看着就充实。MyBatis Plus这个东西在毕设圈子里口碑两极分化——有人觉得它封装太多显不出水平有人觉得它省事到起飞。我的态度很明确用但要用得有节制。简单的单表查询可以用它的内置方法比如根据id查详情、按条件查列表多表关联的复杂查询自己写SQL然后你可以在论文里单独列一小节“基于MyBatis Plus与XML自定义SQL的混合持久层设计”显得你既懂框架又懂SQL。第三个决策是前端和后端的交互方式。这里我强烈建议使用RESTful风格接口加JSON数据格式。不要搞什么WebSocket长连接更不要在小程序端直接拼SQL。前后端分离的架构模式虽然初始搭建的时候要多写一些代码但换来的是逻辑清晰和可扩展性而且现在主流开发模式就是这样写进文档里是加分项。2.3 功能模块划分与页面结构规划我觉得可以把整个小程序想象成一家餐厅小程序端是食客看到的门面和菜单后端是后厨的备菜和炒菜流程数据库则是储藏室的食材清单。这三者各自独立但又通过点餐接口调用串联起来。按照这个思路小程序端的页面结构可以这样规划首页index轮播图推荐位、分类快捷入口、附近热门店铺列表。这是用户进入后看到的第一个页面要做的第一件事就是让它能用最少的点击触达核心内容。我的设计是顶部搜索框直接嵌入首页下面是分类栏和推荐列表。轮播图放三张活动图后面绑定跳转到对应的店铺详情或活动专题页。分类页category左侧是一级分类列表中餐、西餐、火锅、日料、小吃快餐、甜品饮品右侧是分类下的店铺列表。搜索页search关键词搜索店铺名称、菜品名称也可以按分类或评分筛选。店铺详情页detail店铺基本信息、评分、人均消费、地址、联系电话、营业时间、相册、用户评价列表。个人中心页mine用户头像昵称展示、我的收藏、我的评价、浏览记录、意见反馈入口。管理后台Web端管理界面账号密码登录负责管理店铺、分类、用户、评论和推荐位内容。这里你可以用比较简单的Bootstrap加Thymeleaf模板实现也可以用Vue加ElementUI看你前端功力。页面规划成文档的时候建议配一张简单的功能结构图手画也行画图软件也行把用户端和管理端的功能分支画清楚。这一张图写进文档里直接就能撑起“系统功能设计”这一章节的半壁江山。3. 数据库设计与后端接口这层地基打的有多扎实直接决定答辩能否过关3.1 核心表结构与字段设计数据库设计往往是评审老师看得最仔细的部分。为什么因为表结构能直接反映你对业务理解的深度。很多学生喜欢不分青红皂白一张表存所有东西字段能省则省最后对于复杂的业务逻辑就只能写一堆别扭的代码去绕。我这里直接给出核心表的设计方案你可以根据实际需要增减。第一张表是用户表user。字段设计id为主键自增openid是微信登录的唯一标识这个字段必须加唯一索引因为一个用户可以多次登录但只能用一条记录你不想判重的时候全表扫描。nickname、avatar_url存用户昵称和头像这两项在微信授权时可以拿到。还有create_time和statusstatus用于标记账号状态正常、禁用管理员封号的时候用得上。第二张表是店铺表shop。这条表是整个系统里字段最丰富的。id主键shop_name店铺名称category_id关联分类表shop_img封面图URLscore综合评分avg_price人均消费address具体地址phone联系电话business_hours营业时间。还有一个关键字段status用于控制店铺的上架下架状态。这里我在实际开发中遇到的一个问题是很多人喜欢把店铺描述和推荐语直接塞进一个text字段里结果列表页加载的时候也给带出来导致接口响应变慢。我的建议是列表页需要的字段名称、封面、评分、人均价、分类单独查详情页需要的字段地址、电话、营业时间、描述再单独查一次虽然不是最优方案但足够清晰。第三张表是分类表category字段最简单id、name、sort_order排序权重可能还有一个icon图标字段用于在分类栏展示小图标。第四张表是评价表comment关联user_id和shop_idcontent评价内容score评分数值images评价图片可以是以逗号分隔的URL串也可以单独建一张图片表但简单起见用逗号分隔就行create_time。第五张表是收藏表favorite关联user_id和shop_idcreate_time。这里要注意的是user_id加shop_id要建联合唯一索引防止用户反复收藏同一条记录。如果要支持浏览记录功能可以再建一张history表结构类似收藏表区别是每次访问详情页时更新访问时间。我建议你在文档里给每张表配一个字段说明表格字段名、类型、是否为空、默认值、说明文字。不要偷懒这一部分的篇幅写起来很可观而且答辩时随便指一个字段问你为什么这么设计你都能答上来。3.2 接口路径设计与统一返回格式后端接口设计有一个容易踩的坑返回的数据结构不统一。有的接口返回字符串有的返回数组有的直接在data里放对象。前端解析的时候就得各种判空代码写得很痛苦文档也写得稀碎。我这里统一给出一个规范所有接口返回JSON对象结构为code、message、data三层。code为0表示成功非0表示各类异常message为提示信息data是实际数据可以是一个对象、数组也可以是空。成功时code为0失败时code对应具体的错误码10001参数错误10002未登录10003无权限50000服务器内部错误。核心接口路径设计如下微信登录授权POST/api/user/login前端传codewx.login获取的临时凭证后端用这个code向微信接口换取openid如果用户首次登录则创建用户记录返回token和用户信息。获取首页推荐数据GET/api/shop/recommend返回轮播图列表和推荐店铺列表。获取分类列表GET/api/category/list。按分类获取店铺GET/api/shop/list参数categoryId、page、pageSize。搜索店铺GET/api/shop/search参数keyword、page、pageSize。获取店铺详情GET/api/shop/detail/{shopId}参数带路径上同时传userId用于判断该用户是否已收藏此店铺。提交评价POST/api/comment/add参数shopId、content、score、images。获取店铺评价列表GET/api/comment/list参数shopId、page、pageSize。收藏与取消收藏POST/api/favorite/toggle参数shopId。获取我的收藏列表GET/api/favorite/list参数page、pageSize后端从token解析用户id。这些接口的设计思路都是围绕一个原则小程序端只负责展示和收集用户操作所有业务逻辑权限校验、数据组装、异常捕获都在后端完成。这也是答辩时的核心论点之一——你是一个前后端分离的系统。3.3 缓存策略与性能优化的几种可行方案美食类小程序和电商类小程序相比有一个天然的优势数据更新频率极低。一个店铺的开业信息、评分、人均价格可能一周都不会变一次。这就意味着缓存策略在这里有非常大的发挥空间。我自己实际用过并且觉得适合毕设场景的有三个方案。第一个方案是最简单的在小程序端用wx.setStorageSync做本地缓存。以店铺列表为例页面加载时先读缓存如果有数据并且未过期就直接渲染否则请求接口并写入新缓存。这种做法的好处是零后端成本而且确实能优化加载速度。但坏处也很明显代码分散在页面里缓存逻辑没法统一管理。第二种方案是在后端加Redis缓存用Spring Cache注解把接口返回的数据缓存起来。这个方案需要你本机装一个RedisWindows和Mac都有安装包不麻烦。写文档的时候这又是一个加分点因为你可以很自然地写出“分布式缓存设计”这一小节。第三种方案是我最推荐的场景针对首页这种数据更新频率极低但访问量最大的页面直接把接口数据在后端启动时加载一次然后定时刷新。用Spring的定时任务注解很简单但实际项目里如果数据量变大就不够用了因为内存放不下所有数据。我自己在实际项目里通常是这样组合使用的首页推荐数据用后端定时缓存店铺列表和搜索结果不做缓存但用分页查询控制每次加载的数据量一次20条店铺详情数据用小程序端本地缓存有效期为30分钟。这个组合下来的体验比较均衡不会因为缓存问题在答辩时被问住。4. 小程序端核心页面实现从页面骨架到交互细节4.1 首页与导航栏的搭建过程首页是最能体现小程序整体风格的页面代码实现主要有三个层次页面的骨架结构、数据加载逻辑、组件的复用。骨架结构上微信原生小程序常见的做法是把导航栏设计成自定义模式也就是在app.json里把navigationStyle设置为custom然后自己画一个导航栏区域。为什么很多设计要这么干因为默认导航栏的背景色和文字颜色是固定死的想要做得精致必须自定义。但我个人建议毕设项目不要轻易用自定义导航栏为什么因为兼容性问题太多。不同手机的胶囊按钮位置不同顶部状态栏的高度要从wx.getSystemInfoSync()里动态获取写错一点就会出现导航栏被刘海遮挡的尴尬情况。这个坑我踩过调试的时候心态会崩。既然毕设追求的是稳定那就用默认导航栏白色背景、黑色文字中规中矩不会出错。首页的数据加载逻辑是典型的onLoad阶段请求接口。我建议把所有接口请求封装到一个统一的api.js文件里每一个接口对应一个方法用Promise封装wx.request。这样做的原因很实际答辩现场你要改接口地址只需要改一个config文件而不是翻遍所有页面去改url。再看页面结构顶部搜索框、轮播图、分类导航、推荐列表。轮播图用swiper组件分页加载用onReachBottom事件监听页面滚动到底部时加载下一页数据。这里有一个容易忽视的细节列表页的分页参数。很多同学的接口虽然支持分页但页面上没有做分页加载导致数据量大时首页一次性渲染几十条记录体验很差。正确做法是定义page默认为1pageSize为10每次请求成功后将新数据append到列表数组尾部并在数据全部加载完毕后显示“没有更多了”。4.2 详情页评分展示与收藏交互的常见易错点店铺详情页是小程序功能最密集的页面涉及的数据字段多、交互操作也多。常见的布局是顶部店铺封面大图下面依次是店铺名称、评分、人均价格、地址、电话、营业时间、店铺简介再往下是评价列表和评价提交入口。这里我要特别提醒一个位置收藏按钮的交互设计。很多同学把收藏按钮放在详情页的最底部用户得滚很久才能看到操作路径太长。我实际开发中用的是右上角胶囊按钮下方位置放置一个“收藏”图标用户视线自然落到那里点击后有toast提示“收藏成功”或“已取消收藏”。实现逻辑是进入详情页时请求的detail接口会返回isFavorite字段页面用这个字段初始化按钮状态。点击时调用收藏切换接口然后根据返回结果更新按钮状态和本地状态。这个交互看起来简单但很多同学会在这里犯一个典型错误——收藏状态只在前端切换没有同步给后端刷新页面后状态又变回去了。评分展示这块我建议不要只用数字要做一个简单的星级展示。原理不难每个星是一个图标根据评分的整数部分点亮实心星小数部分超过0.5点亮半星否则不亮。我把评分转成字符串后再截取拼接再在小程序端的wxml里用wx:if判断渲染。功能不复杂但视觉上和用户体验上比一个光秃秃的数字好看得多。详情页的另一个关键细节是用户评价与评分的联动更新。用户在详情页提交一个评价后店铺的综合评分需要更新。这个计算逻辑其实很简单新的综合评分等于原有的总评分乘以原有评价人数加上本次评价分数再除以新的总人数四舍五入保留一位小数。这个逻辑写在评论接口的后端事务里执行保证评论表和店铺表的更新操作要么都成功要么都回滚。4.3 个人中心与登录逻辑的完整闭环个人中心页就会涉及微信登录的完整闭环。这里我直接给你拆解整个登录流程因为这是答辩时必问的一环。首先小程序端调用wx.login()获取一个临时凭证code这个code有效期只有5分钟且只能用一次。然后通过wx.request把code发到自己后端的/api/user/login接口。后端收到code后向微信服务端发起请求用appid、secret和code换取openid和session_key。校验成功后就查用户表如果不存在openid对应的记录就自动注册一个新用户最后签发一个token返回给前端。小程序端拿到token后存入wx.setStorageSync(token)后续所有请求在header里带上这个token后端拦截器解析token之后就能知道当前请求的用户是谁。这里有一个很经典的坑appid和secret必须是微信小程序后台自己账号的不能随便填一个网上查到的。而且通过wx.login()拿到的code换取的openid一台手机在一个小程序下是唯一的但换一个appid得到的就是另一个openid。有很多同学在这个环节漏了session_key的管理其实session_key用于解密用户的手机号等敏感信息如果毕设功能用不到手机号绑定就可以不纠结。个人中心还有一个非常重要的细节很多页面的数据是按照当前登录用户去过滤的比如我的收藏、我的评价所以请求这些列表的接口需要一个用户身份的识别机制。我的建议是拦截器统一处理也就是写好代码后在/config/config.js里配置token名称比如header里字段名叫X-Token后端拦截器从这个header里取token解析userId。不要在小程序端的每个请求里手动去加header那样代码冗余到可怕。5. 管理后台与数据维护别让管理员端成为你的软肋5.1 管理后台的技术选型与页面规划管理后台的重要性经常被低估。很多学生辛辛苦苦把小程序端做得花里胡哨管理后台却只做了个残缺的列表页面连数据编辑功能都没有。评审老师一旦在管理后台里发现数据根本改不了会直接认定你的系统“不完整”这个印象分会损失非常大。我的建议管理后台不要做得太复杂但要保证核心功能可用。技术选型上如果你Java基础还算扎实用Spring Boot加Thymeleaf模板引擎是最省事的方案一套后端代码同时服务小程序接口和管理后台页面部署也简单。如果你想显得更有现代感可以用Vue加ElementUI管理后台做成一个单独的前端项目通过API调用后端接口。但我更推荐前者理由还是那个稳定优先。Thymeleaf的用法非常固定页面写起来是服务端渲染的思维调试一次就能跑起来。管理后台的页面规划至少包含这四块登录页账号密码管理员表在数据库里手动预置一条记录店铺管理列表、新增、编辑、上下架关键的上架状态切换要能立即影响小程序端的显示分类管理增删改排序评价管理查看评论列表、删除违规评论。如果时间充足再加一个推荐位内容管理用来配置首页轮播图跳转到指定店铺。这一个功能写在文档里很加分因为能体现你对业务运营的理解。5.2 文件上传与图片回显的实现细节店铺封面、评价图片、分类图标这些图片素材怎么存怎么传是一个避不开的问题。我在毕设项目中见过五花八门的方案有把图片转成base64直接存数据库的有传到第三方图床上然后把外链存数据库的还有干脆写死静态路径让前端拼URL的。先说base64方案为什么不推荐。base64会比原图膨胀约三分之一一张正常大小的店铺封面转出来可能有上百万字符存进数据库不仅浪费空间接口传输也慢。小程序端解析这种超长的JSON字符串时还会出现渲染变慢的问题。第三方图床的问题在于不可控图床挂了图片就全没了而且有些云存储服务还需要额外的配置对小白不友好。我推荐的做法是用后端接口接收前端上传的图片文件保存到服务器本地指定目录然后在数据库里存这个图片的相对路径。具体到代码实现前端通过wx.chooseImage选择图片然后调用wx.uploadFile将文件传到后端的/api/upload接口。后端用MultipartFile接收检查文件大小建议限制2MB以内不然服务器扛不住大图、检查文件类型jpg、png、webp然后生成一个新的文件名用UUID加原文件扩展名避免重名覆盖保存到本地磁盘目录最后把访问路径返回给前端。小程序端拿到这个路径后要在前面拼上服务器的域名或IP才能正常显示图片。部署时有一个非常关键的坑如果你把项目部署到服务器上图片保存的路径必须是绝对路径对应的Web映射目录否则图片是存下来了但访问不到。我用的方案是在application.yml里配置一个upload.path属性然后用一个WebMvcConfigurer把/upload/**路径映射到这个磁盘目录。本地开发时路径配成本地目录部署到服务器时改一下配置就行很方便。5.3 数据一致性的小细节评分更新与统计字段管理后台修改了店铺数据小程序端能看到最新数据吗这个问题看起来理所当然但很多学生在设计时根本没有考虑数据更新的时效性问题。如果你在小程序端做了本地缓存那你管理后台改了数据后用户端看到的还是旧数据体验就很割裂。我的处理方案是给前端缓存设置一个有效期比如店铺列表的缓存有效期是5分钟详情页的缓存有效期是30分钟过期自动请求新数据。管理后台做完修改之后页面上的下架操作其实不用立刻做缓存清理因为你把缓存有效期设为5分钟数据最多延迟5分钟就会更新了。如果追求实时我建议在后端的修改接口里主动调用一次清除缓存逻辑也就是调用wx.setStorageSync没法从后端清但后端的Redis数据可以清。不过考虑到毕设的系统复杂度其实5分钟延迟用户根本感知不到不用刻意追求实时性。管理后台的改进还可以围绕“评分维护”延展管理员在后台查看某店铺的评分分布图几个星级分别有多少条评价这个功能用一个简单的SQL查询就能做出来按score字段分组统计即可。写在文档里就是“基于数据统计的运营决策支持模块”听起来比单纯增删改查高大上不少。6. 实训录开发过程中最常见的五个报错与排查对策6.1 微信开发者工具中常见的编译与渲染陷阱第一个让无数人崩溃的问题是页面一直显示空白或者加载不出来数据。排查的思路要按顺序来先开手机调试看Console面板有没有报错如果报错信息是request:fail说明前端根本没有连上后端接口检查一下开发者工具的“不校验合法域名”开关是否打开再检查本机IP地址和端口有没有写错。如果是errno:600这类系统错误多半是代码里的语法错误或组件使用不当。我的经验是遇到空白页第一时间看Console面板而不是反复改代码。第二个问题是下拉刷新和触底加载分页时数据重复。这个错误几乎每个做列表页的同学都会遇上。原因一般是page参数没有正确递增或者加载下一页时将新数据用setData整体覆盖了旧数据。正确做法是在成功的回调里做数组拼接this.setData({ shopList: this.data.shopList.concat(res.data.data.list) })同时用一个isLoading标志位防止重复触发加载。第三个问题是关于图片显示明明图片URL从后端返回了开发工具里也能看到请求记录但页面就是不显示。大概率是URL拼错了。比如后端返回的是/upload/photo.jpg你前端直接把它当完整路径用了小程序端要么显示不出来要么报域名错误。正确的拼接方式是在请求层统一处理如果返回的路径不是以http开头就自动拼接上你的服务器基础地址基础地址在config.js里配置全局统一改。第四个问题是用户授权相关。小程序获取用户昵称头像的接口在改版后已经不能直接弹窗获取了新版本需要用户主动点击一个按钮触发授权。如果你的项目里还在用wx.getUserProfile之后自动弹窗多半会拿不到数据。现在的标准做法是把“获取头像昵称”的入口放在个人中心页的一个按钮或头像上用户点击后调起授权。这个改动导致很多老教程里的代码直接失效写代码前一定要确认你参照的教程版本是否适用于当前的基础库版本。6.2 后端接口调通时的经典故障跨域与参数接收后端接口的故障也很有规律。第一个高频问题是跨域CORS。你的管理后台前端如果是独立部署的比如用Vue开发然后运行在8080端口而后端Spring Boot运行在9090端口就会遇到跨域请求被拦截的情况。解决方案是在后端加一个CorsFilter允许所有域名访问或者允许来自你前端地址的请求。写文档时这里还能展开写一下CORS的原理浏览器会先发出一个OPTIONS预检请求服务端返回Access-Control-Allow-Origin等响应头浏览器校验通过才会发送真正的请求。能说清楚这个原理老师会认为你是真的理解问题而不是只会复制粘贴。第二个高频问题是参数收不到。前端传了参数后端接口却报参数为空。这通常是因为前端用POST请求传JSON格式数据但后端的Controller方法用RequestParam接收或者前端用application/x-www-form-urlencoded格式提交表单后端却用RequestBody去接。我强烈建议后端统一用RequestBody接收前端传的JSON对象定义对应的DTO类或者直接用Map接收避免这种类型不匹配的问题排查起来也快。第三个值得注意的坑是数据库连接出错。很多同学本机MySQL的账号密码跟配置文件里写的不一致最常见的写法是用户名root密码123456但是安装MySQL时可能设了别的密码启动项目一连接就报错。这个问题在展示项目时经常出现如果老师要求现场演示结果接口连数据库都连不上场面就很难看了。建议项目启动之前先在命令行里用mysql -u root -p验证一下自己的密码到底能不能连上数据库。6.3 数据安全与字段校验的前置处理作为毕业设计数据安全不必做到银行级别但基本的前置校验还是要有。我见过不少同学的代码里前端传了什么就存什么后端完全没有参数校验结果一个负数的评分也能提交进来一个超长字符串直接塞爆数据库字段。这种问题一旦被老师查出来就是“系统健壮性不足”级别的扣分。我的做法是在后端加两层校验。第一层是基础校验非空校验、字符串长度限制比如昵称最多50字符、评论内容最多500字符、评分必须在1到5之间。放在ServiceImpl层里判断不满足直接抛出一个自定义的业务异常统一由全局异常处理器捕获并返回错误信息。第二层是权限校验查询我的收藏、提交评价这类操作必须校验登录状态防止伪造token访问他人的数据。Spring Boot中用拦截器统一做鉴权处理识别一下从header里取到的token是否存在且有效。举一个小例子提交评价的接口我的校验逻辑是这样写的先判断登录用户的id和Token是否匹配不匹配直接拒绝再查询店铺id是否存在不存在返回店铺不存在然后校验评分参数在1到5之间最后才执行插入操作和更新店铺评分的逻辑。每一步都有可能失败但每一层的失败都返回明确的错误码和提示信息前端拿到后提示用户。这套逻辑写下来不需要多少代码量但文档里可以洋洋洒洒写两三页。7. 毕业设计文档的撰写思路与答辩演示的加分细节7.1 论文文档的结构组织和要点提炼文档的撰写往往是很多学生的短板但答辩的通过率很大程度看文档质量。标准的毕设论文结构我不细说因为每个学校都有自己的模板。我只想强调几个容易被忽略但很加分的点。第一个是“可行性分析”部分不要完全照抄模板。你要结合这个项目的特点去写。比如美食推荐小程序的可行性分析可以围绕三个维度技术可行性微信小程序生态成熟、Spring Boot资料全、经济可行性开发不需要额外购买服务器和数据库本地即可完成开发和演示、操作可行性小程序的使用门槛低用户不需要专门学习。套话要有但一定要有项目专属的内容老师一眼能看出你写的是针对这个项目的分析还是泛泛而谈的开题报告。第二个是“系统测试”部分的写法。很多同学的测试章节就是列几个测试用例表格写预期结果和实际结果然后全部填“一致”。这样不是不行但很枯燥。我建议你在常规表格之外专门加一段“异常场景测试”列举遇到的真实问题比如用户评分提交负数时系统的提示是否符合预期、网络异常时列表页是否有加载失败和重试机制、后端数据库未启动时小程序端提示是否友好。这些细节会让老师觉得你确实做了测试而且考虑了边界情况。第三个是“总结与展望”的写法。不要只写“本项目实现了什么功能但因为时间有限还有不足”。这个部分一定要具体比如你可以写“当前系统的推荐逻辑基于分类筛选和评分排序后续可以引入用户行为分析根据收藏和浏览历史构建用户兴趣标签实现个性化推荐”。这种展望既体现你对当前系统的局限性有清醒认知也体现你对推荐系统有一定了解比空喊“未来可以做得更好”强得多。7.2 答辩现场的演示流程脚本答辩演示是最容易翻车也最容易加分的环节。我建议你提前准备一个演示脚本按照功能的主干路径去走而不是东点一下西点一下。我的推荐演示顺序如下先介绍系统的整体架构前端小程序加后端接口加数据库三层然后打开小程序演示用户端流程登录授权展示用户信息、浏览首页、点击分类筛选、搜索美食、查看店铺详情、收藏店铺、提交评价、切换个人中心查看收藏列表和评价记录。这套流程走完大约5分钟。接着打开管理后台页面演示管理员登录、修改店铺信息、下架一个店铺、再去小程序端刷新列表确认店铺消失。这组操作能同时展示前后端数据的联动关系。演示时有三个细节必须注意第一个是提前关闭手机息屏防止演示中黑屏尴尬第二个是提前清理缓存让小程序首次加载完整走一遍数据请求流程让老师看到接口请求的真实发生不要打开就是个纯静态页面第三个是网络切到手机热点或现场WiFi不要依赖自己电脑的本地网络因为你演示的机器可能有代理或防火墙拦截请求。我还建议准备两套运行环境一套是本地开发环境本机跑着后端和MySQL一套是云端部署环境如果你有时间把项目部署到云服务器上。现场演示优先用本地环境因为稳定不受公网环境影响。万一本地环境出了意外再切云端的备用地址这样双保险能极大降低翻车概率。7.3 从毕业设计到项目经验的延伸建议做一套完整的毕业设计收获的远不止一个分数。我见过的学生里有人靠着毕设项目面试进了不错的公司因为面试官对小程序开发经验比较感兴趣也有人把毕设扩展成了自己的副业产品在校园里真给同学们提供美食推荐和信息展示的服务。说白了毕业设计是一个绝佳的练手机会像一座微型的完整系统设计训练的桥把你从大学的课程作业带向真实的工程场景。如果学有余力我建议可以做这几个方向的延伸一是把前端改成uniapp因为这样同一套代码可以同时发布到微信小程序、支付宝小程序和H5二是给后端加上Redis缓存这是企业开发的标配三是把推荐逻辑做成基于标签的个性化推荐引入简单的协同过滤算法。每一个方向都能让这个项目从“完成学业要求”升级为“一个有商业想象力的产品雏形”。不过最后我还是想多说一句毕设的核心目标是顺利通过答辩拿到学分在此之上才是展示技术能力。做了这么多年的项目看完这么多学生的作品我的感觉是真正让老师眼前一亮的不是技术有多高深而是你对自己做的东西理解有多透彻。能够把每一个需求的前因后果、每一个技术选择的权衡利弊都讲清楚这就是一个合格甚至优秀的毕业设计了。照着这篇的思路去梳理拿到一个理想的成绩应该不是难事。