直接说结论这个基于 SpringBoot 微信小程序 AI 的智能外卖点餐推荐系统是目前计算机毕业设计里非常典型、也很有含金量的一类题目。它不是只做一个后台管理系统也不是只写一个能展示菜品的小程序页面而是把用户端、商家端、管理端和 AI 推荐模块放在同一条业务链里完整实现“登录 → 浏览菜品 → 加购物车 → 提交订单 → 接收个性化推荐”的闭环。对需要同时体现后端开发能力、小程序开发能力、数据库设计能力和算法应用能力的同学来说这个组合比单纯做个 CRUD 系统好讲得多也比只写前端页面更有说服力。这篇文章我不做源码逐行讲解而是按实际落地的顺序把项目拆开先搞清楚系统由哪些模块组成再讲环境和版本选型然后分别拆后端、小程序端、数据库和 AI 推荐模块最后把容易翻车的问题和答辩思路整理出来。这样不管你是准备直接运行源码还是想在此基础上改成自己的一套完整系统都能按图索骥。1. 先拆开看这个系统到底由哪些技术组成1.1 三个核心角色的分工这套系统有三个明显的主角SpringBoot 负责后端接口和数据处理微信小程序负责用户侧的交互界面AI 大模型负责推荐逻辑中的“智能判断”部分。SpringBoot 在整个系统里承担的是标准的后端职责接收小程序发来的 HTTP 请求处理用户登录、菜品查询、购物车、下单、订单状态更新同时管理管理员端的菜品上架、分类维护、订单管理等。它是整个系统的心脏小程序端所有页面上的数据最终都从这里来。微信小程序负责的是用户直接能看到的部分。菜品列表、菜品详情、购物车页面、下单页面、个人中心、推荐结果页面都运行在小程序环境里。小程序通过 wx.request 向 SpringBoot 后端发起请求拿到的数据再渲染到页面上。因为小程序本身有一些登录、授权和跳转逻辑这部分工作量在前端里占的比例不小。AI 大模型在这套系统里的定位有两种常见做法。第一种是把大模型作为推荐引擎后端把用户历史行为和菜品列表组装成提示词请求大模型 API让它返回推荐结果。第二种是让大模型做“辅助说明”比如协同过滤算法已经算出推荐菜品再由大模型生成一段推荐理由让结果看起来更“懂用户”。这两种方案在很多毕设项目里都存在后面我会专门讲它们的选型和实现差异。1.2 为什么说这个组合适合做毕设第一个原因是覆盖的技术点足够多。从后端接口设计、权限验证、数据库建模到小程序跨端开发再到 AI 接口调用和提示词设计每一个都是面试和答辩时能单独展开讲的东西。第二个原因是业务场景足够真实。外卖点餐不是虚构需求用户、菜品、购物车、订单这些实体关系清晰边界明确容易理解也容易查错。评审老师不用花力气理解业务可以把注意力放在你的代码结构和功能完成度上。第三个原因是可扩展性强。如果基础功能做完之后还有余力可以加骑手端、评论系统、优惠券、销量统计图表甚至把推荐模块做得更深。这些可以作为论文里的创新点也可以作为答辩时的加分项。1.3 系统整体运行流程流程可以按一条用户主线来理解用户打开微信小程序进入登录授权流程拿到微信身份标识。后端校验身份后返回该用户的自定义登录态。用户进入首页查看推荐菜品或按分类浏览菜品。用户把菜品加入购物车进入购物车页修改数量或删除。用户提交订单填写收货地址生成订单记录。用户可在个人中心查看历史订单并触发个性化推荐。管理员登录后台管理菜品、分类、订单和推荐相关配置。这条链路看起来简单但它把小程序端、后端、数据库和 AI 模块全部串联了起来。任何一个环节断裂流程就跑不通这也意味着你需要完整理解每个模块的职责才能调试成功。2. 环境准备与版本选型这一步最容易被忽视2.1 基础环境清单在运行源码之前先把环境准备好。根据这类项目的普遍配置我建议按下面的表格核对环境项常见要求说明JDK1.8 或 11大多数毕设项目基于 JDK 1.8 编写个别新项目用 11Maven3.6 及以上用于下载和管理依赖MySQL5.7 或 8.0建议 8.0但要注意连接驱动配置微信开发者工具最新稳定版导入小程序项目并预览后端运行端口8080 或 8081注意不要和小程序配置里的 baseUrl 冲突Node.js可选如果小程序端使用 npm 构建则需要纯项目一般不需要上面这些配置不是死标准但符合大多数毕设项目的现状。你拿到源码后第一件事不是急着点运行而是先看一下项目里的 README、pom.xml 和 application.yml确认目标 JDK、MySQL 版本和端口信息。2.2 SpringBoot 版本不是越高越好这一点要重点说。很多同学电脑上装的 JDK 比较新或者顺手就在 Maven 里把 SpringBoot 版本改成了最新版结果一启动就报各种依赖冲突。“springboot 版本太高”是这类项目最常见的启动失败原因。因为毕设源码通常基于某一个特定 SpringBoot 版本编写里面的 MyBatis、Swagger、JWT 等依赖版本都是配套好的。你单独把 SpringBoot 升级到 3.xJDK 版本如果还停在 8直接编译不过就算把 JDK 也换成 17很多依赖也要跟着换。如果项目原本是 SpringBoot 2.x建议保持原版本不要因为追求新版而随意升级。只有在明确知道某个依赖不兼容时才动版本而且动完之后要重新跑一遍全部接口测试。2.3 微信小程序端的准备小程序端需要在微信开发者工具里导入项目目录。导入时需要注意 AppID 的选择如果你没有自己的小程序 AppID可以先用测试号如果源码自带了 AppID也要确认它是真实可用的否则会报“小程序获取登录后的微信用户失败”。小程序的 baseUrl 配置是另一个容易踩的坑。本机调试时后端跑在 http://localhost:8080但小程序开发工具里不能直接用 localhost需要改成 http://127.0.0.1:8080同时必须开启开发者工具里的“不校验合法域名”选项。如果不开启请求会被微信的域名校验拦下来。注意在微信开发者工具里调本地后端接口经常会遇到请求失败。先确认是否勾选了“不校验合法域名”再看后端是否开启了跨域支持。3. SpringBoot 后端从分层结构到核心接口3.1 后端项目分层设计一个规范的外卖点餐系统后端一般分成 controller、service、mapper、entity 四层再加一个 config 包存放配置类。这种分层并不是为了好看而是为了让每一层只做一件事controller 接收请求并返回结果service 处理业务逻辑mapper 访问数据库entity 对应表结构。拿到源码后你可以先按这个路径浏览一遍src/main/java/com/xxx/food ├── controller # 接口层 ├── service # 业务逻辑层 ├── mapper # 数据访问层 ├── entity # 实体类 ├── config # 配置类 └── common # 通用返回结果、异常处理等如果源码里没有 common 包而是用 Map 直接返回也不要慌很多毕设项目都这么写。但如果你打算长期维护这个项目建议把统一返回结果抽出来至少包含 code、msg、data 三个字段这样小程序端处理起来会清晰很多。3.2 用户登录与鉴权用户登录是第一个核心接口。小程序端调用 wx.login 拿到临时 code然后把它传给后端后端拿着 code 去微信接口换取 openid。这个 openid 是用户在微信体系里的唯一标识系统用它来识别用户。常见写法是后端提供一个类似/api/user/login的接口接收 code 参数内部调用微信登录凭证校验接口拿到 openid 后查询或创建用户再生成一个自定义 token 返回给小程序。小程序把 token 存到本地缓存里后续请求都带上这个 token。这里要注意的是很多新同学会混淆 wx.login 和 wx.getUserProfile。wx.login 是用于获取登录凭证的不管用户是否点授权都能拿到 codewx.getUserProfile 是用来获取用户头像和昵称的需要用户主动授权。外卖点餐系统真正核心的是前者头像昵称只是展示信息拿不到也不影响下单流程。后端鉴权一般用拦截器或 AOP 实现。简单做法是在拦截器里校验请求头中的 token如果 token 不存在或已过期返回 401。这一步决定了系统是否安全不能省略。3.3 菜品、购物车与订单接口菜品模块的核心接口是分类列表和菜品列表。一般会有GET /api/category/list # 获取所有菜品分类 GET /api/dish/list # 分页获取菜品 GET /api/dish/detail/{id} # 获取菜品详情购物车模块有两种设计。第一种是在后端维护购物车表用户每次加购都请求后端接口第二种是购物车数据只存在小程序本地缓存里下单时一次性传后端。两种都能做但毕设里我更推荐后端维护购物车表因为这样订单生成逻辑更完整论文里也更好写。订单模块是业务最重的部分。下单接口需要同时完成三件事创建订单主表记录、写入订单明细表、减少菜品库存。这三件事必须放在同一个事务里否则会出现订单创建成功但库存没减的情况。如果项目里没有加事务注解答辩时容易被打断。3.4 管理端与统计功能管理端通常不单独做一个大系统而是通过角色区分权限在同一个后端里提供管理员接口。管理员可以新增菜品、修改菜品上下架状态、查看订单列表、发货或完成订单。如果你想让项目更有亮点可以在管理端加一个简单的统计接口比如统计每日订单量、热门菜品排行、销售额。数据量不大用一条 SQL 就能查出来但展示出来之后整个系统的完整度会明显提升。4. AI 推荐模块怎么把“大模型”做成真正的亮点4.1 推荐数据的来源与特征构建很多人在 AI 推荐上有一个误区以为只要调用了大模型接口就算智能推荐。实际上要让推荐结果靠谱必须先有数据特征。没有用户行为数据大模型也推不准。在这个系统里你至少可以构建这些特征用户历史订单里的菜品分类分布比如用户点黄焖鸡的次数最多说明偏好家常菜。用户菜品的口味属性比如辣度、荤素、价格区间。菜品销量排名、评分、月售数量。用户浏览记录如果做了浏览埋点还可以统计停留时间。特征构建完成之后下一步是生成候选菜品列表。候选集不需要太大一次取 20 到 30 个菜品就足够。候选集可以综合评分、销量、分类匹配度来生成不需要一开始就上复杂算法。4.2 两种推荐实现路径第一种是规则推荐。后端不调用外部接口直接根据用户特征和菜品标签计算匹配分数比如分类匹配加固定分数、销量权重加一个分数、用户历史偏好加权最后按分数从高到低排序。这种方案稳定、可控、不依赖网络论文里也可以写清楚计算过程。第二种是调用大模型 API。把用户特征和候选菜品列表组装成提示词请求大模型接口让模型返回推荐结果和推荐理由。这种方式更贴近“AI 大模型”这个题目名称答辩时更有话讲但要注意网络环境和接口费用。提示词可以这样设计你是外卖平台的推荐助手。用户历史偏好偏好辣味常点盖饭类平均消费25元。 以下是候选菜品列表 1. 招牌黄焖鸡 价格22元 销量1200 评分4.8 2. 麻辣香锅 价格28元 销量800 评分4.6 3. 番茄鸡蛋面 价格15元 销量900 评分4.5 请根据用户偏好推荐3道菜并给出每条推荐理由。 输出格式菜品ID | 菜品名称 | 推荐理由这个提示词包含了用户特征、候选集、任务说明和输出格式属于真正可控的大模型调用方式。很多项目把候选集全部塞进提示词让模型随便选效果自然不稳定。如果你不想依赖外部网络可以选择本地部署一个小尺寸开源模型比如 7B 或更小的量化版本用 Ollama 或类似工具提供一个本地 HTTP 接口后端只改一个 base_url 就行。但这需要机器至少有 8G 以上内存显存有更好没有显存也可以用 CPU 跑只是响应时间会明显变长。4.3 推荐接口返回结构推荐模块最终要给前端一个统一结构的返回结果我建议这样设计{ code: 200, msg: success, data: { recommendDate: 2025-01-10, items: [ { dishId: 1024, dishName: 招牌黄焖鸡, dishPrice: 22.0, reason: 你最近的订单里多次选择了辣味菜品这道黄焖鸡的辣度适中值得尝试。 } ] } }推荐理由字段是关键。有没有 reason直接决定这个功能在答辩时是“调了一个接口”还是“做了一个推荐系统”。哪怕你用的是最简单的规则推荐只要能把推荐理由生成出来整条链路就完整了。5. 微信小程序端登录、点餐与推荐展示5.1 小程序登录流程与授权问题小程序端的登录流程可以直接参考官方推荐做法页面加载时调用wx.login获取临时 code。调用后端登录接口传入 code。后端返回 token 和用户基本信息。小程序将 token 存入wx.setStorageSync后续请求统一携带。这里要特别提醒微信已经从 2022 年开始调整了用户头像昵称的获取方式。以前调用wx.getUserInfo就能拿到头像昵称现在这个方法已经不能弹出授权框了。需要用button open-typechooseAvatar和input typenickname的方式间接获取。如果源码里还在用老方法在小程序工具里会报“获取登录后的微信用户失败”之类的错误不是后端写错而是微信平台改版导致旧接口失效。遇到这类问题时不要急着改后端先确认是不是微信接口本身的行为变化。把登录逻辑和用户信息获取逻辑拆开登录负责身份用户信息负责展示两者互不影响。5.2 点餐页面与购物车逻辑菜品列表页一般用 scroll-view 或简单列表渲染。菜品卡片包含图片、名称、价格、销量、加号按钮。点击加号时在小程序本地维护一个购物车对象用 dishId 作为 key数量作为 value。购物车页面需要实时计算总价这个计算建议放在小程序端完成不在后端反复请求。因为购物车是会话级的操作用户加一份、减一份都立即重新计算等确认下单时再统一传到后端。下单时要传的字段至少包括用户 ID、总金额、收货地址、菜品明细列表。后端在事务里创建订单主表和明细表返回订单 ID。前端拿到订单 ID 后跳转到订单详情页。5.3 推荐结果展示推荐结果页面是整套系统最有辨识度的页面。一般有两种展示方式第一种是一个独立的“猜你喜欢”页面进入时请求推荐接口用卡片列表展示推荐菜品和推荐理由。这种方式适合作为功能亮点直接演示。第二种是在首页头部放“为你推荐”模块用户一进来就能看到。这种方式对用户更友好但需要保证首页加载速度推荐接口如果响应时间太长会影响整体体验。如果推荐接口消耗时间比较长我建议在页面里加一个加载状态而不是让用户干等。可以用骨架屏效果或者先展示一个加载中的提示拿到结果后再渲染列表。6. 数据库设计与表关系6.1 核心表结构外卖点餐系统的数据库表设计并不复杂但表之间的关系要清晰。核心表一般包括表名主要字段用途userid, openid, nickname, avatar, phone用户信息categoryid, name, sort菜品分类dishid, category_id, name, price, image, sales, rating, status菜品信息cartid, user_id, dish_id, quantity购物车ordersid, user_id, total_amount, address, status, create_time订单主表order_detailid, order_id, dish_id, dish_name, price, quantity订单明细recommend_recordid, user_id, dish_id, reason, create_time推荐记录orders 和 order_detail 是一对多关系。dish 和 category 是多对一关系。user 和 orders 是一对多关系。只要能把这几个关系讲清楚数据库设计环节就没什么问题了。6.2 推荐记录表的作用很多毕设项目没有 recommend_record 表推荐结果直接由接口实时计算不落库。这样做的优点是逻辑简单缺点是答辩时拿不出推荐历史的证据也没法分析推荐效果。如果加上 recommend_record 表每次调用推荐接口时把返回结果记录进去之后就可以写一个“推荐记录”页面展示系统给用户推荐过什么、用户是否点了这些推荐菜。这个数据虽然简单但能支撑你的论文里写“推荐效果追踪”和分析推荐命中率是性价比很高的加分设计。订单表里的 status 字段建议用数字表示状态比如 0 待支付、1 已支付、2 配送中、3 已完成、4 已取消。不要把状态存成中文后续做统计和筛选都很不方便。7. 调试与排错最常见的问题和排查顺序7.1 小程序请求不到后端接口这是出现频率最高的问题几乎没有之一。遇到请求失败按照下面的顺序排查后端是否启动成功看控制台日志确认没有启动异常。小程序 baseUrl 是否正确本机调试时用 127.0.0.1 而不是 localhost。是否勾选“不校验合法域名”开发工具默认情况下会拦截非 https 请求。后端是否有跨域配置SpringBoot 接口需要允许小程序来源的跨域请求。请求路径是否匹配小程序里写的路径和后端 RequestMapping 的路径必须完全一致注意不要少写斜杠。很多同学前两步没问题最后发现是小程序的 baseUrl 配错了端口。后端跑在 8080小程序里配置成了 8081请求自然失败。7.2 SpringBoot 版本太高导致的依赖冲突如果启动时出现类似Invalid value type for attribute factoryBeanObjectType或ClassNotFoundException的报错多数情况是 SpringBoot 版本和依赖不匹配。排查顺序是这样打开 pom.xml确认 spring-boot-starter-parent 的版本。确认本地 JDK 版本是否满足该版本要求。检查 MyBatis、MySQL 驱动、JWT 等依赖是否和 SpringBoot 版本兼容。尝试回退到源码默认的版本而不是升级。在确认项目能跑起来之前绝对不要为了追求新版而升级 SpringBoot。项目里的依赖版本都是被验证过能一起工作的你改任何一个关键版本都可能引发连锁问题。7.3 用户信息获取失败“小程序获取登录后的微信用户失败”这个提示需要区分两种场景。第一种是 wx.login 本身失败。这种情况很少见但如果你在小程序后台上传了不匹配的 AppID或者没有配置 request 合法域名会直接影响登录。排查时先看小程序的 AppID 是否和后端调用微信接口时使用的一致。第二种是 wx.getUserProfile 或 wx.getUserInfo 拿不到用户信息。这是微信接口改版导致的不是你代码的问题。解决办法是改用按钮触发chooseAvatar获取头像用输入框获取昵称或者干脆让用户信息可选填不影响登录和下单。7.4 系统运行卡慢如果项目跑起来之后操作很慢先看几个地方数据库有没有提前开。MySQL 没启动时后端接口会一直等待连接超时。大模型 API 调用有没有超时设置。如果推荐接口每次都等 30 秒才返回前端体验会非常差建议设置连接超时为 10 秒以内。列表接口有没有做分页。没有分页时菜品量一大前端渲染也会卡。本地调试时建议给推荐接口加一个 fallback 逻辑大模型调用失败时返回基于销量和评分的默认推荐结果保证流程不断。注意任何外部接口调用都不要让用户无限等待。先设超时时间再给失败情况准备降级方案这是生产经验在毕设答辩里也值得主动提。8. 答辩准备、功能扩展与源码使用建议8.1 答辩时大概率会被问到的三个方向第一个方向是业务流程。评委可能会问用户从登录到下单数据在前后端之间是怎么流动的这个问题只要按我之前讲的链路回答就能应对wx.login 拿 code后端换 openid生成 token后续请求带 token下单时后端在事务里写订单主表和明细表。第二个方向是 AI 推荐的具体实现。评委会关注你到底用了什么算法调用的是哪个大模型还是本地规则。这里建议准备一张图或一张表说明用户特征如何构建、候选集如何生成、提示词如何设计、返回结果如何解析。哪怕用的是最朴素的规则推荐加提示词优化只要讲清楚就比含含糊糊说“用了人工智能”好得多。第三个方向是数据库设计。评委会看表之间的关系和字段设计是否合理。准备时把核心表的建表语句复习一遍尤其要能说清楚订单主表和明细表为什么要拆开。答案很简单一个订单包含多个菜品如果全塞在一个表里查询和统计都会很困难。8.2 把推荐做成真正的加分项如果基础功能已经跑通想再往上走一个台阶可以朝这几个方向扩展给推荐接口加“不感兴趣”反馈。用户点“不喜欢”后后端把该菜品 ID 加入排除列表下次推荐不再出现。这个功能逻辑简单但表现力很强。记录推荐点击行为。在推荐卡片上埋点用户点击后上报推荐记录 ID这样可以统计推荐点击率论文里可以写“推荐效果指标”。对接微信订阅消息。用户下单后通过小程序订阅消息模板推送订单状态更新。这个功能需要在小程序后台申请模板但做好了会显得项目很完整。把推荐方式做成可配置。在管理后台里设置“当前推荐模式”是规则推荐、大模型推荐还是混合推荐。这样答辩时可以现场切换演示效果。8.3 源码、论文和 PPT 怎么配合使用这套毕设资源包里通常包含源码、LW、PPT 和讲解视频使用方法不是“解压后直接照抄”而是把它当模板进行二次理解。正确的顺序是先把后端启动起来逐个调用接口确认数据能返回再用微信开发者工具打开小程序端跑通登录、浏览、下单、推荐这条完整链路最后对照论文里的功能模块表给每个功能找到对应的代码文件。论文、PPT 和源码之间的关系是对应关系不是三份独立材料。答辩时老师看了 PPT 上的功能模块图可能会直接问“这个接口在源码里是哪个方法”如果你没有真正跑过源码这一关很容易卡住。所以哪怕时间紧张也至少要完整跑通一遍并记住每个核心功能对应的 Controller 类名。把这篇内容当路线图把源码当练习题自己动手跑一遍、改一遍才是这套毕设资源最正确的打开方式。项目本身不难难的是你能不能把它讲成一个完整的技术故事。