不用怀疑毕设选“社区团购”这个方向确实是一个性价比非常高的决定。后端用SpringBoot前端用微信小程序一套完整的线上团购系统——这不仅是近两年计算机专业毕设里的热门选题更是一个真正能用起来、能讲清楚、能展示你工程能力的项目。为什么我敢这么说因为社区团购本身就是一个完整的业务闭环用户端浏览商品、发起拼团、在线支付团长端核销订单、管理小区配送管理后台商品上下架、订单统计。这里面既有基础CRUD又有订单状态机、登录鉴权、接口幂等等复杂逻辑工作量适中技术覆盖面却非常广拿来当毕设绝对够分量而且答辩时能讲的东西特别多。这篇文章我会把这套系统从0到1的完整思路、核心设计、代码实现细节、开发中容易踩的坑以及毕设文档和答辩准备的要点全部掰开揉碎讲清楚。文章里的代码、配置、表结构都是从实际跑通的项目里精简出来的直接可以抄作业。1. 项目整体设计与方案选型1.1 为什么选SpringBoot小程序这套组合做毕设第一步不是写代码是把技术栈定下来。决定了技术栈后续的开发路径和精力投入也就基本定型了。我见过太多人上来就给自己上难度用了微服务、用了Redis集群、用了消息队列实际上系统核心逻辑还没写明白最后交上去自己都讲不清楚。毕设的本质是展示你独立完成一个完整系统的能力不是秀技术有多花哨。SpringBoot最大的优势是“约定大于配置”。同样一套表结构用SSH框架写可能要写大几十行XML配置SpringBoot几个注解就出来了。再加上内置的Tomcat打包直接java -jar就能跑部署流程几乎为零。这对只要求本地演示功能的毕设来说是最稳妥的底盘。小程序端的优势就不用多说了微信的生态摆在那里。用户打开微信就能用不需要装App界面走的是前端那一套需求展示直观。而且小程序开发工具自带模拟器调试方便对不熟悉复杂前端工程的人来说学习曲线也友好得多。另外用户普遍对“微信里能打开的商城”接受度更高演示效果天然就比网页端强一截。我带的几届学弟学妹里凡是选了SpringBoot小程序的后期几乎没有因为技术选型翻车的凡是选了微服务或者其他重框架的一半以上卡在环境配置和分布式问题里出不来。所以你问我推不推荐答案是肯定的。1.2 系统总体架构与角色权限设计这套系统的架构不算复杂属于典型的前后端分离单体应用但业务上并不单薄整体分为三层用户端微信小程序面向小区居民提供商品浏览、团购活动查看、下单支付、订单查询、个人信息管理等功能。服务端SpringBoot单体应用提供RESTful API接口处理业务逻辑、数据持久化、用户鉴权、订单状态流转、定时任务等。管理端后台这里可以做Web端也可以用小程序端内嵌管理页面。我采用的是“H5管理后台小程序用户端”的组合也就是在后端另开一组Controller接口给管理端页面调用本质上还是复用同一套SpringBoot服务。角色权限设计是答辩时一定会被问到的地方需要认真梳理。我设计了三种角色角色权限范围核心操作普通用户小程序端全部功能浏览、下单、支付、收货、评价团长/商家管理自己的商品和订单发布团购、核销订单、查看营收、管理配送点系统管理员全站管理用户管理、分类管理、全局订单管理、数据统计、审核团长申请权限控制上我用SpringBoot的拦截器 自定义注解来实现。后端定义了一个RequireRole注解标注在Controller方法上拦截器根据请求头携带的token解析出用户角色判断是否有权访问。这套方案实现成本低逻辑也直观答辩时非常好讲清楚。有一个容易忽略的细节在实现角色权限前先想清楚“团长”这个角色是怎么来的。我的方案是小程序端提供“申请成为团长”入口填写小区名称、配送地址等信息提交后由管理员在后台审核。审核通过后这个用户才有团长身份。这个流程加上去之后系统的完整度会高一个档次也顺便把“审核”这个业务场景打通了。1.3 核心业务流程图与页面清单系统业务围绕“一次线上团购活动”展开核心流程如下团长在小程序端/后台发布团购活动选择一批商品、设置活动起止时间。普通用户在小程序首页看到拼团活动进入活动页挑选商品并下单。用户支付订单后后台记录支付状态订单进入“待提货”状态。活动结束后团长对订单进行核销用户到小区自提点提货核销后订单完成。后台持续统计团购活动的订单数、销售额给团长和管理员提供数据看板。小程序端主要页面我列一下这些页面在答辩演示时都要逐个过一遍提前准备首页轮播图、团购活动列表、分类入口商品详情页商品图、价格、库存、拼团信息、加入购物车/立即购买确认订单页收货地址选择、商品清单、订单金额、备注订单列表页全部订单/待支付/待提货/已完成/已取消购物车页选中商品、批量下单个人中心页用户信息、地址管理、申请团长入口、我的团购团长工作台发布活动、核销订单、营收统计、配送点管理登录页微信授权登录2. 数据库设计与核心表结构2.1 数据库建模思路社区团购系统的核心实体并不复杂但有几张表的设计很值得花心思。我直接说结论按“用户-商品-团购活动-订单-支付-核销”这条主线来建模就能覆盖90%以上的业务需求。我建的表如下精简版表名说明关键字段user用户表openid、昵称、头像、手机号、角色、小区idcategory商品分类表名称、排序、图标goods商品表名称、主图、轮播图、价格、库存、销量、分类id、团长idgroup_activity团购活动表活动名称、开始时间、结束时间、状态、团长idactivity_goods活动商品关联表活动id、商品id、活动价cart购物车表用户id、商品id、数量、选中状态order订单表订单号、用户id、总金额、状态、地址快照、团长idorder_item订单明细表订单id、商品id、商品名、价格、数量address收货地址表用户id、联系人、电话、详细地址、默认标志recharge_record支付记录表订单id、支付流水号、支付金额、支付时间这里设计表的时候有一个实践中很重要但教科书上很少提的点订单表里要冗余一份“地址快照”。什么意思就是用户下单时把商品名称、价格、收货地址、联系人电话这些信息都原样复制一份存到订单表/订单明细表里。这样做的原因很现实——商品可能改价、可能下架地址可能被用户修改但订单一旦生成就该锚定下单那一刻的信息不能跟着后续变动漂移。团购活动也是一样的思路。我用一张group_activity表记录活动主信息再用activity_goods表把商品以“活动价”挂进活动里。这个设计的好处是同一个商品可以同时被多个活动引用而每个活动可以给不同的价格不直接改动商品原价。业务拓展性一下就上来了。2.2 订单状态的流转设计订单状态是整个系统里最容易出错、也最值得在答辩时展开讲的部分。我采用的是经典状态机模型订单状态字段用int存储0-待支付 - 1-待提货 - 2-已完成 0-待支付 - 3-已取消 1-待提货 - 3-已取消仅管理员/团长可操作这个状态流转是单向的不允许从“已完成”回到“待提货”不允许从“已取消”跳到任意其他状态。在后端代码中我单独写了一个OrderStatusHandler类集中管理状态流转的合法性判断而不是把状态判断散落在各个Service方法里。这个做法非常推荐理由有二一是当状态变多、流转变复杂时集中管理能显著降低出bug的概率二是答辩时你可以直接说自己“采用了状态机模式设计订单生命周期”这是一个很加分的专业表达。有了状态机还需要一个像样的“订单号生成器”。项目里我用的方案是时间戳(yyyyMMddHHmmss) 用户ID后四位 随机数四位。这个方案足够应付日常量级的并发也不会和微信支付的商家订单号要求冲突微信支付要求商户订单号不能重复。2.3 核心SQL与索引优化毕设项目的数据量不会很大但面试或答辩时如果主动聊到索引优化会很加分。我在这套系统里加了两组必要的索引order表idx_user_id(user_id, status) —— 用户查看自己的订单列表时按user_id过滤很常见联合索引能覆盖“用户订单状态”的查询场景。order_item表idx_order_id(order_id) —— 订单明细量级大时按订单号反查明细是最高频的操作。goods表idx_category_id(category_id) —— 分类页的商品列表查询。举个例子小程序端“我的订单”页需要按用户ID和状态分页查询SELECT * FROM order WHERE user_id #{userId} AND status #{status} ORDER BY create_time DESC LIMIT #{offset}, #{pageSize}如果没有idx_user_id联合索引这条SQL在数据量大了以后必然全表扫描几百条数据可能感觉不到但表里上万条订单时用户会明显感觉到页面加载变慢。加了索引之后这个查询基本是毫秒级的。3. 后端SpringBoot核心功能实现3.1 小程序登录鉴权的完整实现小程序端只有一种登录方式微信登录。核心流程是小程序端调用wx.login()获取临时code把code传给后端后端拿着 code appid appsecret 去微信接口换取openid。openid是用户在你这个小程序里的唯一标识存储到user表里后续所有业务都以这个 openid 作为用户身份的依据。后端我用SpringBoot写了一个AuthControllerRestController RequestMapping(/api/auth) public class AuthController { Autowired private UserService userService; PostMapping(/login) public Result login(RequestBody LoginRequest request) { // 1. 使用 code 换取 openid String url https://api.weixin.qq.com/sns/jscode2session ?appid appid secret appSecret js_code request.getCode() grant_typeauthorization_code; String result restTemplate.getForObject(url, String.class); JSONObject json JSON.parseObject(result); if (json.get(errcode) ! null) { return Result.error(微信登录失败: result); } String openid json.getString(openid); // 2. 查询用户是否存在不存在则自动注册 User user userService.findByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户 openid.substring(openid.length() - 6)); user.setRole(0); // 0:普通用户 userService.createUser(user); } // 3. 生成自定义登录态token String token UUID.randomUUID().toString().replace(-, ); tokenService.save(token, user.getId()); return Result.success(token); } }注意这里我生成的token不是JWT而是一个UUID字符串存到了Redis或内存Map里。用UUID的好处是实现简单不用担心密钥泄漏、过期时间控制灵活你可以在Redis里给每一个token设置过期时间比如7天。小程序端拿到token后每次请求都把它放在请求头Authorization字段里后端通过拦截器解析token并找到当前用户。我遇到过不少人问“为什么不用JWT”其实对毕设来说JWT和UUID方案都能跑通。但从答辩的角度JWT的三个组成部分header、payload、signature和签名验证逻辑讲起来更唬人如果你已经熟练掌握用JWT加分如果你只是想稳定跑通UUIDRedis的方案完全够用而且逻辑更好理解。3.2 商品与团购活动的CRUD实现商品和团购的后台管理是实现起来相对机械、但坑也不少的一部分。核心是文件上传。微信小程序端上传图片需要后端提供一个文件上传接口本质上就是SpringBoot的MultipartFile接收文件然后保存到本地磁盘的一个特定目录PostMapping(/upload) public Result upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(上传文件不能为空); } String originalFilename file.getOriginalFilename(); String suffix originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) suffix; // 保存到本地目录实际开发建议用OSS File dir new File(/www/upload/); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, fileName)); // 返回可访问的URL return Result.success(/upload/ fileName); }这里有个容易忽略的坑本地图片路径必须经过SpringBoot的静态资源映射才能被访问。你需要写一个配置类把/upload/**映射到你本地磁盘的真实路径否则小程序端加载图片时会404Configuration public class WebConfig implements WebMvcConfigurer { Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler(/upload/**) .addResourceHandler(file: System.getProperty(user.dir) /upload/); } }实际上完整路径要看你的上传根目录配置在哪个位置写清楚映射关系很重要。我当初第一次做的时候就是忘了配这个静态资源映射结果后台能传图、前端死活显示不出来排查了半小时最后发现是这个配置缺失。3.3 订单生成与支付流程这是全系统最核心的部分。整个下单支付流程我总结为以下步骤用户提交订单小程序端把选中的商品列表、收货地址id、备注一起发给后端。后端校验校验商品是否存在、库存是否足够、价格是否变动。生成订单主表明细表计算订单金额状态设为“待支付”生成唯一订单号。发起微信支付后端调用微信支付统一下单接口获取预支付参数prepay_id返回给小程序端。小程序端拉起支付小程序端通过wx.requestPayment唤起收银台用户输入密码完成支付。支付回调处理微信服务器异步通知后端支付结果后端更新订单状态为“待提货”。第6步是必须做的因为小程序端不能依赖前端返回结果来更新状态万一用户支付成功但小程序退出了回调没收到订单就卡在“待支付”了。我在项目里用一个PayNotifyController专门接收微信支付回调并在回调里做订单金额的二次校验即回调里的金额必须等于数据库中订单的实际金额防止恶意伪造回调。针对毕设如果你没有企业资质无法开通微信支付通常的做法是模拟支付即订单状态在“待支付”状态下提供一个“模拟支付”按钮直接调用后端的模拟支付接口把订单状态更新为“待提货”。这个设计一定要说明清楚答辩时老师大概率会问“你这个支付是真实支付吗”。3.4 定时任务活动自动结束与自动取消订单订单和活动里有两个典型的定时任务场景超时未支付订单自动取消用户下了一个订单但没有支付超过30分钟自动关闭并释放库存。团购活动自动结束活动到达结束时间自动把活动状态从“进行中”改为“已结束”。我用SpringBoot的Scheduled注解实现并打开EnableSchedulingComponent public class OrderTask { Scheduled(cron 0 */5 * * * ?) // 每5分钟执行一次 public void autoCancelOrder() { ListOrder pendingOrders orderMapper.selectPendingTimeoutOrders( new Date(System.currentTimeMillis() - 30 * 60 * 1000)); for (Order order : pendingOrders) { orderService.cancelOrder(order.getId(), 超时未支付系统自动取消); } } }这里批量处理任务的时候最需要关注的是时间窗口的选择cron表达式不能太频繁比如每隔几秒一次否则会造成不必要的数据库压力也不能太长比如一天一次否则订单超时处理的时效性会变差。我实测下来每5分钟扫一次是比较合理的。另外要注意状态判断的并发问题。代码里不能只判断status 0待支付还应该加上create_time 当前时间-30分钟这个条件否则一旦任务还没执行用户刚好在这30分钟内完成了支付任务扫描时就会把刚刚支付成功的订单误判为超时订单并取消这是线上最容易出现的bug。4. 小程序端实现与前后端联调4.1 小程序工程结构与请求封装小程序端的工程结构我建议按业务模块分目录千万别把所有页面堆在pages根目录下。我的目录结构大致是这样miniprogram/ pages/ index/ // 首页 goods/ // 商品详情 cart/ // 购物车 order/ // 订单列表 orderConfirm/ // 确认订单页 user/ // 个人中心 captain/ // 团长工作台 utils/ request.js // 封装 wx.request auth.js // 登录态管理 util.js // 工具函数 api/ goods.js // 商品接口 order.js // 订单接口 auth.js // 登录接口utils/request.js是整个小程序端的核心所有接口请求都必须走这层封装。为什么要封装因为你需要在这里统一做三件事携带token、处理401跳转、统一错误提示。const request (url, method GET, data {}) { return new Promise((resolve, reject) { const token wx.getStorageSync(token) wx.request({ url: BASE_URL url, method: method, data: data, header: { Content-Type: application/json, Authorization: token ? Bearer token : }, success: (res) { if (res.statusCode 401) { // token过期重新登录 wx.removeStorageSync(token) wx.navigateTo({ url: /pages/login/login }) reject(new Error(登录已过期)) return } if (res.data.code 200) { resolve(res.data.data) } else { wx.showToast({ title: res.data.msg || 请求失败, icon: none }) reject(new Error(res.data.msg || 请求失败)) } }, fail: (err) { wx.showToast({ title: 网络异常, icon: none }) reject(err) } }) }) }4.2 登录态管理与首次登录流程小程序端登录流程有两条路径需要分别处理冷启动登录用户首次打开程序时未登录。小程序端先调用wx.login()换取code再调用后端登录接口换取token然后把token存入wx.setStorageSync。token过期恢复任何请求返回401时说明token过期或无效。这时需要静默登录一次即调用wx.login() 后端登录接口刷新token然后再重新发送原请求。实际开发中“token过期恢复”是容易漏掉的处理点。我看到很多项目只在冷启动时登录一次token过期之后就再也无法正常请求了只能让用户退出小程序重新进来。这里我在request.js中增加了一层处理// 在request内部如果遇到401先调用login接口刷新token // 然后用新token重发刚才失败的请求。 function loginAndRetry(options) { return new Promise((resolve, reject) { wx.login({ success: (res) { request(/auth/login, POST, { code: res.code }) .then((res) { wx.setStorageSync(token, res.token) // 重发原请求 request(options.url, options.method, options.data) .then(resolve) .catch(reject) }) .catch(reject) } }) }) }这个“自动重发请求”的机制虽然代码不多但保证了用户无感知刷新登录态体验提升非常明显。答辩时提这个细节也能体现你对登录链路的理解深度。4.3 典型页面实现细节商品详情页是用户决策的核心页面。我会在页面里展示商品主图、价格原价活动价、库存、销量。加入购物车和立即购买两个按钮分别调用不同的接口。注意库存的展示如果库存为0按钮应该置灰并提示“已抢光”这是细节体验但很加分。确认订单页需要重点处理地址选择。用户未填地址时要引导跳转到地址列表页已填地址时默认带出最近使用的地址。地址列表页要支持“设为默认地址”。订单提交成功后页面应该清空购物车中已下单的商品这个逻辑容易被忽略。订单列表页按状态分Tab是最常见的方案待支付、待提货、已完成、已取消。每个Tab单独请求对应的接口并用分页加载。这里我要提醒一个坑小程序onReachBottom事件触发的“加载更多”和onPullDownRefresh的“下拉刷新”都需要处理好“防止重复请求”的逻辑。我项目里用了一个isLoading的布尔标志位let isLoading false const loadOrderList async (status) { if (isLoading) return isLoading true try { const res await getOrderList({ status, page, size }) if (page 1) { this.setData({ orderList: res.records }) } else { this.setData({ orderList: this.data.orderList.concat(res.records) }) } page } finally { isLoading false } }这个标志位能挡住99%的重复请求问题务必要加上。4.4 管理员端H5与小程序的数据联动管理后台我采用的方案是前后端分离的“H5管理端”本质上是一个独立的Web页面通过接口和SpringBoot后端通信。这样做的好处是管理员操作在电脑上进行页面布局更自由商品编辑、订单审核这类操作效率更高比在小程序里做管理页面舒服很多。管理端的数据联动逻辑其实很简单管理端调用和后端之间的一组/admin/**接口后端接口里校验管理员身份然后操作数据库。你只需要确保管理端的登录验证、请求封装、菜单权限和用户端逻辑一致即可。5. 毕设开发中的常见问题与排查技巧5.1 SpringBoot版本相关的坑SpringBoot的版本兼容性是毕设开发中最容易闹心的问题之一。我建议统一使用SpringBoot 2.7.x版本比如2.7.18原因很直接适配JDK 8兼容性极好生态内几乎所有第三方starter都有对应版本。如果你用SpringBoot 3.x就必须搭配JDK 17同时不少老版本的依赖比如某些数据库连接池、Swagger版本会出现兼容性问题排查起来非常浪费时间。还有一个小坑是SpringBoot内置Tomcat的版本差异直接影响部分Web功能。如果遇到奇怪的问题比如上传文件大小受限、接口404优先检查SpringBoot的版本是不是太高了以及是否缺少必要的配置。5.2 小程序合法域名与SSL证书问题小程序真机预览和正式上线前必须在微信公众平台后台配置服务器域名包括request合法域名和uploadFile合法域名。这个配置很关键如果你直接手机访问本地后端接口的IP地址会提示 “不在以下request合法域名列表中”。开发过程中如果你没有线上域名可以临时勾选微信开发者工具里的“不校验合法域名”选项但如果要真机演示最好还是有一个HTTPS的域名。SSL证书这里也要提醒一句小程序要求正式环境的后端接口必须是HTTPS不能用HTTP。一旦你配置了证书但证书过期就会报“小程序显示客户端ssl握手失败”之类的错误。排查这种问题先看证书有效期再用手机浏览器单独访问一下接口如果浏览器也报证书错误那就是证书链的问题如果浏览器能访问但小程序不行那就是小程序配置的问题两者排查路径完全不同。5.3 openid获取失败与“后端鉴权失效”问题小程序登录对接开发中经常有人遇到**“获取微信用户失败: wx1cb4398e1413dce7”** 这样的报错。这个错误本质上就是调用微信登录接口时code不正当或重复使用导致的。我遇到过不少次总结下来原因有几种wx.login()获取的 code 只能用一次重复提交就会报错。code 有效期很短5分钟如果用户很久才触发下单后端拿到的code可能已过期。后端调用jscode2session接口时接口域名拼写错误或参数缺失。排查方法其实很简单后端在拿到 code 时打日志把请求微信的完整URL打印出来然后用 postman 单独请求一次微信接口看返回结果。如果返回errcode: 40029那就是 code 无效或过期如果返回appid与secret不匹配那就是小程序后台的 AppSecret 配置错了到微信公众平台重置一下即可。5.4 真机调试与模拟器的差异问题很多页面在小程序开发者工具模拟器里一切正常一到真机就出问题这常见于底部安全区适配、键盘弹起遮挡输入框等问题。我踩过的具体坑有两个第一个是iPhone的底部小黑条Home Indicator遮挡。如果页面有固定在底部的按钮比如“立即购买” “去结算”在iPhone X以上机型会有一部分内容被小黑条挡住再往下是“胶囊按钮”和TabBar的兼容问题。解决方式是在小程序的全局样式app.wxss里加上page { padding-bottom: constant(safe-area-inset-bottom); padding-bottom: env(safe-area-inset-bottom); }第二个是安卓手机的浏览器内核差异。某些安卓机型上用position: fixed的弹层会闪退或位置错乱建议使用cover-view组件来实现地图、视频上层的覆盖内容。5.5 常见问题速查表问题现象可能原因排查思路小程序图片加载不出来静态资源映射未配置浏览器直接访问图片路径看是否能打开登录成功但接口请求401token未携带或过期检查请求头Authorization字段支付回调一直触发不了回调域名未配置或回调逻辑异常先看后端日志确认微信是否已请求列表分页重复请求缺少loading标志位加上isLoading防止重复每次登录openid都不一样appid或secret配置错误核对微信公众平台后台的配置6. 毕设文档LW与答辩准备6.1 LW论文怎么写才不空洞毕设论文是整个毕设环节中占比很大的一部分不要等项目写完了才开始写论文那样你会非常痛苦。我的经验是把论文写作拆成阶段任务和开发同步推进。论文的框架大致如下第一章 绪论研究背景、国内外研究现状、研究目的与意义第二章 相关技术介绍SpringBoot、小程序开发框架、MySQL、微信支付、RESTful架构等第三章 系统分析可行性分析、需求分析功能性需求非功能性需求、用例分析第四章 系统设计总体架构设计、功能模块设计、数据库设计、接口设计第五章 系统实现核心功能模块的界面截图核心代码实现逻辑说明第六章 系统测试测试环境、测试用例、测试结果分析第七章 总结与展望这里有个很实用的建议第五章“系统实现”不要事无巨细全写只挑4-5个最核心的功能模块展开比如登录鉴权、商品管理、下单流程、订单管理。每个模块的展开套路是功能描述 → 页面截图 → 核心代码/逻辑讲解 → 实现效果说明。这样写不仅拿字数稳而且答辩时老师很容易在里面找到提问点你也能答上来。6.2 说明文档怎么组织说明文档README主要面向的是“让一个陌生人在短时间内跑起项目”。这部分虽然不参与评分但它是一个隐性加分项因为不少评审老师会真的按文档去启动你的项目试一试。我的说明文档包含这六部分项目简介与技术栈环境要求JDK版本、MySQL版本、Maven版本、微信开发者工具版本数据库初始化SQL文件导入步骤及账号密码说明后端启动步骤修改application.yml配置、启动类运行方式小程序端启动步骤导入项目、修改appid、配置合法域名、运行默认账号说明管理员账号、团长账号的初始密码这里最容易忽略的是appid 和 secret 要提示用户替换成自己的。很多人把自己申请的小程序appid写在代码里到处发别人复制过去用不了还以为是代码问题。文档开头加黑体提示一句“使用前请替换为你自己的小程序appid和secret”。6.3 答辩演示的节奏把控答辩演示是整个毕设的临门一脚。我见过代码写得不错、但演示效果稀碎的人最后分数并不高。演示的时候要注意节奏建议按下面的顺序走花1分钟介绍系统定位和技术选型让老师先有整体认知。演示用户端从微信小程序打开系统 → 首页浏览团购活动 → 进入商品详情 → 加入购物车 → 下单 → 模拟支付 → 查看订单。演示团长端登录团长账号 → 发布团购活动 → 商品上下架 → 核销订单。演示管理端登录管理员账号 → 用户管理 → 商品管理 → 数据统计。预留QA准备几个老师可能问的问题比如“为什么这个表要加索引”“订单状态是如何流转的”“如果支付回调失败了怎么办”。最后还有一个实操小建议演示环境务必提前准备好数据库先启动好、后端先跑起来、小程序开发者工具已经打开。不要在答辩现场花时间等SpringBoot冷启动或者等小程序编译现场等待是所有演示事故里最高频的一种。7. 一些过来人的额外建议最后再分享几条个人体会。这套系统从开发到完成如果每天投入3-4小时大约三到四周能跑通核心流程再花一到两周补充细节、写文档、做测试时间线算是比较宽裕。真正花时间的不是代码而是订单流程的边界情况处理和线上环境的兼容性问题这两块预留的时间要充分。另外关于代码规范。项目里Controller、Service、Mapper三层结构分得清楚类名和方法名尽量见名知义数据库注释写完整。这些看起来是小事但在答辩时老师翻到你的代码一眼扫过去印象分差别很大。一个干净整洁的工程结构比一个功能完整但乱成一锅粥的工程结构更让人愿意给高分。如果你打算在这个项目基础上继续扩展我推荐两个方向。一个是接入真实微信支付把模拟支付替换为正式支付链路这样项目就具备了上线商用的潜力。另一个是增加数据可视化分析模块比如用ECharts生成团长销售排行、商品热力图等报表能进一步体现数据分析能力。这两个方向无论对毕设评级还是对后续求职都是实打实的加分项。做毕设本身就是一个从“看别人代码”到“写自己代码”的过程中间一定会走弯路但正是因为这些踩坑、解决、再优化的过程你才会真正理解一个完整的业务系统是怎么运转的。希望这篇文章里的思路和经验能让你的开发过程顺一些也让你的项目成为那个能在答辩现场从容展示的作品。