1. 为什么我推荐把“鲜花预售系统”当成Spring Boot毕设选题先说个实话每年计算机毕设选题翻来覆去就那么几类图书管理、在线考试、学生选课、宿舍报修……不是说这些题目不行而是做得太多以后答辩老师一眼就能看出你的功能模块到底是自己写的还是照着视频敲的。相比之下鲜花预售系统是一个“看似普通但实际很有挖掘空间”的题目它天然带着一个普通CRUD项目没有的东西——预售这个核心业务规则。你要知道普通商城系统就是“上架商品→用户下单→管理员发货”线性流程属于标准的增删改查。但预售系统里多了一个“先付定金、后付尾款”的环节这个小小的规则改动直接让你的项目从“管理系统”升级为“业务系统”。因为凡是涉及定金、尾款、支付状态、库存锁定、到期发货时机这些东西就必然牵扯到状态流转、定时任务、并发扣减、订单一致性这几个让评委眼前一亮的专业话题。另外从选题策略上讲鲜花本身具有非常强的“时效性”和“节日爆发性”特征——情人节卖玫瑰、母亲节卖康乃馨这种场景天然适合做预售能讲出商业故事。你答辩的时候可以理直气壮地说“鲜花提前预售花店才能按单采购避免囤货损耗。”这比“方便管理员管理图书”有说服力得多。再说回技术层面Spring Boot Vue这套组合目前仍然是Java方向毕设的绝对主流。Spring Boot解决了传统SSH、SSM工程里那些繁琐的XML配置问题约定优于配置内置Tomcat打jar包就能跑。你用零配置就能起一个Web服务这对毕设选手来说意味着——你把精力花在业务逻辑上而不是折腾配置文件。而Vue前端做起来也快Element Plus这类组件库能让你用很短的代码搭出像样的管理后台。所以我给这个题目的定位是难度中等偏上一点点、技术栈主流、业务有亮点、答辩有故事可讲。适合那些Java基础和数据库操作还凑合、想做出一个“有含金量”的毕设、又不希望难度大到做不完的同学。源码我拿到手的时候第一反应是结构很干净package分层清晰没有那种为了凑代码量堆出来的冗余类。后面我会把里面值得复用的核心设计思路全部拆开讲一遍包括怎么跑起来、怎么讲清楚、怎么避开那些你可能查两个小时都查不出原因的坑。2. 花店经营的“预售”到底解决了什么问题业务模型与角色划分2.1 预售和普通电商的本质区别库存与支付时机很多人做毕设的时候有个通病拿着题目就开写连业务规则都没想清楚。但如果你真的做过开发就知道业务规则就是这个项目的灵魂评委问的问题基本都是围绕业务规则展开的。鲜花预售和普通电商的核心区别在于普通电商商品上架 → 用户付款 → 商家发货库存即时扣减预售模式商品预购 → 用户支付定金 → 尾款支付期开启 → 用户支付尾款 → 商家统一采购/生产 → 发货这个差异带来两件很有意思的事。第一库存的扣减时机变了。你在预售阶段看到的“剩余库存”本质上是“可预购名额”用户付完定金后名额就被锁定这个锁定的订单不能因为用户没付尾款就立刻把名额放给别人——需要等尾款期结束后统一释放。第二状态机变复杂了。普通订单就是“待付款/已付款/已发货/已完成”而预售订单至少要多出“待付定金/已付定金/待付尾款/已付尾款/已取消/已关闭”这么几个状态。源码里对这块的处理方式是设置了一个非常清晰的订单状态字段结合支付状态、发货状态三个字段组合起来判断当前订单处于什么阶段。这是很标准的做法你在答辩的时候如果能把这个状态流转图画出来用嘴讲清楚也行就已经赢了一半的普通选手。2.2 系统角色拆解前台用户、后台管理员、超级管理员这个项目分为两个端用户端前台和管理端后台。用户端面向的是普通买花的人核心功能是注册登录、浏览鲜花商品、查看预售活动、发起预购支付定金、在我的订单里查看预售进度、尾款期支付尾款、确认收货、以及个人资料的维护。管理端面向的是花店运营人员核心功能是商品管理维护花材、价格、库存、预售活动管理创建预售场次、设置定金比例、设定尾款支付截止时间、订单管理查看所有订单、按状态筛选、发货操作、用户管理查看注册用户、禁用异常账号、以及数据看板统计预售金额、订单量、热门鲜花。另外系统里还有个隐藏角色叫超级管理员它的权限粒度更粗主要管“管理员账号”本身。这其实是很多毕设里容易被忽略的点——权限模型一定要分级不需要做到Spring Security那么复杂但至少要有“普通用户看不到管理界面、管理员之间也有高低之分”这个层次感否则评委一问权限怎么做你就哑了。2.3 预售活动周期从“上架预热”到“尾款发货”的完整链路我拿源码里的一个具体场景给各位还原一下“一场预售是怎么跑完的”这能帮你建立整体认知管理员在后台创建一场预售活动选定若干鲜花商品设置定金金额、尾款截止时间、发货时间。前台用户看到“预售中”的活动卡片点进去详情页选择规格比如11朵、33朵、99朵支付定金。定金支付成功后系统生成一笔“预购订单”该商品的预购名额减一。时间来到尾款期用户在我的订单页收到提醒进入订单详情支付尾款。用户支付尾款后订单状态变为“待发货”管理员后台看到满屏待发货订单按地区、品种统一采购鲜花然后批量发货。用户收到花点击确认收货订单关闭整个生命周期结束。如果用户一直不付尾款怎么办源码的处理是超过尾款截止时间后订单自动关闭预购名额释放回库存。这个逻辑非常关键是你在答辩时一定要讲的点。实现手段无非两种定时任务扫描 用户主动支付时校验时间。源码里用的是后者搭配一个简单的定时清理任务说实话这个设计已经很成熟了。3. 核心依赖与配置这套源码是怎么把Spring Boot生态串起来的3.1 为什么拒绝SSH老古董Spring Boot这波选型赢在哪我看到源码的pom.xml时心里默默点了个赞。引用的依赖没有一个是多余的而且全部是Java生态里目前最主流、最不容易在答辩时被问倒的那一套依赖作用选型理由Spring Boot Starter Web提供Web容器、Spring MVC、Jackson等零配置启动内嵌Tomcat打jar包直接跑MyBatis-PlusORM层、通用Mapper、分页插件比原生MyBatis少写大量XML内置CRUD方法MySQL Connector数据库驱动经典组合面试也常问Lombok实体类自动生成getter/setter减少样板代码实体类看着干净Hutool工具类库身份证校验、日期处理、随机数生成都有现成的JWT / Spring Security相关登录鉴权与权限控制前后端分离场景最常用的无状态鉴权方案你可能注意到这里没有用Redis。很多教程会让你强行上Redis做缓存但说实话一个毕设项目里如果只是把数据从MySQL搬到Redis再读回来没有实际的高并发场景答辩老师一眼就看穿你这是“为了用而用”。这个源码没堆没用的技术这点很重要——技术上做“够用且合理”的选择比盲目堆砌新技术更讨喜。不过如果你想加分可以自己在尾款支付那块引入Redis做分布式锁防超卖我后面会给出具体思路。3.2 工程结构与目录规划按业务模块分package的正确姿势我见过太多毕设源码包结构乱七八糟全部堆在controller/service/dao/mapper四层里一个类五六百行改个需求想死的心都有。这套源码的包结构比较舒服com.example.flower ├── controller/ // 控制层接收前端请求 │ ├── admin/ // 后台管理接口 │ └── api/ // 用户端接口 ├── service/ // 业务层接口 │ └── impl/ // 业务层实现 ├── mapper/ // MyBatis-Plus的数据访问层 ├── entity/ // 数据库实体 ├── vo/ // 视图对象给前端返回的封装 ├── dto/ // 数据传输对象接收前端参数 ├── config/ // 配置类跨域、拦截器、MybatisPlus配置 ├── common/ // 公共工具、统一返回结果、异常处理 └── utils/ // 工具类JWT、日期处理等vo和dto是经常被人忽略的层。很多人做项目图省事直接把entity丢给前端结果多查出几个敏感字段或者字段格式不对还得临时改实体。源码里单独分了vo/dto说明作者是有工程经验的这点你在答辩时也可以提一嘴——“为了前后端解耦我单独做了视图对象”这句话含金量不低。配置方面application.yml里主要配置了数据源、端口、MyBatis-Plus的日志与分页插件、文件上传路径等。数据库这块值得注意的一个细节是字符集编码一定要设置成utf8mb4不然鲜花商品描述里出现个emoji表情符号存进去就变乱码这种问题排查起来能让你怀疑人生。3.3 登录鉴权JWT无状态方案在前后端分离里的落地细节这个小节单独拉出来讲是因为登录鉴权是很多毕设最容易被问倒的地方。这套源码的鉴权方式是传统Session还是JWT我看了代码采用的是JWT方案。整体流程是用户登录时校验用户名密码成功后后端生成一个token字符串返回给前端前端把它存在localStorage里每次请求在请求头Authorization里带上后端拦截器对所有/api/**接口做token校验合法则放行、不合法则返回401。实现的三个关键点拦截器注册在WebMvcConfigurer里新增一个HandlerInterceptor通过addInterceptors方法注册并配置excludePathPatterns放行登录、注册、商品列表这些无需鉴权的接口。token里只放必要信息源码的JWT载荷里放了userId和role没有放密码等敏感信息。过期时间一般设置为7天过期后前端会收到401跳回登录页。权限控制管理员接口要做拦截校验判断token里的role是否为ADMIN不是就拒绝访问这也是第一道权限防线。如果你在答辩时被问“JWT和Session有什么区别”核心答法是JWT无状态、服务端不用存会话信息、天然支持分布式Session有状态、服务端要维护会话记录但在单个服务器场景下实现简单。知道这两句基本不会被难住。4. 数据库设计是这类项目的命根子核心表结构与关键SQL4.1 八张核心表从用户到订单的完整数据链路数据库设计好坏直接决定你做一个项目的体感。这套源码共设计了多少张表我数了一下核心的八张用户表、管理员表、鲜花分类表、鲜花商品表、预售活动表、订单表、订单明细表、活动与商品关联表。挑重点表来说用户表user用户ID、用户名、密码BCrypt加密存储、昵称、手机号、头像、余额、注册时间、状态。这里注意两点第一密码绝对禁止明文存储用SecureUtil.md5或者BCryptPasswordEncoder第二余额字段是后面做支付逻辑的基础虽然毕设通常用模拟支付但用户余额这个字段一定要有。鲜花商品表flower商品ID、名称、主图、轮播图、分类ID、原价、预售价、库存、销量、上架状态、描述。有一个细节处理得好——detail字段存的是富文本HTML前端用v-html渲染这样后台编辑商品时可以像写Word一样排版比存纯文本体验强很多。预售活动表pre_sale_activity活动ID、活动名称、开始时间、结束时间、尾款开始时间、尾款截止时间、发货时间、状态。这张表是整个系统的核心发动机所有时间节点都在这张表里定义。订单表orders订单号、用户ID、活动ID、商品ID、商品快照名称图片单价防止商品后续修改导致历史订单错乱、定金金额、尾款金额、实付金额、订单状态、支付状态、发货状态、创建时间、支付时间、发货时间、收货地址。订单表里的“商品快照”字段是最容易被初学者忽略的。这里强调一下订单里保存的必须是下单那一刻的商品信息副本而不是通过外键去关联商品表查询。如果用户下单后管理员改了鲜花图片和价格你再去查商品表历史订单显示就全乱了——这个坑我当年自己踩过。4.2 订单状态机设计定金、尾款、取消、关闭一个都不能乱这块是整个系统的业务核心也是答辩时最能展现你逻辑能力的部分。源码用订单状态、支付状态、发货状态三个字段的组合来标识订单当前所处阶段。这里笔者整理了一张订单状态流转表建议你在答辩前背熟场景订单状态支付状态发货状态说明用户提交预购未付定金待付定金未支付未发货用户还可取消用户已支付定金已付定金已付定金未发货库存已锁定尾款期内未付尾款待付尾款已付定金未发货系统提醒用户用户支付尾款待发货已付全款未发货等待商家发货管理员发货已发货已付全款已发货等待用户收货用户确认收货已完成已付全款已发货订单生命周期结束用户取消订单已取消视情况退款未发货定金按规则退还尾款超时未付已关闭已付定金可能不退还未发货库存释放这里有个常见问题尾款超时前如果用户主动取消订单定金退不退还不同业务规则有不同答案。源码的做法是提供“取消订单”接口且取消后定金原路退回用户余额。至于尾款超时被强制关闭的订单定金如何处理一般是规则里定义好“超时关闭后定金不退”模拟支付可以简化成退回余额你要在答辩时明确说出你的规则。4.3 数据库连接与初始化拿到手第一步要改的配置源码运行时第一步肯定是配置数据库。application.yml里核心配置就以下几行spring: datasource: url: jdbc:mysql://localhost:3306/flower_pre_sale?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/Shanghai username: root password: 你自己数据库的密码 driver-class-name: com.mysql.cj.jdbc.Driver这里有几个容易翻车的小地方我挨个说一下serverTimezoneAsia/Shanghai必须加。如果你用MySQL 8.x的驱动不指定时区很可能会报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized这种错看起来像乱码一样其实只是时区问题。characterEncodingutf8mb4一定要配utf8mb4而不是utf8。原因上面说过了emoji字符问题。MySQL 8.x的驱动类是com.mysql.cj.jdbc.DriverMySQL 5.x则是com.mysql.jdbc.Driver如果你本机是5.7版本就要注意改。至于建表SQL源码里一般放在sql/目录或者doc/目录下一个flower_pre_sale.sql文件用Navicat或命令行source执行即可。执行前建议提前创建一个空数据库然后导入SQL避免表已经存在导致报错。5. 从源码到跑通我的启动实操记录与避坑参考5.1 环境准备清单JDK、Maven、Node版本怎么选才稳这个源码是标准的Spring Boot Vue前后端分离项目所以你需要准备两套环境后端环境JDK 1.8 或 11千万、千万、千万不要用JDK 17跑老项目很多依赖的反射机制和模块化限制会让你踩到飞起Maven 3.6只要不是特别老的3.2、3.3就行IDEA 2020.3及以上社区版也能跑就是少一点Spring插件支持MySQL 5.7 或 8.0如果你的机器上同时有多个MySQL版本注意IDE里配置的是哪个端口前端环境Node.js 14 或 16别装Node 20老项目用的node-sass大概率编译不过去装完就想砸电脑npm 或 yarnnpm随Node自带够用这些版本建议不是凭空说的是这类前后端分离项目跑不通的时候八成以上案例都死于版本。记住一句话毕设项目跑不起来90%是环境问题不是代码问题。5.2 启动流程五步跑通全程半小时我实际操作了一遍整理出最顺滑的启动顺序导入数据库打开Navicat或者DataGrip、命令行都行创建数据库flower_pre_sale字符集选utf8mb4然后运行源码目录下的SQL文件。用IDEA打开后端项目File - Open选择源码的backend文件夹也可能是根目录下的后端子目录之后等待Maven自动下载依赖。这里有个技巧如果下载特别慢检查IDEA的Maven配置里的settings.xml是否配置了阿里云镜像仓库配置后速度能快十倍。修改application.yml把数据库账号密码改成你自己的端口默认8080一般不用动。启动后端找到Spring Boot启动类一般带SpringBootApplication注解类名类似FlowerApplication右键运行。看到类似Started FlowerApplication in 3.2 seconds的日志就是成功。启动前端用IDEA自带终端或者VSCode打开前端目录依次执行npm install、npm run dev看到Local: http://localhost:8081/之类输出后浏览器打开对应地址。如果一切顺利你就能看到系统的登录页了。默认管理员账号密码一般源码的README里会写比如admin/admin123之类的组合如果没有去数据库admin_user表里直接插入一条记录或改一条已有记录即可。5.3 我踩过的坑启动报错排查与更优做法把我实操过程中遇到的几个典型报错整理如下前两个是我自己踩过的后两个是帮别人排查时见过的大概率你也会碰到报错一Consider defining a bean of type xxxMapper in your configuration这个经典中的经典。原因是启动类没有被MapperScan扫到或者mapper接口没有加Mapper注解。解决方法是在启动类上加MapperScan(com.xxx.mapper)或者在每个Mapper接口上加Mapper。源码里一般已经配好但如果你自己新建了Mapper类就会触发这个问题。报错二前端npm install报错node-sass相关我看到源码前端依赖里可能有sass或者旧版本node-sass一旦Node版本过高就会出现编译失败。最快的解决方式是卸载重装node-sass改用dart-sass在package.json里把node-sass替换为sass然后删掉node_modules整个文件夹重新install。如果项目不需要自定义样式覆盖甚至可以忽略这个依赖。报错三前端请求后端接口404或跨域报错前后端分离项目必备三件套后端配置跨域CorsConfig、前端代理vue.config.js里的devServer.proxy、请求路径以/api为前缀。源码里后端和前端一般都已经配好了但你如果改了端口就需要同步改前端代理的target地址和后端的实际端口。报错四登录后刷新页面用户信息丢失这是前端路由守卫没有处理好的典型表现。源码里的方案比较稳妥路由守卫里判断localStorage里有没有token有就尝试获取用户信息没有就跳转到登录页。如果你自己改造时发现刷新就跳登录大概率是刷新后用户信息接口返回失败或者token已经过期检查一下token有效期和请求拦截器的处理逻辑。6. 把预售业务逻辑一次性讲透模块边界、超卖与状态同步6.1 用户从“看花”到“付定金”的完整请求链路很多同学答辩被问倒不是因为代码没写完而是讲不清一次请求从前端到数据库到底走了哪些层。这里我用“用户浏览预售活动并支付定金”这个场景手把手过一遍调用链前端Vue组件加载活动列表向/api/pre-sale/list发GET请求参数带当前页和页码大小。后端PreSaleController.listPage()接收参数调用PreSaleService。PreSaleService层通过MyBatis-Plus的selectPage方法分页查询活动表同时联表查出活动关联的商品列表。返回结果是Result.ok(data)的统一封装code200表示成功前端拿到数据后渲染卡片列表。用户点击“立即预购”进入详情页选择商品规格点击“支付定金”。前端把{ activityId, flowerId, userId, depositAmount }这些参数POST到/api/pre-sale/submit。后端PreSaleServiceImpl.submit()做了三件事校验活动时间是否在预售期内、校验定金金额是否为0、然后调用订单Mapper插入一条“待付定金”的订单记录。支付定金时修改订单状态为“已付定金”更新商品库存预购名额减一。数据库事务提交前端跳转至“我的订单”页面展示这笔预购订单。这个链路最核心的一步在第8步库存扣减必须和订单状态更新放在同一个数据库事务里。源码里用Transactional注解搞定这个注解背后的原理是Spring AOP的事务管理你答辩时可以提一下。6.2 防超卖思路单机和并发场景各自的处理方式“库存超卖”是电商类项目必问的经典问题放在鲜花预售场景里更突出因为预售的名额是有限的如果100个人同时抢99朵红玫瑰的最后10个预购名额处理不好就会出现卖了12单但库存只减了10的情况。源码里采用的方案比较基础先查库存判断是否大于0大于0才执行更新SQL同时用数据库的行锁做兜底。具体到SQL层面其实可以做成一个原子操作来保障安全UPDATE flower SET stock stock - 1 WHERE id ? AND stock 0这条SQL通过stock 0条件保证不会扣成负数是单机场景下最简单可靠的防超卖手段。如果你项目中加入了Redis也可以把库存预扣放在Redis里用DECR原子命令来做这个思路可以作为你答辩时的“进阶回答”。6.3 尾款支付与订单关闭定时任务和支付校验双保险尾款期到了用户没付尾款系统要自动关闭订单并释放库存。源码的实现思路是双保险第一重保险定时任务。Spring Boot里用Scheduled注解声明一个方法每隔5分钟扫描一次订单表找出所有“尾款截止时间已过但仍然是待付尾款状态”的订单批量更新为“已关闭”同时把对应的预购名额加回库存。第二重保险用户支付尾款时校验。即使定时任务还没来得及跑用户此刻刚好在支付尾款后端会在支付接口里再次校验当前时间是否在尾款期内如果超时直接返回“尾款期已结束订单已关闭”的提示阻断支付。这种“被动校验 主动清理”的组合设计很适合拿来当答辩亮点。你可以说“为了防止数据不一致我不仅在用户触发时校验还用了定时任务兜底清理保证系统状态最终一致。”定时任务本身很简单Component public class OrderAutoCloseTask { Scheduled(cron 0 */5 * * * *) public void autoCloseExpiredOrders() { // 扫描过期待付尾款订单更新状态、释放库存 } }注意Scheduled默认是单线程执行如果你的项目后续要跑多个定时任务最好在配置类里加一个EnableAsync并用线程池隔离否则一个任务卡住会影响其他任务。当然毕设阶段不用那么讲究知道即可。7. 管理后台实操从创建预售活动到批量发货的完整演示7.1 创建一场预售活动字段、时间节点、关联商品管理员后台的核心操作就是创建预售活动。我在源码的PreSaleActivityController里找到了相关接口前端管理页面的操作流程如下进入“预售管理”菜单点击“新增活动”。填写活动基本信息活动名称如“情人节玫瑰超前预售”、预售开始时间、预售结束时间、尾款开始时间、尾款截止时间、计划发货时间。从商品列表里勾选本场活动要卖的花材可以设置活动价预售价和定金金额。设置活动状态为“上架”点击保存。活动创建成功后用户端首页就能看到这场预售活动了。这里有一个设计细节值得关注活动时间的校验逻辑。比如尾款截止时间必须晚于尾款开始时间发货时间必须晚于尾款截止时间这些都应该在接口层校验前端只管提示。源码里用的是LocalDateTime来做时间比较比用Date类型写起来清爽得多。你要是用着不爽可以自己在Service层加一个时间冲突校验的公共方法顺便还能写几个单元测试。7.2 商品管理图片上传、规格设置、库存初始化鲜花商品和普通商品还有一些小区别——花材有规格朵数、包装、有主图和详情图、库存可能不是按件算而是按“束”算。源码里的商品管理功能覆盖了这些细节点图片上传通过MultipartFile接收前端上传的图片保存到服务器本地指定目录然后返回图片访问URL前端用它来展示。本地路径的配置在application.yml里的file.upload-path字段。创建商品时指定分类选择“玫瑰/百合/康乃馨”等花材分类分类表是一张独立的表支持一级分类和多级分类。初始化库存时普通电商直接填库存数字预售场景下库存字段有两种解读如果是“现货立即发”的商品库存就是实际库存如果是“预售商品”库存实际上代表“本场可预购名额”。上下架状态单独一个字段控制上下架不影响历史订单查询因为订单里存了商品快照。这部分功能属于标准CRUD难度不高但参数校验尽量做全尤其是金额、库存不能为负数这个常识性问题。7.3 订单处理发货、退款、订单导出三个高频操作后台订单管理页面是三段式布局顶部是状态筛选Tab全部/待付定金/已付定金/待发货/已发货/已完成/已取消中间是订单列表右侧是订单详情抽屉。发货操作是后台最频繁的操作。点击“发货”按钮弹出填写物流单号的对话框提交后订单状态从“待发货”变成“已发货”用户端就能看到物流信息了。这块源码用的也是简单的状态更新大概率没有对接真实的物流接口如果你想加分可以自己接入快递100的免费API。退款操作一般针对用户取消的订单。用户在前台取消“待付定金”订单后后台不需要操作直接完成如果订单已经付了定金或尾款取消后需要后台审核退款。源码里简化成了“取消后自动退款”——这也是可以接受的做法毕竟毕设不是上线生产环境。订单导出这块不少毕设没有做但这个功能很讨喜。做法不难后端把所有订单列表用EasyExcel或POI生成Excel文件返回二进制流前端下载。答辩时演示一下“导出月度预售订单报表”观感瞬间就不一样了。8. 答辩前的准备讲出亮点、避开雷区让评委觉得你是真做了8.1 这些技术点一定要会主动讲它们是你的加分项答辩的本质不再是“代码跑通”而是“你讲清楚你做了什么”。我把这套源码里可以提炼的亮点打包好了你答辩时按顺序说状态机设计强调订单状态支付状态发货状态三者组合实现了从“付定金→付尾款→发货→收货”的完整状态流转。这是任何CRUD系统都没有的复杂度。事务控制下单扣库存、支付改状态、取消退库存凡是涉及多个写操作的方法都用Transactional包起来。你可以说“为了保持数据一致性”。统一返回结果与全局异常处理源码里应该有Result类和RestControllerAdvice注解的全局异常处理器。主动提“所有接口返回统一json格式异常全部走全局处理器不会把堆栈信息暴露给前端”。权限控制JWT token 拦截器 角色判断三层配合。注意要说清楚“管理员接口和用户接口是隔离验证的”。预售业务的商业价值讲清楚为什么鲜花要预售——降低库存损耗、按单采购、锁定客户。这个你从业务角度讲评委绝对爱听。8.2 评委大概率会问的五个问题与参考答案提前把高频问题准备好答辩时你就不慌Q1你的库存字段扣减是如何防止超卖的答我在扣减库存时使用了带条件的更新SQLUPDATE flower SET stock stock - 1 WHERE id ? AND stock 0这样即使在高并发下数据库本身也保证了库存不会扣成负数。如果系统量级更大我会考虑引入Redis预扣库存来解决热点数据并发问题。Q2如果用户支付定金后一直不支付尾款怎么办答系统里有两个保障机制第一用户发起尾款支付时后端会校验当前时间是否在尾款期限内超时直接拒绝第二系统配置了一个定时任务每5分钟扫描一次所有超时未支付的预售订单批量关闭并把预购名额释放回库存。Q3密码是怎么存储的答用户密码不是明文存储而是通过加盐哈希算法比如BCrypt或MD5加盐处理后才存入数据库。登录时也是拿输入的密码做同样的哈希运算再比对保证数据库泄露也不会直接暴露密码。Q4这个系统和普通的鲜花商城有什么区别答最大的区别是订单生命周期多了一个“定金尾款”的阶段。普通商城用户付款后就等发货了但预售系统里用户先付定金锁定名额等尾款期开启后再付尾款商家才统一采购和发货。这就带来了两个额外设计预购库存管理和尾款超时释放机制。Q5你对这个系统未来有什么扩展想法答我会从两个方向扩展。第一种是技术方向引入Redis把热门的预售活动库存放到缓存里用分布式锁解决并发超卖引入消息队列做订单峰值削峰。第二种是业务方向增加鲜花礼盒搭配推荐、生日提醒订阅、配送时间选择等功能。这样回答既展示了技术视野也体现了商业思维。8.3 讲解过程中的几个关键话术最后分享几个实战技巧。用这些方式去讲自然得像真做了几个月项目的人提到别人的设计时用“我这里采用的方式是……”而不是“源码里是这样写的……”。不要背代码把核心业务流程画在纸上或者脑子里讲到订单流转时用手势示意方向会更从容。遇到不会的问题用一句“我当时实现的时候主要考虑的是……”把话题拉到你知道的范围内千万别当场沉默或者硬编一个答案。9. 技术复盘做完这个项目你真正掌握的硬技能清单最后这部分我想换个角度聊。一个毕设项目做完你不只是交了一个系统你在这个过程里真正掌握的技能清单才是有价值的东西。这里按经验帮大家盘一盘第一块后端核心开发能力。你用Spring Boot写了完整的RESTful接口理解了Controller-Service-Mapper三层之间的联系学会了MyBatis-Plus怎么通过实体类Mapper接口完成单表CRUD怎么用LambdaQueryWrapper构造查询条件怎么做分页查询。这些技能直接对标工作里的常规开发任务。第二块业务设计与建模能力。你从零设计了一个包含预售活动、订单状态流转、库存锁定与释放的数据库画了E-R图定义了核心表结构。这个能力比单纯的CRUD值钱得多因为你经历了一个完整的“业务规则→数据模型→接口→实现”的过程。第三块常见问题的排查能力。你遇到过数据库时区报错、端口占用、Mapper扫描不到、跨域拦截、前端依赖装不上……这些问题在开发社区里天天有人问你亲手解决一遍下次再遇到就完全不慌了。第四块答辩与表达总结能力。你能把项目功能讲清楚、把业务设计讲清楚、把技术方案讲清楚如果前面这些你都记住了答辩现场你基本不需要临场发挥只需要按准备内容讲。我自己做项目这么多年最大的体会是一个好的毕设项目不一定用了多高深的技术而在于你能否把一件事情从头到尾完整地做透。鲜花预售系统恰恰提供了这样一个“完整”的载体——业务不算简单到无聊技术不算复杂到失控做完了有得讲、有得展示、也有得扩展。如果你正在纠结选题或者已经选了这套源码但还在研究怎么跑通我的建议很简单先照着这篇内容把环境和流程跑通一遍然后把订单状态流转和预售活动创建这两个核心流程亲自操作三遍做到不用看笔记也能说出来每一步发生了什么。做到这个程度你的毕设就稳了。