选题那阵子我把开放社区和代码仓库翻了个底朝天最终敲定“基于SpringBoot的社区超市生鲜团购平台”时身边同学的第一反应都是这不就是个换了肤色的下单系统可真正把需求理完、代码写到一半我才承认低估了这个题目。社区团购表面上只是“把超市搬到线上”实际牵扯到的拼团成团规则、生鲜库存的时效扣减、次日自提的核销流程、缺货售后的状态回滚每一项单拎出来都够写一篇小专题。这篇文章就围绕这个毕设项目做一次完整复盘。如果你是正在选毕设题目的学生或者想拿SpringBoot项目练手、甚至面试时作为项目讲解的开发者我想告诉你这个选题的边界在哪哪些模块是答辩必问的哪些坑是我不踩一遍绝对发现不了的。源码结构、数据库设计、核心代码逻辑、部署演示、答辩应答我会按做项目的顺序一路讲下来。1. 这个选题为什么值得做生鲜团购不是另一个“电商CRUD”1.1 表面是下单实际是社区团购的业务闭环先聊业务。普通电商系统的核心动作是“搜索-加购-下单-支付-快递送达”全程只有买家和平台两个角色在线上打交道。但社区生鲜团购的链路完全不同平台按小区组织预售用户今天下单、明天自提生鲜商品从超市出库后配送到社区由某个线下提货点通常叫“团长”完成分拣和交付。这一下就多出了三个现实问题拼团状态一个团购活动是“进行中”“已成团”还是“已过期”谁来维护、何时更新库存时效生鲜不能按普通电商的“下单即减库存”来处理因为用户还会取消、退款、缺货而蔬菜水果的库存又是按天采购的。交付闭环订单在“已支付”之后并没有结束还要经过备货、分拣、自提、核销最后才进售后入口。这就是我说“不是另一个电商CRUD”的原因。CRUD系统只关心数据的增删改查而社区团购平台更关心“数据状态之间的流转是否严谨”。状态流转一旦理不清代码层面就会到处打补丁最后自己都看不懂。1.2 技术难点浓度足够但又不至于失控作为毕设选题难度要卡在“评委会追问、你答得上来”的位置。SpringBoot做后端是标准答案但单纯做CRUD又显不出水平。社区生鲜团购刚好踩在分界线上涉及 Spring Security / JWT 做用户鉴权这是权限设计的必修课涉及 Redis 做活动数据缓存和库存预扣让项目有了“中间件应用”的谈资涉及订单事务的 ACID 边界能讲清楚“哪几步必须同一事务、哪几步可以异步”涉及支付回调的幂等设计哪怕只是模拟也能体现工程意识。同时它又不像秒杀系统那样需要极端并发性能不需要上微服务、消息队列、分库分表。复杂度可控设备要求低一台普通电脑加一台云服务器就能完整跑通。这正是毕业设计最舒服的难度区间别人看得到你的工作量你也守得住每个细节。2. 先把业务理顺三个角色和一条完整交易链路2.1 用户、团长、超市管理员三方视角我在做系统设计时把整个平台分成三个端用户端H5或小程序注册登录、浏览当前社区正在进行的团购活动、查看商品详情、发起/参与拼团、在线支付、生成提货码、到货后评价以及申请退款。团长端管理自己负责的社区查看每天配送到本社区的商品清单逐个核销用户提货码处理少货/坏货反馈查看自己的佣金。超市管理端维护商品与分类、设置团购活动与参团人数门槛、管理订单状态、查看销售统计。注意我特意没有把“用户下单后直接到超市自提”纳入主流程。社区超市生鲜团购的核心运营单位是“社区团长”如果省略团长角色整个系统就退回成普通电商答辩时也缺少业务特色。2.2 “今日下单、明日自提”的主流程拆解主流程我用一句话串起来用户选择一个社区看到该社区正在进行的团购活动发起或加入某个团支付订单超市端按订单备货第二天送货到社区用户凭提货码到团长处核销取货订单完成团长获得佣金。这个流程里有几个容易被忽略的细节用户选址每个商品、每个活动必须绑定社区用户看不到其他社区的库存。这是社区团购与普通电商的差异点。拼团与普通下单并存系统里既允许用户单独购买也允许拼团购买。单独购买就是标准的电商订单拼团购买要维护“团”的实体。提货码设计核销凭证最好是短码如8位字母数字而不是直接用订单号。原因是团长端需要一个快速输入或扫描的凭证订单号太长了。2.3 售后与退款最容易在设计阶段漏掉的部分很多初版设计把思路全放在“正向流程”上真实项目里售后才是最容易产生脏数据的地方。我遇到过的场景用户支付后没去提货过了提货期钱怎么退到手发现缺斤少两团长确认后的“部分退款”怎么记账拼团订单里某一件商品缺货是整单取消还是部分取消我的建议是在数据库设计阶段就为售后留出状态位而不是等问题出现再补字段。后面第4章会讲具体怎么落地。总之不要让“退款”成为代码里的孤儿操作。3. 技术选型我用SpringBoot Vue这套组合的理由3.1 后端选型逻辑刚需、生态、可控后端我选了Spring Boot 2.7.x MyBatis Plus MySQL 8.0 Redis。理由很直接SpringBoot的自动配置和Starter机制能把开发效率拉满一个人短期内写完整套后端是可行的MyBatis Plus帮我在单表CRUD上省下大量样板代码复杂查询用自定义SQL仍然完全可控JWT Spring Security做登录鉴权既能演示安全设计又比Session方案更适合前后端分离。有人会问为什么不直接上Spring Cloud微服务我的态度很明确毕设项目的体量不需要微服务强行上只会让答辩变成“为什么你每个服务里只有两三个接口”的拷问现场。单体应用把模块边界划清楚一样能讲出架构感。3.2 缓存层Redis在这里是功能件不只是性能件很多项目把Redis当作“给接口加速”的缓存但在这个平台里Redis承担了更核心的职责拼团人数的原子计数人们同时参团时用Redis的INCR命令保证人数不超比数据库行锁逻辑简单得多库存预扣用户提交订单时先在Redis里扣减“可售数”超卖风险在这里就被拦住了活动状态缓存团购活动的开始/结束时间频繁读取从Redis取可以减少数据库压力。这三点不是锦上添花而是直接影响正确性。答辩时说出“我用Redis的原子操作解决了并发超卖问题”比只讲MyBatis Plus写接口有明显区分度。3.3 工程目录设计让答辩和演示都舒服我的后端工程结构大致是这样的src/main/java ├── config # Security配置、Redis配置、全局异常处理 ├── controller # 用户端、团长端、管理端接口 ├── service # 业务逻辑层核心交易逻辑都在这层 ├── mapper # MyBatis Plus的Mapper接口 ├── entity # 数据库实体 ├── dto # 前端入参对象 ├── vo # 返回给前端的视图对象 └── common # 统一返回体、常量、工具类前端我用的是Vue 2 Element UI别问为什么不用Vue 3问就是生态资料多、踩坑成本低。管理端和用户端共用一套代码通过路由和权限控制区分入口这样演示时只需要启动一个前端工程。如果想让项目更有卖相也可以把用户端改成uni-app一套代码打包H5和小程序。但时间紧张的话H5足够。4. 数据库设计生鲜业务把哪些“坑”埋在了表结构里4.1 九张核心业务表与关键字段设计数据库是毕设真正藏功夫的地方。我最后沉淀下来的核心表有这些表名作用关键字段说明user平台用户role区分用户/团长/管理员inviter_id记录上级团长community社区团长与社区一对一用户下单前必须绑定社区category生鲜分类蔬菜、水果、肉禽、水产、乳品product商品stock可售库存、locked_stock锁定库存、unit单位activity团购活动关联商品与社区包含成团人数、开始/结束时间purchase_group团实例一次开团产生一个团status跟踪开团/已成团/已过期group_member团成员一人一条参团记录记录参团时间和支付状态orders订单主表订单号、用户、社区、状态、支付方式、提货码order_item订单明细快照商品名、价格、数量避免商品改价影响历史订单另加 review 评价表和 refund_order 退款申请表一个是业务完整度需要一个是答辩时能讲“售后闭环”。4.2 库存设计预留、锁定与超卖的底线生鲜库存的难点在于“下单不等于立刻出库”。用户下单、支付后超市才进入备货阶段。如果用户取消订单库存要释放如果备货时发现缺货库存也要同步修正。所以我给商品表设计了两个字段stock当前仓库实际可采购/可售数量。locked_stock已被有效订单锁定但尚未出库的数量。用户可购买的剩余量是stock - locked_stock。下单时先做一次乐观锁更新UPDATE product SET stock stock - #{count}, locked_stock locked_stock #{count}, version version 1 WHERE id #{productId} AND stock #{count} AND version #{version}这行SQL的意思是只有“当前库存够扣”并且“版本号没变”时才允许扣减否则影响行数为0业务层捕获后提示“库存不足”。这样处理下来超卖问题在数据库层面就挡住了。库存释放同理取消订单时把locked_stock减回来即可。4.3 订单状态机自提场景下的状态流转设计订单是整条链路的中心状态必须一开始就规划好。我用了一个字符串状态字段取值如下状态含义触发动作PENDING_PAY待支付用户下单成功PAID已支付支付回调成功PREPARING备货中管理员确认开始备货READY待自提货物已送达社区COMPLETED已完成团长核销提货码CANCELED已取消超时未支付/用户取消REFUNDING退款中用户申请售后REFUNDED已退款退款完成关键点在于不是所有状态都能互相跳转。比如CANCELED不能再变回PAIDREFUNDED之后不能再核销。我在Service层写了一个状态流转校验方法每次更新前检查“当前状态是否允许目标状态”这比在Controller里到处写if判断要稳健得多。5. 三个核心链路的代码实现拆解5.1 拼团开团、参团、成团与超时释放拼团是这个平台最有辨识度的功能。我分三步实现开团用户选择活动后如果没有进行中的团就创建一条purchase_group记录状态OPEN并把当前用户写入group_member。开团用户自动成为团长此团长指拼团发起人与线下提货团长不是一回事这里容易在答辩时被追问提前想清楚措辞。参团用户加入一个OPEN状态的团。参团先扣Redis里的“团剩余名额”名额扣成功再写数据库。核心逻辑Long remain redisTemplate.opsForValue() .decrement(group:remain: groupId); if (remain 0) { // 名额已满把计数器加回去并抛异常 redisTemplate.opsForValue().increment(group:remain: groupId); throw new BizException(该团名额已满); }没有直接查数据库再判断就是避免两个人同时读到“还剩1个名额”后都插入成功导致参团人数超限。成团与超时每次参团成功后把group_member的数量和活动要求的成团人数比较达到就更新purchase_group.status SUCCESS。如果到活动结束时间仍未满员则定时任务把所有仍在OPEN状态的团批量置为FAILED同时把成员的订单改为取消并原路退款。这个定时任务用Spring的Scheduled每5分钟扫一次即可毕设体量完全够用。5.2 下单与事务边界多表写入如何保证一致下单接口涉及商品库存、订单主表、订单明细、购物车清理四个动作。这四步必须是一个事务任何一步失败都不能留下半截数据。我用Transactional圈住整个方法并注意一件事把远程操作移出事务。比如支付链接的生成如果是调用第三方接口就不应该放在这个事务里避免长时间占用数据库连接。典型的下单流程长这样校验活动状态和社区匹配三方锁扣库存失败则整体回滚创建订单主记录状态PENDING_PAY批量插入订单明细清空购物车生成支付单号返回给前端唤起支付。事务提交前我还会把“库存扣减记录”写到一张库存流水表里。这张表平时看起来没用但排查问题、做对账时是救命的。5.3 支付回调模拟、验签与幂等毕设不可能真的接第三方支付但又不能不演示支付流程。我的做法是写一个模拟支付网关前端弹出支付对话框用户点击“确认支付”请求这个模拟支付接口接口“假装”调用了外部支付平台然后异步回调自己的通知接口。真实业务里支付平台会多次回调所以最关键是幂等。我用支付流水号作为唯一业务键处理前先查这个流水号是否已经处理过处理过直接返回成功不再重复操作。// 幂等判断同一支付流水号只允许成功处理一次 String payNo payNotifyDTO.getPayNo(); if (null ! orderService.getByPayNo(payNo)) { return success; } // 验签 if (!signVerify(payNotifyDTO)) { return fail; } // 更新订单状态、通知店铺发货 orderService.paySuccess(payNo);这个paySuccess方法里再锁订单行、判状态、改状态。就算回调来了三遍也只有第一遍生效。演示时我可以现场把回调接口连调三次展示第二三次都被幂等拦截这一手在答辩时很加分。6. 部署演示与答辩准备别让好项目栽在最后一步6.1 Docker Compose一键启动与演示数据很多同学项目代码写完了但交给老师验收时环境起不来直接扣分。我更推荐用Docker Compose把环境固定下来services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: 123456 MYSQL_DATABASE: fresh_goods ports: - 3306:3306 redis: image: redis:7 ports: - 6379:6379 app: build: . ports: - 8080:8080 depends_on: - mysql - redis一条docker compose up -d就能把MySQL、Redis、后端服务全部拉起来。前端我再配一个Nginx容器静态资源打包后丢进去整站直接通过80端口访问。另外一定要准备一套演示数据两三个社区、四五个活动、十几款生鲜商品、一个测试账号、一个团长账号。老师看演示时不可能注册一个新账号慢慢逛你直接告诉他“管理员账号是什么、团长账号是什么”流程就顺畅了。我还会在数据里预留一个“即将过期”的团和一个“已成团”的团现场演示定时任务效果。6.2 答辩追问Top 5与应答思路我把被问得最多的问题列在下面每个问题背后都对应一个设计决策追问建议应答角度为什么不用微服务项目规模与团队规模决定架构单体模块化可以快速交付引入微服务会增加一致的分布式事务成本库存超卖怎么解决乐观锁SQL条件更新Redis预扣两条防线数据库层面保证负数不可能出现Redis宕机了怎么办保留数据库的乐观锁兜底Redis作为性能层可降级重启后重新预热活动数据拼团人数不足怎么办定时任务扫描超时未成团的团自动置为失败并触发退款支付回调重复通知怎么处理支付流水号唯一约束状态机校验第二三次调用直接拦截回答的时候不要背概念要拿自己代码里的方法名和SQL举例。比如讲乐观锁时直接念一遍那条UPDATE ... WHERE stock #{count}比空谈“乐观锁”三个字有说服力得多。6.3 一些零碎但很实际的建议最后几件小事看着不起眼但影响体验后端全局异常处理一定要做不要让数据库的异常信息直接打到前端页面上前后端联调时统一好返回体格式我全程用{ code, message, data }三件套后期没有因为字段歧义浪费过时间上传代码前把本地数据库连接密码改成弱密码并写清启动文档方便别人一键复现文档里放几张核心流程截图和表关系图老师还没看代码就对你的项目有了整体印象。如果让我重新做一次这个毕设我最想提醒自己的是别急着打开IDE写接口先把业务流程图和订单状态图画明白。很多卡壳都不是写代码卡壳而是业务没想清楚。等到一遍遍debug拼团超员、订单状态不一致的时候你才会体会到那些看似没用的设计文档其实才是最值钱的部分。希望这篇复盘能帮你少走几步弯路。
选题那阵子我把开放社区和代码仓库翻了个底朝天最终敲定“基于SpringBoot的社区超市生鲜团购平台”时身边同学的第一反应都是这不就是个换了肤色的下单系统可真正把需求理完、代码写到一半我才承认低估了这个题目。社区团购表面上只是“把超市搬到线上”实际牵扯到的拼团成团规则、生鲜库存的时效扣减、次日自提的核销流程、缺货售后的状态回滚每一项单拎出来都够写一篇小专题。这篇文章就围绕这个毕设项目做一次完整复盘。如果你是正在选毕设题目的学生或者想拿SpringBoot项目练手、甚至面试时作为项目讲解的开发者我想告诉你这个选题的边界在哪哪些模块是答辩必问的哪些坑是我不踩一遍绝对发现不了的。源码结构、数据库设计、核心代码逻辑、部署演示、答辩应答我会按做项目的顺序一路讲下来。1. 这个选题为什么值得做生鲜团购不是另一个“电商CRUD”1.1 表面是下单实际是社区团购的业务闭环先聊业务。普通电商系统的核心动作是“搜索-加购-下单-支付-快递送达”全程只有买家和平台两个角色在线上打交道。但社区生鲜团购的链路完全不同平台按小区组织预售用户今天下单、明天自提生鲜商品从超市出库后配送到社区由某个线下提货点通常叫“团长”完成分拣和交付。这一下就多出了三个现实问题拼团状态一个团购活动是“进行中”“已成团”还是“已过期”谁来维护、何时更新库存时效生鲜不能按普通电商的“下单即减库存”来处理因为用户还会取消、退款、缺货而蔬菜水果的库存又是按天采购的。交付闭环订单在“已支付”之后并没有结束还要经过备货、分拣、自提、核销最后才进售后入口。这就是我说“不是另一个电商CRUD”的原因。CRUD系统只关心数据的增删改查而社区团购平台更关心“数据状态之间的流转是否严谨”。状态流转一旦理不清代码层面就会到处打补丁最后自己都看不懂。1.2 技术难点浓度足够但又不至于失控作为毕设选题难度要卡在“评委会追问、你答得上来”的位置。SpringBoot做后端是标准答案但单纯做CRUD又显不出水平。社区生鲜团购刚好踩在分界线上涉及 Spring Security / JWT 做用户鉴权这是权限设计的必修课涉及 Redis 做活动数据缓存和库存预扣让项目有了“中间件应用”的谈资涉及订单事务的 ACID 边界能讲清楚“哪几步必须同一事务、哪几步可以异步”涉及支付回调的幂等设计哪怕只是模拟也能体现工程意识。同时它又不像秒杀系统那样需要极端并发性能不需要上微服务、消息队列、分库分表。复杂度可控设备要求低一台普通电脑加一台云服务器就能完整跑通。这正是毕业设计最舒服的难度区间别人看得到你的工作量你也守得住每个细节。2. 先把业务理顺三个角色和一条完整交易链路2.1 用户、团长、超市管理员三方视角我在做系统设计时把整个平台分成三个端用户端H5或小程序注册登录、浏览当前社区正在进行的团购活动、查看商品详情、发起/参与拼团、在线支付、生成提货码、到货后评价以及申请退款。团长端管理自己负责的社区查看每天配送到本社区的商品清单逐个核销用户提货码处理少货/坏货反馈查看自己的佣金。超市管理端维护商品与分类、设置团购活动与参团人数门槛、管理订单状态、查看销售统计。注意我特意没有把“用户下单后直接到超市自提”纳入主流程。社区超市生鲜团购的核心运营单位是“社区团长”如果省略团长角色整个系统就退回成普通电商答辩时也缺少业务特色。2.2 “今日下单、明日自提”的主流程拆解主流程我用一句话串起来用户选择一个社区看到该社区正在进行的团购活动发起或加入某个团支付订单超市端按订单备货第二天送货到社区用户凭提货码到团长处核销取货订单完成团长获得佣金。这个流程里有几个容易被忽略的细节用户选址每个商品、每个活动必须绑定社区用户看不到其他社区的库存。这是社区团购与普通电商的差异点。拼团与普通下单并存系统里既允许用户单独购买也允许拼团购买。单独购买就是标准的电商订单拼团购买要维护“团”的实体。提货码设计核销凭证最好是短码如8位字母数字而不是直接用订单号。原因是团长端需要一个快速输入或扫描的凭证订单号太长了。2.3 售后与退款最容易在设计阶段漏掉的部分很多初版设计把思路全放在“正向流程”上真实项目里售后才是最容易产生脏数据的地方。我遇到过的场景用户支付后没去提货过了提货期钱怎么退到手发现缺斤少两团长确认后的“部分退款”怎么记账拼团订单里某一件商品缺货是整单取消还是部分取消我的建议是在数据库设计阶段就为售后留出状态位而不是等问题出现再补字段。后面第4章会讲具体怎么落地。总之不要让“退款”成为代码里的孤儿操作。3. 技术选型我用SpringBoot Vue这套组合的理由3.1 后端选型逻辑刚需、生态、可控后端我选了Spring Boot 2.7.x MyBatis Plus MySQL 8.0 Redis。理由很直接SpringBoot的自动配置和Starter机制能把开发效率拉满一个人短期内写完整套后端是可行的MyBatis Plus帮我在单表CRUD上省下大量样板代码复杂查询用自定义SQL仍然完全可控JWT Spring Security做登录鉴权既能演示安全设计又比Session方案更适合前后端分离。有人会问为什么不直接上Spring Cloud微服务我的态度很明确毕设项目的体量不需要微服务强行上只会让答辩变成“为什么你每个服务里只有两三个接口”的拷问现场。单体应用把模块边界划清楚一样能讲出架构感。3.2 缓存层Redis在这里是功能件不只是性能件很多项目把Redis当作“给接口加速”的缓存但在这个平台里Redis承担了更核心的职责拼团人数的原子计数人们同时参团时用Redis的INCR命令保证人数不超比数据库行锁逻辑简单得多库存预扣用户提交订单时先在Redis里扣减“可售数”超卖风险在这里就被拦住了活动状态缓存团购活动的开始/结束时间频繁读取从Redis取可以减少数据库压力。这三点不是锦上添花而是直接影响正确性。答辩时说出“我用Redis的原子操作解决了并发超卖问题”比只讲MyBatis Plus写接口有明显区分度。3.3 工程目录设计让答辩和演示都舒服我的后端工程结构大致是这样的src/main/java ├── config # Security配置、Redis配置、全局异常处理 ├── controller # 用户端、团长端、管理端接口 ├── service # 业务逻辑层核心交易逻辑都在这层 ├── mapper # MyBatis Plus的Mapper接口 ├── entity # 数据库实体 ├── dto # 前端入参对象 ├── vo # 返回给前端的视图对象 └── common # 统一返回体、常量、工具类前端我用的是Vue 2 Element UI别问为什么不用Vue 3问就是生态资料多、踩坑成本低。管理端和用户端共用一套代码通过路由和权限控制区分入口这样演示时只需要启动一个前端工程。如果想让项目更有卖相也可以把用户端改成uni-app一套代码打包H5和小程序。但时间紧张的话H5足够。4. 数据库设计生鲜业务把哪些“坑”埋在了表结构里4.1 九张核心业务表与关键字段设计数据库是毕设真正藏功夫的地方。我最后沉淀下来的核心表有这些表名作用关键字段说明user平台用户role区分用户/团长/管理员inviter_id记录上级团长community社区团长与社区一对一用户下单前必须绑定社区category生鲜分类蔬菜、水果、肉禽、水产、乳品product商品stock可售库存、locked_stock锁定库存、unit单位activity团购活动关联商品与社区包含成团人数、开始/结束时间purchase_group团实例一次开团产生一个团status跟踪开团/已成团/已过期group_member团成员一人一条参团记录记录参团时间和支付状态orders订单主表订单号、用户、社区、状态、支付方式、提货码order_item订单明细快照商品名、价格、数量避免商品改价影响历史订单另加 review 评价表和 refund_order 退款申请表一个是业务完整度需要一个是答辩时能讲“售后闭环”。4.2 库存设计预留、锁定与超卖的底线生鲜库存的难点在于“下单不等于立刻出库”。用户下单、支付后超市才进入备货阶段。如果用户取消订单库存要释放如果备货时发现缺货库存也要同步修正。所以我给商品表设计了两个字段stock当前仓库实际可采购/可售数量。locked_stock已被有效订单锁定但尚未出库的数量。用户可购买的剩余量是stock - locked_stock。下单时先做一次乐观锁更新UPDATE product SET stock stock - #{count}, locked_stock locked_stock #{count}, version version 1 WHERE id #{productId} AND stock #{count} AND version #{version}这行SQL的意思是只有“当前库存够扣”并且“版本号没变”时才允许扣减否则影响行数为0业务层捕获后提示“库存不足”。这样处理下来超卖问题在数据库层面就挡住了。库存释放同理取消订单时把locked_stock减回来即可。4.3 订单状态机自提场景下的状态流转设计订单是整条链路的中心状态必须一开始就规划好。我用了一个字符串状态字段取值如下状态含义触发动作PENDING_PAY待支付用户下单成功PAID已支付支付回调成功PREPARING备货中管理员确认开始备货READY待自提货物已送达社区COMPLETED已完成团长核销提货码CANCELED已取消超时未支付/用户取消REFUNDING退款中用户申请售后REFUNDED已退款退款完成关键点在于不是所有状态都能互相跳转。比如CANCELED不能再变回PAIDREFUNDED之后不能再核销。我在Service层写了一个状态流转校验方法每次更新前检查“当前状态是否允许目标状态”这比在Controller里到处写if判断要稳健得多。5. 三个核心链路的代码实现拆解5.1 拼团开团、参团、成团与超时释放拼团是这个平台最有辨识度的功能。我分三步实现开团用户选择活动后如果没有进行中的团就创建一条purchase_group记录状态OPEN并把当前用户写入group_member。开团用户自动成为团长此团长指拼团发起人与线下提货团长不是一回事这里容易在答辩时被追问提前想清楚措辞。参团用户加入一个OPEN状态的团。参团先扣Redis里的“团剩余名额”名额扣成功再写数据库。核心逻辑Long remain redisTemplate.opsForValue() .decrement(group:remain: groupId); if (remain 0) { // 名额已满把计数器加回去并抛异常 redisTemplate.opsForValue().increment(group:remain: groupId); throw new BizException(该团名额已满); }没有直接查数据库再判断就是避免两个人同时读到“还剩1个名额”后都插入成功导致参团人数超限。成团与超时每次参团成功后把group_member的数量和活动要求的成团人数比较达到就更新purchase_group.status SUCCESS。如果到活动结束时间仍未满员则定时任务把所有仍在OPEN状态的团批量置为FAILED同时把成员的订单改为取消并原路退款。这个定时任务用Spring的Scheduled每5分钟扫一次即可毕设体量完全够用。5.2 下单与事务边界多表写入如何保证一致下单接口涉及商品库存、订单主表、订单明细、购物车清理四个动作。这四步必须是一个事务任何一步失败都不能留下半截数据。我用Transactional圈住整个方法并注意一件事把远程操作移出事务。比如支付链接的生成如果是调用第三方接口就不应该放在这个事务里避免长时间占用数据库连接。典型的下单流程长这样校验活动状态和社区匹配三方锁扣库存失败则整体回滚创建订单主记录状态PENDING_PAY批量插入订单明细清空购物车生成支付单号返回给前端唤起支付。事务提交前我还会把“库存扣减记录”写到一张库存流水表里。这张表平时看起来没用但排查问题、做对账时是救命的。5.3 支付回调模拟、验签与幂等毕设不可能真的接第三方支付但又不能不演示支付流程。我的做法是写一个模拟支付网关前端弹出支付对话框用户点击“确认支付”请求这个模拟支付接口接口“假装”调用了外部支付平台然后异步回调自己的通知接口。真实业务里支付平台会多次回调所以最关键是幂等。我用支付流水号作为唯一业务键处理前先查这个流水号是否已经处理过处理过直接返回成功不再重复操作。// 幂等判断同一支付流水号只允许成功处理一次 String payNo payNotifyDTO.getPayNo(); if (null ! orderService.getByPayNo(payNo)) { return success; } // 验签 if (!signVerify(payNotifyDTO)) { return fail; } // 更新订单状态、通知店铺发货 orderService.paySuccess(payNo);这个paySuccess方法里再锁订单行、判状态、改状态。就算回调来了三遍也只有第一遍生效。演示时我可以现场把回调接口连调三次展示第二三次都被幂等拦截这一手在答辩时很加分。6. 部署演示与答辩准备别让好项目栽在最后一步6.1 Docker Compose一键启动与演示数据很多同学项目代码写完了但交给老师验收时环境起不来直接扣分。我更推荐用Docker Compose把环境固定下来services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: 123456 MYSQL_DATABASE: fresh_goods ports: - 3306:3306 redis: image: redis:7 ports: - 6379:6379 app: build: . ports: - 8080:8080 depends_on: - mysql - redis一条docker compose up -d就能把MySQL、Redis、后端服务全部拉起来。前端我再配一个Nginx容器静态资源打包后丢进去整站直接通过80端口访问。另外一定要准备一套演示数据两三个社区、四五个活动、十几款生鲜商品、一个测试账号、一个团长账号。老师看演示时不可能注册一个新账号慢慢逛你直接告诉他“管理员账号是什么、团长账号是什么”流程就顺畅了。我还会在数据里预留一个“即将过期”的团和一个“已成团”的团现场演示定时任务效果。6.2 答辩追问Top 5与应答思路我把被问得最多的问题列在下面每个问题背后都对应一个设计决策追问建议应答角度为什么不用微服务项目规模与团队规模决定架构单体模块化可以快速交付引入微服务会增加一致的分布式事务成本库存超卖怎么解决乐观锁SQL条件更新Redis预扣两条防线数据库层面保证负数不可能出现Redis宕机了怎么办保留数据库的乐观锁兜底Redis作为性能层可降级重启后重新预热活动数据拼团人数不足怎么办定时任务扫描超时未成团的团自动置为失败并触发退款支付回调重复通知怎么处理支付流水号唯一约束状态机校验第二三次调用直接拦截回答的时候不要背概念要拿自己代码里的方法名和SQL举例。比如讲乐观锁时直接念一遍那条UPDATE ... WHERE stock #{count}比空谈“乐观锁”三个字有说服力得多。6.3 一些零碎但很实际的建议最后几件小事看着不起眼但影响体验后端全局异常处理一定要做不要让数据库的异常信息直接打到前端页面上前后端联调时统一好返回体格式我全程用{ code, message, data }三件套后期没有因为字段歧义浪费过时间上传代码前把本地数据库连接密码改成弱密码并写清启动文档方便别人一键复现文档里放几张核心流程截图和表关系图老师还没看代码就对你的项目有了整体印象。如果让我重新做一次这个毕设我最想提醒自己的是别急着打开IDE写接口先把业务流程图和订单状态图画明白。很多卡壳都不是写代码卡壳而是业务没想清楚。等到一遍遍debug拼团超员、订单状态不一致的时候你才会体会到那些看似没用的设计文档其实才是最值钱的部分。希望这篇复盘能帮你少走几步弯路。
