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和status，status用于标记账号状态（正常、禁用），管理员封号的时候用得上。
第二张表是店铺表（shop）。这条表是整个系统里字段最丰富的。id主键，shop_name店铺名称，category_id关联分类表，shop_img封面图URL，score综合评分，avg_price人均消费，address具体地址，phone联系电话，business_hours营业时间。还有一个关键字段status，用于控制店铺的上架下架状态。这里我在实际开发中遇到的一个问题是：很多人喜欢把店铺描述和推荐语直接塞进一个text字段里，结果列表页加载的时候也给带出来，导致接口响应变慢。我的建议是列表页需要的字段（名称、封面、评分、人均价、分类）单独查，详情页需要的字段（地址、电话、营业时间、描述）再单独查一次，虽然不是最优方案，但足够清晰。
第三张表是分类表（category），字段最简单：id、name、sort_order（排序权重），可能还有一个icon图标字段，用于在分类栏展示小图标。
第四张表是评价表（comment），关联user_id和shop_id，content评价内容，score评分数值，images评价图片（可以是以逗号分隔的URL串，也可以单独建一张图片表，但简单起见用逗号分隔就行），create_time。
第五张表是收藏表（favorite），关联user_id和shop_id，create_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，前端传code（wx.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注解把接口返回的数据缓存起来。这个方案需要你本机装一个Redis，Windows和Mac都有安装包，不麻烦。写文档的时候这又是一个加分点，因为你可以很自然地写出“分布式缓存设计”这一小节。第三种方案是我最推荐的场景：针对首页这种数据更新频率极低但访问量最大的页面，直接把接口数据在后端启动时加载一次，然后定时刷新。用Spring的定时任务注解很简单，但实际项目里如果数据量变大就不够用了，因为内存放不下所有数据。
我自己在实际项目里通常是这样组合使用的：首页推荐数据用后端定时缓存，店铺列表和搜索结果不做缓存但用分页查询控制每次加载的数据量（一次20条），店铺详情数据用小程序端本地缓存，有效期为30分钟。这个组合下来的体验比较均衡，不会因为缓存问题在答辩时被问住。
4. 小程序端核心页面实现：从页面骨架到交互细节
4.1 首页与导航栏的搭建过程
首页是最能体现小程序整体风格的页面，代码实现主要有三个层次：页面的骨架结构、数据加载逻辑、组件的复用。
骨架结构上，微信原生小程序常见的做法是把导航栏设计成自定义模式，也就是在app.json里把navigationStyle设置为custom，然后自己画一个导航栏区域。为什么很多设计要这么干？因为默认导航栏的背景色和文字颜色是固定死的，想要做得精致必须自定义。但我个人建议毕设项目不要轻易用自定义导航栏，为什么？因为兼容性问题太多。不同手机的胶囊按钮位置不同，顶部状态栏的高度要从wx.getSystemInfoSync()里动态获取，写错一点就会出现导航栏被刘海遮挡的尴尬情况。这个坑我踩过，调试的时候心态会崩。既然毕设追求的是稳定，那就用默认导航栏，白色背景、黑色文字，中规中矩不会出错。
首页的数据加载逻辑是典型的onLoad阶段请求接口。我建议把所有接口请求封装到一个统一的api.js文件里，每一个接口对应一个方法，用Promise封装wx.request。这样做的原因很实际：答辩现场你要改接口地址，只需要改一个config文件，而不是翻遍所有页面去改url。再看页面结构：顶部搜索框、轮播图、分类导航、推荐列表。轮播图用swiper组件，分页加载用onReachBottom事件监听页面滚动到底部时加载下一页数据。
这里有一个容易忽视的细节：列表页的分页参数。很多同学的接口虽然支持分页，但页面上没有做分页加载，导致数据量大时首页一次性渲染几十条记录，体验很差。正确做法是定义page默认为1，pageSize为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缓存，这是企业开发的标配；三是把推荐逻辑做成基于标签的个性化推荐，引入简单的协同过滤算法。每一个方向都能让这个项目从“完成学业要求”升级为“一个有商业想象力的产品雏形”。
不过最后我还是想多说一句：毕设的核心目标是顺利通过答辩拿到学分，在此之上才是展示技术能力。做了这么多年的项目，看完这么多学生的作品，我的感觉是，真正让老师眼前一亮的不是技术有多高深，而是你对自己做的东西理解有多透彻。能够把每一个需求的前因后果、每一个技术选择的权衡利弊都讲清楚，这就是一个合格甚至优秀的毕业设计了。照着这篇的思路去梳理，拿到一个理想的成绩，应该不是难事。
