毕设选了个“基于SpringBoot的成人小饭桌微信小程序”从题目到定稿折腾了十来天期间踩了不少坑也摸清了一套小程序后端项目的完整打法。这篇就当成一次复盘把这套项目从需求设计到数据库、后端接口、小程序端适配再到联调上线和答辩准备原原本本说清楚。不管你是正在选毕设题目的学生还是刚接触SpringBoot想拿个真实项目练手的人看完这篇基本就能明白这类项目应该怎么拆、怎么做、怎么讲。1. 项目拆解与设计思路1.1 成人小饭桌的需求从哪来“小饭桌”这个词最早指学校附近给中小学生提供午托、午餐的小型服务点而“成人小饭桌”则是这两年在一二线城市慢慢多起来的模式有人在家里或者小档口做家常菜面向周边上班族、单身青年按周或按月订餐比外卖更家常比自己做省事。拿这个场景做毕设最大的好处是需求非常具象不需要凭空想象。一顿饭点几个菜、日期选哪天、自提还是配送、能不能评价这些都是日常需求。把这类业务抽象成系统核心就是一套“浏览菜品—加入购物车—提交订单—支付—商家接单—完成配送/自提—评价”的流程。哪怕只做最基础的用户端和商家端也已经能覆盖一个餐饮O2O系统的绝大部分功能。这个模式做毕设还有一个天然优势它和外卖平台、食堂订餐等已存在系统有相似逻辑导师听完不陌生你讲起来也容易。同时它又有“周边服务”“个人商家”这种轻量属性可以把权限控制、订单状态流转、数据统计这些考点都放进去评分点很好凑。1.2 为什么是SpringBoot加微信小程序选技术栈不能只看流行要看毕设的匹配度和可维护性。SpringBoot成为绝大多数毕设首选不是因为它比Spring Cloud、SSH这些框架高级而是因为它够轻、够稳、资料多。成年人小饭桌项目的并发量并不高单体应用加关系型数据库完全扛得住不需要引入微服务和消息队列。SpringBoot自带的Tomcat、spring-boot-starter-web、自动配置机制可以让一个学生从零到跑通前后端联调的时间大幅缩短。小程序端选微信小程序而非Android或Vue网页主要出于三个层面的考虑。其一微信小程序有着极低的触达成本不用安装App扫码就能用更符合餐饮行业消费场景其二小程序开发语法接近前端标准WXML、WXSS、JS会一点Vue就能很快上手其三微信小程序自带登录、支付、订阅消息等能力做毕设可以展示更多与微信生态的联动这在答辩时是加分项。实际开发中需要注意SpringBoot后端只负责业务逻辑和数据存储小程序的授权登录本质上是拿微信的code去后端换openid和session_key后端再自己发一个token给小程序后续请求都带这个token。理解这条链路才不会被“微信登录到底做了什么”卡住。1.3 角色与功能模块设计一个成人小饭桌小程序至少要拆出三种角色普通用户、商家店主、管理员。很多毕设把商家和管理员做成同一套后台这其实是不严谨的。管理员管用户、管审核、管数据统计商家管菜品上下架、订单状态流转、营业信息用户则只关心点餐、订单和评价。用户端功能列表[登录、首页菜品展示、分类筛选、菜品详情、加入购物车、创建订单、地址管理、订单查询、评价、收藏]。商家端可以做成小程序内嵌的管理页也可以单独做一个H5或者PC后台。我建议用SpringBoot的Thymeleaf或者直接做一套简单的Vue页面至少要比在小程序里切换角色清爽得多。如果只想保持一个前端也可以在小程序里通过账号类型跳转到不同页面。后台管理端功能更偏统计和配置比如用户列表、商品分类管理、订单总览、营业额统计、销量排行。注意这里要把“菜品管理”和“分类管理”拆开因为菜品可能要按“热菜”“凉菜”“汤品”“主食”等维度筛选而分类本身是需要增删改的。在权限模型上角色直接用一个字段userType区分即可没必要引一套Spring Security加上注解式权限控制但为了体现水平可以在后端加一个简单的拦截器放行登录验证、商家操作前检查角色。答辩时有老师问权限控制能讲出“自定义拦截器角色判断”的取舍比照搬复杂框架更显示自己的理解。2. 数据库与后端核心实现2.1 核心数据表设计所有业务都围绕订单展开所以数据库的核心是把“用户—菜品—订单”串起来。表不必多但字段不能少否则后面做统计和状态变更会很难受。我给一个经过实操精简的结构user表id、openid、nickname、avatar_url、phone、user_type0用户/1商家/2管理员、create_timecategory表id、name、sort、statusdish表id、category_id、name、image、description、price、monthly_sales、stock、status、create_timecart表id、user_id、dish_id、quantity、create_timeaddress表id、user_id、name、phone、detail_address、is_defaultorders表id、order_no、user_id、merchant_id、total_amount、address_snapshot、status、pay_time、finish_time、remarkorder_item表id、order_id、dish_id、dish_name、price、quantity、imagecomment表id、order_id、user_id、content、rating、create_time注意orders表里一定要存address_snapshot快照。因为用户下单后如果改了地址订单历史应该保留下单时的地址。菜品价格也用order_item里的price存一份不能下单后去菜表里查实时价格否则商家改价会影响历史订单这在答辩时很容易被抓住。订单的order_no不要用自增id建议用时间戳加随机数或者直接用Snowflake算法。为了演示技术点可以在后端写一个简单的OrderNoGenerator例如“yyyyMMddHHmmss 4位随机数”虽然并发高了会有重复风险但毕设场景绝对够用。你可以在答辩时提一句“真实生产会考虑雪花算法”这句话就是亮点。2.2 SpringBoot目录结构与分层后端建议统一按controller、service、mapper、entity、common、config分层。不要在一个Controller里写300行业务逻辑哪怕项目再简单也要养成分层的习惯。我常用的包结构大概是com.example.app ├── controller # 接口入口只做参数接收和返回 ├── service # 业务逻辑事务在这里控制 │ └── impl ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体 ├── vo # 返回给前端的视图对象 ├── dto # 前端传入的参数对象 ├── common # 统一返回结果、异常、常量 └── config # 拦截器、跨域、配置类返回给前端的结果不要直接用Map建议定义一个Result 里面放code、message、data。前端拿到后统一判断code是否为200。这样做的好处是后面加状态码、统一异常处理都非常方便。很多学生喜欢直接返回对象前端取不到错误信息出问题时要抓瞎。Service层的事务控制要留心。下单这个操作不只是往orders表插一条数据还要同时创建order_item、清空购物车、扣减库存。这四件事必须放在一个事务里任何一步失败都要回滚。在方法上加Transactional然后自己模拟一次“库存不足抛异常”看看是否连订单也消失了这是检验事务配置是否生效最快的方法。2.3 微信登录与JWT签发微信小程序端通过wx.login拿到code传给后端后端再拿code去微信接口换取openid。这一步不需要小程序端存任何东西也不需要后端保存session_key。拿到openid后去user表查找不到就自动注册新用户然后根据用户id生成一个token返回。token我推荐用JWT。虽然JWT有无法主动失效的问题但做毕设足够而且比存数据库session更现代。生成JWT时可以放userId和userType两个字段这样后续拦截器里就能直接判断角色。注意JWT的过期时间设成24小时小程序端每次请求都把它放在header的Authorization里。需要避开一个坑微信小程序的request域名白名单要求所有请求地址都必须是HTTPS且备案过的域名。在开发调试阶段可以在微信开发者工具里勾选“不校验合法域名”但做演示或答辩时如果要用真机就必须有HTTPS域名。很多学生挂在这一点最后只能用模拟器演示。如果买不起服务器可以考虑在答辩时沿用工具调试但要准备一套应对老师提问的说法比如“正式上线需要配置已备案域名并开启HTTPS”。2.4 订单状态机与核心接口设计订单状态不要想得过于复杂否则你会被各种状态的边界问题折磨死。我的建议是只设5个状态待支付、待处理、配送中/待自提、已完成、已取消。商家操作流程就是“接单”待支付-待处理、“开始配送或设定自提”待处理-配送中、“完成”配送中-已完成。用户侧“取消订单”限定了必须在待支付状态下才能做避免商家已经接单后被用户拍屁股取消。状态流转在后端可以用一个枚举类OrderStatusEnum来维护同时提供一个changeOrderStatus方法里面先查旧状态再判断是否允许迁移到目标状态最后更新。不要在多个Service里到处写update status xxx那样后期查问题会很被动。接口设计上除了常规的增删改查还要考虑几个业务接口获取首页推荐菜品和轮播、按分类分页获取菜品、获取购物车列表刷新价格、创建订单、支付回调模拟、商家后台的今日订单和销售额统计。数据统计可以用SQL聚合也可以用MyBatis-Plus的QueryWrapper总之不要让每个统计接口都全表查出数据在后端循环累加。3. 小程序端开发要点3.1 页面结构与路由设计小程序端页面不要过度设计我见过有些同学非要套TabBar加分包最后把自己绕晕。成人小饭桌的小程序端建议就三个主Tab首页、订单、我的。首页里包含菜品分类、轮播图、菜品列表和搜索入口订单页展示订单列表以及不同状态下快速操作我的页面放用户信息、地址管理、收藏和商家入口。其余页面用普通页面栈菜品详情、购物车、确认订单、确认订单成功、订单详情、编辑地址、评价。全部加起来也就十来个页面工作量基本可控。路由跳转要注意参数传字符串就好不要试着传整个对象不然从后台返回时会得到一坨解析不出来的字符串。购物车这页不放进TabBar而是从首页右上角入口进入会让结构更简单。购物车数据用本地缓存加后端同步两条腿走路。本地缓存让用户随时能看到勾选结果后端同步保证最终创建订单时的价格、库存以服务端为准。实际上我在开发中采取的策略是购物车数据操作时先更新本地缓存界面立即刷新等到点击“去结算”时候再调后端接口实时校验所有商品的库存和最新价格用后端返回到结算页面展示。这样既兼顾了响应速度又把准头留给了后端。3.2 请求封装与登录态管理小程序的wx.request非常不好直接使用我建议所有请求走一个统一封装。封装层要干这几件事拼接baseURL、设置header放token、超时设置、统一处理返回码。比如后端返回401时自动清掉本地token并跳转登录页返回500时给用户一个“服务器开小差”的轻提示。不要每次在页面里重复写loading和错误提示封装成request之后页面里只需要关心自己的数据渲染。登录态管理是小程序的经典痛点。我的实现思路是在小程序启动时app.js的onLaunch先检查本地storage有没有token没有就直接静默登录调用wx.login拿code换token有token但后端返回401时再重新登录。要注意登录接口要做防抖避免多个请求同时触发重新登录不然会连环刷login。一个简单的变量isRefreshing配合一个pending数组就能解决这个实现写出来答辩时就是你比其他人多走一步的证明。3.3 购物车数据存储与同步策略本地购物车用storage存一个数组元素是dishId和quantity。为什么不全量存菜品信息因为菜品价格和名称会变存了也不可靠。页面渲染购物车列表时用本地数据里的dishId去后端批量查最新菜品信息前端再组装。这个方案看似多了一次请求实际却解决了数据一致性问题而且体验很自然。批量查询接口可以设计成POST /dish/listByIds接收一组id返回菜品列表。如果某个菜下架了后端返回时带上status参数前端就直接把该项置灰并禁止勾选结算。这种设计比后端直接返回失败列表要友好得多避免用户每次进购物车都因为某个失效菜品被打断。下单接口提交时后端自己会重新核算价格不要相信小程序端传来的总价。小程序端只是展示一个预计价格真实的total_amount必须由后端遍历订单明细计算。原因很简单前端传多少就收多少的话用户可以改参数白嫖老师问这个问题时你要能说清楚。3.4 支付对接与模拟方案真实微信支付需要商户号、API证书、回调验签等一大堆流程普通学生在毕设里往往搞不定。如果不能真实开通商户号就采用“模拟支付”方案在小程序端点击“立即支付”后不调wx.requestPayment而是调用自己的支付接口后端直接改变订单状态为已支付。同时弹窗提示“当前为模拟支付环境”。但即使模拟也建议按真实支付流程设计接口用户请求支付时会得到一个payInfo小程序端模拟成功后回调confirmPay接口后端在confirmPay里修改状态。这样做的好处是代码结构接近真实项目答辩时老师如果说“你没接入微信支付是不是很假”你可以顺水推舟解释模拟支付是为了避开繁琐的商户资质申请但接口设计保留了后续无痛切换成真实支付的可能性。这句话一出来老师就知道你不是不懂而是有其他顾虑。如果真要做真实支付务必提前申请测试商户号并注意回调地址必须是HTTPS域名。微信支付的回调流程后端还要做签名校验、订单金额比对、防止重复回调。这类扩展点属于加分项有兴趣可以深挖但不作为基本要求。3.5 菜品图片与静态资源处理小程序端直接引用网络图片时需要域名白名单里有imgUrl对应的域名。如果图片是放在SpringBoot的静态目录下那就要确保后端域名和端口能被小程序访问。开发时最简单的方式后端配置上传目录为本地某个文件夹同时配置虚拟路径映射把/img/**映射到那个文件夹。小程序端请求时直接访问http://localhost:8080/img/dish01.jpg配合开发工具的不校验域名选项完全够用。生产环境如果买不起对象存储就放在源码的resources/static/img下打包成jar后还是能访问。不过上传功能就不好实现了需要单独部署到一个固定目录。毕设大都不在乎这点演示时预置菜品图片即可。要小心一个经典坑SpringBoot读取上传文件时multipart前缀乱码或上传目录不存在报FileNotFoundException。提前在配置类里创建目录并统一使用UUID命名文件避免中文文件名导致路径解析问题。这一点在代码里虽然只有三四行但很多人被折腾一晚上。4. 调试运行与毕设避坑指南4.1 环境准备清单从下载源码到跑起来一张清单可以少走很多弯路。JDK建议8或11不要一上来用17有些老项目兼容性麻烦。数据库用MySQL 5.7或8.0。Redis不是必须的如果用到缓存或登录态可以装但最初版本不依赖Redis会省很多事。开发工具方面后端用IDEA前端用微信开发者工具数据库可视化用Navicat或者DataGrip。导入项目第一步改application.yml里的端口、数据库名、账号密码。如果连接报时区错了就在url后面加serverTimezoneAsia/Shanghai。初始化数据库脚本要在源码里找清楚找不到就直接执行一句source或复制到Navicat里跑跑完确认表数量和字段。如果你是在本地跑小程序端请求地址记得写http://localhost:8080不要写127.0.0.1个别情况下两者有差异。如果你用手机真机预览就要把地址改成电脑的局域网IP且手机和电脑在同一个WiFi下。刚上手的人最容易在这个地方抓狂真机上一直提示超时其实不是代码问题而是地址配错。4.2 前后端联调十大常见报错把项目跑起来后第一批问题往往集中在网络和参数上。我整理了一份高频报错自查表基本覆盖百分之八十的联调现场。现象可能原因解决办法小程序请求报request:fail域名未配置或地址不可达或开发工具未勾选不校验合法域名在工具详情里勾选不校验域名本地用局域网IP真机就用HTTPS域名后端报Cross origin error小程序端请求未带跨域头或拦截器处理不当后端开启CORS配置允许所有来源header里加上Authorization报Invalid codewx.login的code失效或被反复使用每次调用wx.login后立即传给后端不要存起来以后用登录后拿不到用户信息wx.getUserProfile只在按钮点击回调里可以调用不是onLoad里能随便用的在页面上放“微信授权登录”按钮用户主动点击后弹出授权小程序端发起POST报404后端RequestMapping路径与前端不一致或者忘了加RequestBody检查接口路径和请求方法调试时后端日志里能看到请求路径对比一下就知道了数据库中文乱码数据库连接字符集未设置url上加characterEncodingutf8建库时使用utf8mb4插入order_item时报外键失败orders表还没插入或事务没生效确认创建订单的方法加Transactional先保存主单拿到id再保存明细上传图片后访问不了虚拟路径未配置在WebMvcConfigurer里addResourceHandlers映射本地磁盘路径返回数据里有字段为null但数据库有值JSON序列化把null字段隐藏了看是否使用了JsonInclude(Include.NON_NULL)去掉或调整即可小程序端页面空白JS报错或请求返回数据格式不对打开控制台看报错重点看result的code判断是否进入错误分支这十条看起来琐碎但每条都对应一次真实踩坑。把这张表贴在项目文档里或者放进设计文档的“运行说明”部分是很加分的。4.3 失败现场与逆袭过程说个我之前帮同学调试的案例。他后端代码看着都对但小程序端一进首页就是白屏后端也没报错。查了老半天发现是他的Controller返回用了一个自定义Result类但字段名是code和message前端却用result.code去判断。这个看起来是前端写错真正原因是前端和后端在接口定义上没沟通好。后来我让他把前端所有接口调用都改走统一封装统一从res.data取code判断问题就消失。另一次调试问题比这个还隐蔽。创建订单后点击支付后端一直说订单状态不是待支付。查了日志发现是因为用户在前端点击下单时把接口重复提交了两次两次请求同时进来后面的那次把状态改成了待支付但前端被第一份响应卡住了。解决方法是增加一个订单号幂等判断如果某个用户已有一个待支付订单且内容和当前订单相同就返回旧订单号而不是重复创建。这个幂等设计在真正支付系统里极其常见你放在毕设里老师就没话可挑。还有一次更离奇小程序真机预览时下单成功但订单列表查不到。最后发现是后端接口按登录用户的openid查询而真机和模拟器拿到的openid不一样。原因在于模拟器的登录用户是测试号真机用的是真实用户后端把两个用户当成一个了。后来把所有测试数据清空重新走一遍登录流程就好了。这也是提醒大家测试数据污染和登录身份不一致比代码Bug更难排查。4.4 文档撰写与答辩技巧毕设文档一般包括选题背景、需求分析、系统设计、数据库设计、核心代码说明、系统测试和总结展望。不要硬挤论文里的“创新点”把一个真实的业务流程讲清楚加上必要的对比分析就非常扎实。文档里至少放两类图功能结构图、数据库ER图、系统流程图。不需要画太复杂能表达模块关系和状态流转即可。不要用Mermaid这类别人看不懂的格式在Word或Visio里画好再插入PDF。核心代码说明要挑重点写JWT登录拦截器、订单事务、购物车同步。不要贴一大段Controller老师会怀疑这是从哪个源码站抄的。写清楚设计思路比如“订单号用时间戳加随机数避免并发重复”这种话比贴300行代码有用。答辩时先用5分钟讲系统演示流程从授权登录到浏览菜品加购下单模拟支付商家端接单完成订单评价。把这条主链路走通老师已经能看出项目能跑。然后针对性准备几个高频问题“为什么选SpringBoot而不是SSH” 答自动配置简化开发、生态成熟、资料多单体够用。“你的项目有并发考虑吗” 答小饭桌属于中小规模业务如果用Redis做热点菜品缓存、用乐观锁防超卖则有扩展空间。“支付是真的吗” 答当前为模拟支付接口设计上预留了真实支付的替换位只要配置商户号和回调验签即可切换。只要你把主流程和这几个问题准备透一场答辩基本就稳了。5. 最后的实操心得这个项目我在动手前也查了一堆资料最后发现很多教程都把重点放在环境配置而不是业务逻辑上。实际开发下来最让我花时间的不是SpringBoot的接口而是小程序端的各种状态管理购物车刷新、订单状态的展示切换、登录态失效的自动处理。如果再来一次我会建议所有做这类毕设的同学先把“创建订单”这条例行的场景走通再回头补页面和样式。这个场景通了你的串讲流程就通了。另外一个小技巧开发时给后端加一个全局日志切面把每个请求的路径和参数打出来时间久了你会发现排查问题的速度提高一大截。别依赖debug断点很多问题是小程序先报错你看不到后端入参加上切面日志后一眼就能看出是不是字段名对不上。还有一个建议就是趁早把小程序基础库版本固定下来。微信开发者工具经常提示升级基础库但某些API在旧设备上兼容性很差。你在文档里写清楚“使用最新稳定基础库开发兼容iOS和Android”就行。别天天追版本稳定压倒一切。如果你准备用这个项目做二次扩展可以加的方向也不少按周预制定饭、配送路线查看、优惠券系统、商家营业时间自动下架等。每加一个方向你的系统复杂度就上一个台阶但核心代码还是围绕我上面讲的这一套逻辑转。先跑通再优化最后再讲这才是毕设最正确的节奏。