简介这是一套面向计算机专业本科生的高分毕业设计资源聚焦花店电商场景完整实现从前端展示到后台管理的全流程销售系统可直接用于毕设答辩、课程设计或期末大作业。资源包共1405个文件含164个Java后端业务类、242个Vue组件页面、318个SVG图标资源、154张JPG商品图及126个JS交互脚本辅以SQL建库脚本、Maven构建配置.bat、YML配置文件等整体52.69MB结构清晰、模块解耦明确。已有100人学习下载资源经导师指导与多轮调试确保在IDEAMySQL 5.7Navicat环境下开箱即用。用户可获得完整可运行源码、数据库初始化脚本、前后端分离部署方案及典型业务逻辑实现如购物车状态同步、订单生命周期管理、库存扣减事务控制特别适合掌握Spring Boot与Vue工程化开发流程的学习者快速上手并深入理解电商系统核心设计模式。 毕设选了花店销售系统这个题目在国内毕业设计里属于典型的不会出大错但想拿高分也不轻松的类型。为什么这么说因为它的业务链路完整度恰到好处——有用户端、有商品管理、有购物车、有订单流转、甚至还能做出库存和营销功能技术栈又能顺手覆盖主流Java全栈招聘要求里的SpringBoot、MySQL和Vue。说白了这既不是纯CRUD的学生管理系统那种一眼看到底的项目也不是电商秒杀那种复杂到让答辩老师怀疑你能力的选题。但你如果只是把表和增删改查拼起来交上去也就只能拿个及格分。这篇文章我按自己带过的项目经验把花店销售系统从架构选型、表设计、后端接口、前端页面到论文写作整套链路拆开讲一遍重点放在那些真正影响答辩成绩的细节上。1. 花店系统选型之前先想清楚这几个业务问题1.1 毕业设计不是做产品业务边界要划清楚很多人在做系统设计时最容易犯的毛病是恨不得把美团、盒马的功能全塞进去。尤其是花店这种日常生活场景一听就觉得应该有用户注册登录、鲜花分类浏览、购物车、下单支付、订单管理、后台商品管理、库存管理、促销活动、会员积分、物流跟踪……真按这个清单做下来半年都做不完而且答辩时老师随便问一个深层业务逻辑你就容易露馅。我的建议是把所有功能分三个等级——核心链路、加分链路、扣分陷阱。花店销售系统的核心链路就是用户浏览商品 - 加入购物车 - 生成订单 - 支付订单 - 后台发货 - 订单状态流转。这条链路必须做扎实每个环节的流程、状态、异常处理都要经得起追问。加分链路是商品分类筛选、库存自动扣减、订单统计报表这类能和业务结合技术的点。扣分陷阱则是那种你以为是加分项、实际会让整个项目失控的功能比如复杂的促销规则、优惠券叠加、退款流程——这些在毕设里能不做就别做。1.2 技术栈选型SpringBoot Vue MySQL为什么不踩坑这套组合能成为毕设标配不是没有道理。SpringBoot的特性是约定优于配置你不用像早期SSH框架时代那样写一堆XML配置文件内嵌Tomcat让项目打包后一条命令就能跑起来这对答辩前环境崩溃要现场恢复的场景极为友好。Vue的开发体验对前端基础一般的人也足够友好单文件组件、双向绑定、Vue Router、Vuex/Pinia每一块都有大量文档和现成案例可抄。MySQL是关系型数据库里最普及的就算你是学生本地装在Windows或Mac上也就是一路Next的事。但这里要特别提醒一个容易被忽视的问题框架版本要选对不要追新。尤其SpringBoot3.x的基线是JDK17很多学校实验室机器装的还是JDK8如果强行用新版本光环境兼容问题就能折腾你三天。我自己见过太多人因为SpringBoot版本太高启动时报各种依赖冲突最后答辩前崩溃。选SpringBoot 2.7.x JDK1.8 MySQL 5.7或8.0这是目前最稳的组合网上资料也最全。1.3 分清两个端管理端和用户端不要混着做花店销售系统从使用者角度天然分两端——前端用户要的是逛和买后台管理员要的是管和看。这两个诉求的交互逻辑完全不同混在一个项目里做会让代码和页面都变得不伦不类。我推荐的做法是前后端分离、两套前端工程一是面向顾客的商城端页面风格要清爽主打鲜花展示、购物车、结算流程二是后台管理端表格为主功能要密集主打商品维护、订单处理、数据统计。后端接口也可以按模块拆分/api/user/**、/api/product/**、/api/order/**、/api/admin/**。这样做的另一个好处是论文里可以名正言顺地写前后端分离架构技术含量和答辩分数直接上了一个层次。2. 数据库设计花店系统的核心不是花是订单和库存2.1 从订单模型反推表结构才是正确的设计姿势这可能是整篇文章最重要的一段话设计花店数据库表不能从有哪些页面出发从后往前推而要从订单数据如何产生、如何流转从前往后推。订单是整个销售系统的核心产物其他所有表本质上都是为订单服务的。一张完整的订单表必须包含下面的核心字段——我把它们串成一个清单照着抄基本不会漏order_id订单主键内部自增不对外暴露order_no订单编号对外展示格式建议为日期随机数如202405151230001234用于客服查单时直接定位user_id下单用户ID关联用户表total_amount订单总金额单位分避免浮点数陷阱pay_amount实付金额如果有优惠就是优惠后的金额pay_type支付方式1模拟微信支付2模拟支付宝也可以写余额status订单状态用整数枚举更清晰0待支付1已支付/待发货2已发货3已完成4已取消receiver_name、receiver_phone、receiver_address收货人三件套remark买家留言花店场景太常用了——麻烦包装得文艺一点生日蛋糕一起送create_time、pay_time、send_time、finish_time各个状态节点的更新时间为什么要单独强调order_no因为这是答辩时老师习惯问的点。如果用户下单失败要退款如果客服要查单如果用户打电话来催单靠自增ID根本没法查询必须要一个全局唯一的业务单号。很多低分毕设就败在这种细节上。2.2 购物车和订单明细为什么拆成两张表购物车表cart的结构非常简单主键、用户ID、商品ID、购买数量、加入时间。但要注意一个易错点——同一用户重复加入同一商品时不要在购物车表生成重复记录而是累加数量。这个逻辑在接口层就要控制好不然前端显示会乱。订单明细表order_item则是订单的子表每条记录对应订单中的一个商品项。为什么订单要单独拆明细表而不是直接往订单表里塞商品列表核心原因有两点一个订单包含多个商品时订单表的一行无法存储违反数据库第一范式商品信息名称、价格、图片随时可能被后台修改订单明细必须快照下单那一刻的商品信息否则订单历史数据全乱套。所以order_item表里要有product_name、product_image、price这几个冗余字段——它们在商品表里本来就有但在这里是独立的副本。这是电商系统设计的常识业务数据不要随时关联最新数据关键时刻要落快照。2.3 商品表、分类表和库存表怎样设计才能支撑上架下架商品表product的常规字段有商品ID、分类ID、商品名、主图、轮播图JSON格式、详情介绍富文本、原价、现价、销量、上下架状态、创建时间。分类表category就相对简单分类ID、分类名、父分类ID、排序号。这里推荐用父子分类两级别设计比如鲜花下面有玫瑰/百合/康乃馨绿植下面有多肉/盆栽这样前端分类展示时既有层级感又不至于过度设计。库存表stock要单独设计一个字段叫stock_num库存数量并且要区分两种扣库存方式下单扣减还是支付扣减。毕设里我的建议是支付成功后扣库存——因为花店场景下很多用户可能下单后不支付先锁库存会导致在售商品大量被占着却卖不出去虽然这是真实电商的标准做法但毕设里为了简化流程支付后扣减更好解释。哦对还有一点库存不足时要有预校验并给前端返回明确的库存不足提示而不是让用户在支付环节才报错那体验太糟糕了。2.4 用户表和管理员表别把两种身份混在一张表里很多小白设计时会把用户表和管理员表合成一张user表加个role字段区分。这在小项目里勉强能用但答辩时老师很可能会问普通用户和管理员的操作权限差异在哪里如果都在一张表里登录和鉴权怎么处理 除非你做好了完善的RBAC权限模型否则我更推荐拆成两张表user表面向商城前台的顾客存用户ID、用户名、密码BCrypt加密、手机号、头像、余额实现虚拟支付需要、注册时间等admin表面向后台管理人员存管理员ID、账号、密码、角色、最近登录时间等这两张表独立管理登录鉴权时分别走/api/user/login和/api/admin/login令牌也分开签发逻辑清晰很多。答辩时讲用户体系和管理员体系隔离设计降低权限越权风险这就是第一个亮点。3. 后端接口落地从登录鉴权到订单状态机3.1 项目结构怎么组织让代码看起来就值80分SpringBoot项目目录结构我见过最乱的情况是把所有类一股脑塞在同一个包下两三百行一个的Controller到处都是。一个好的后端结构应该按MVC职责 按业务模块分包两个维度同时组织com.flower.shop ├── config // 配置类跨域、拦截器、MyBatis、Swagger ├── controller // 控制层user、admin、product、cart、order ├── service // 业务层接口 实现 ├── mapper // 持久层MyBatis的Mapper接口 ├── entity // DO实体和数据库表字段一一对应 ├── dto // 入参对象接收前端传参做参数校验 ├── vo // 出参对象返回给前端的数据结构 ├── common // 通用类Result、状态码枚举、常量类 └── exception // 全局异常处理一定要区分entity、dto、vo这三个概念。尤其是dto和entity数据库实体不应该直接暴露给前端接收JSON参数。比如注册接口只接收用户名、密码、手机号而用户表里还有余额、注册时间、状态字段——如果直接用entity接收前端多传一个balance9999就可能被恶意修改。对入参严格用DTO出参严格用VO这既是安全实践也是答辩时的加分谈资。3.2 统一返回体和全局异常处理比你想的重要前后端分离项目里接口不能一会儿返回{code:0,data:{}}一会儿又返回字符串否则前端要疯掉。统一的返回结构应该类似{ code: 200, message: success, data: { } }Result类可以这么设计public class ResultT { private Integer code; private String message; private T data; public static T ResultT success(T data) { ResultT result new Result(); result.code 200; result.message success; result.data data; return result; } public static T ResultT error(Integer code, String message) { ResultT result new Result(); result.code code; result.message message; return result; } }配合RestControllerAdvice做全局异常处理业务代码里就不用到处写try-catch了。凡是参数校验异常、业务异常、未知异常在全局异常处理器里统一封装成上面的返回结构。这样前端不管是成功还是失败都能用同一套逻辑解析排查问题时看code和message一目了然。这也是那些高分毕设看起来像企业项目的关键原因之一。3.3 订单核心接口的完整流程以提交订单为例我以提交订单这个核心接口为例走一遍完整链路第一步接口定义。接收DTO里三个核心字段购物车选中项ID列表cartIds、收货人信息、买家留言。前端把这些传来之后后端才开始干活。第二步事务处理。订单相关操作强烈建议加Transactional(rollbackFor Exception.class)。我见过有人不加事务控制结果出现订单创建成功、订单明细却没插进去的脏数据——答辩运行Demo时当场就表现出来了非常尴尬。关键逻辑根据cartIds查出购物车记录同时联查商品信息校验商品是否上架、库存是否充足计算订单总金额单价 x 数量求和生成order_no格式为yyyyMMddHHmmss 4位随机数插入order表拿到主键后逐条插入order_item清空已下单的购物车记录返回order_no给前端第三步幂等设计。这是答辩加分项。实际场景里用户可能因为网络卡顿重复点击提交订单如果不做任何防护会生成两个一模一样的订单。最简单的方案是前端防重复提交按钮提交后置灰更进一步是后端在生成订单前校验该用户是否已有同金额、同商品、未支付的订单如果有就返回已存在的order_no。这一条你写进论文老师的眼神都会变。3.4 订单状态机如何用代码优雅地管理状态流转订单状态从待支付到已完成中间有清晰的状态机不能乱跳。好的做法是在OrderService里定义每种状态流转的专属方法cancelOrder(orderNo, userId)只允许从待支付变为已取消payOrder(orderNo, userId)只允许从待支付变为已支付sendOrder(orderNo, adminId)只允许从已支付变为已发货finishOrder(orderNo, userId)只允许从已发货变为已完成每个方法开头都先校验当前状态是否符合预期不匹配就直接抛业务异常订单状态异常无法执行该操作。这样哪怕前端页面在某种极端情况下调错了接口后端也不会产生非法状态数据。这块设计在论文里用一个状态流转图纯文字描述也可以展示出来就是订单全生命周期管理的完整阐述。3.5 登录鉴权方案JWT还是Session别纠结选JWT前后端分离架构下Session登录天然有跨域和扩展性问题更推荐用JWT。SpringBoot集成JWT很简单核心就三步用户登录成功后用SecretKey签发一个有效期为2小时的Token包含用户ID和用户名前端拿到Token后存到localStorage在Axios请求拦截器里统一加到Authorization: Bearer token后端写一个拦截器校验Token合法性和有效期把用户ID放到ThreadLocal里供后续业务使用这里直接给一个可用的工具类要点只需要io.jsonwebtoken:jjwt这一个依赖加上generateToken、parseToken、isTokenExpired三个方法就够用了。另外额外提醒不要在前端用Base64解JWT拿用户信息做权限判断因为Base64是明文可逆的真正可靠的权限判断必须发生在后端。3.6 跨域问题最常见的后端接口调不通元凶之一前后端分离项目里前端跑在localhost:8080后端跑在localhost:8081跨域问题必然出现。最省事的方案是在后端配置类里加一个全局CORS配置Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }这里有个坑要告诉你如果同时开启了JWT拦截器预检请求OPTIONS不能被拦截器拦截否则预检失败前端真正请求发不过去。解决办法是拦截器里判断if (OPTIONS.equals(request.getMethod())) { return true; }放行。4. 前端工程化Vue不是写页面是管状态和路由4.1 项目脚手架和目录结构先建对再开写Vue项目推荐直接用npm create vuelatest或vue create flower-shop-adminVite版更轻量。要注意的是路由和状态管理的选型路由用Vue Router 4状态管理用PiniaVue3下Pinia替代了VuexAPI更简洁类型支持更好。前端目录建议按views页面、components组件、router路由、stores状态管理、api接口封装、utils工具来组织。这里特别提示一个新手常犯的错把接口请求散落在每个组件里。正确做法是在api目录下按模块封装比如api/order.js里导出import request from /utils/request export function createOrder(data) { return request({ url: /order/create, method: post, data }) } export function getOrderDetail(orderNo) { return request({ url: /order/detail/${orderNo}, method: get }) }组件里只调用这些方法不直接写URL更不直接用axios实例。这样做的好处是接口变更时只改一个文件代码条理性也更强。4.2 购物车和Token状态应该放Pinia还是localStorage购物车有两种管理模式前端存储和后端存储。因为后端已经建了cart表所以以数据库为准。用户登录后登录成功接口就应该把购物车数量一起返回前端存到Pinia里任意页面都能实时读取并展示角标。未登录状态点击加入购物车时的处理也很关键一种是直接提醒请先登录另一种是本地临时存着、登录后同步——毕设场景建议用第一种逻辑简单且安全。Token状态则有讲究Pinia中存一份、localStorage里也存一份。页面刷新时Pinia内存会被清空如果只存在内存里一刷新就丢了刷新后需要从localStorage回填到Pinia。这一条在论文里可以写基于本地缓存和内存状态同步机制实现登录态持久化既有技术点又让人听得懂。4.3 商品列表页一个会说话的页面足以撑起前端工作量花店的前台首页重点就两个模块分类导航和商品瀑布流/卡片列表。分类导航点击某个分类时前端请求/api/product/list?categoryIdxpageNum1pageSize12回到全部分类时不带categoryId即可。这就是典型的分类筛选 分页加载。分页推荐使用el-pagination组件配置好currentPage和pageSize切换时重新请求数据。每个商品卡片除了图片、名称、价格外还要有一个加入购物车按钮点击后调用addToCart接口成功后message.success(已加入购物车)并且右上角角标1——这套交互虽然简单但很直观地演示了前端状态联动的完整链路非常利于答辩演示。4.4 购物车页全选、单选、金额联动、数量加减一个都不能少购物车页是所有前端页面里业务逻辑最密集的。核心交互如下全选/单选用一个isChecked字段标记每条购物车记录用v-model绑定checkbox金额汇总用computed计算已勾选商品的总价商品价格变化、数量变化、勾选状态变化时总价要实时刷新。这一步强烈推荐演示给老师看非常稳妥数量加减点击或-后调用后端更新数量接口同时前端更新本地数据这里有一个算得上经验教训的点购物车金额计算不要依赖后端返回的总价字段因为后端在查询购物车时只返回商品单价和数量总价应该由前端实时计算。否则用户改了数量但总价不变会被当成Bug。4.5 后台管理端表格、弹窗、表单校验、图片上传四大件后台管理端的页面类型高度统一基本就是列表页 表单弹窗 删除确认 状态切换。以商品管理为例el-table展示商品列表列包括图片、名称、分类、价格、库存、上下架状态、操作按钮编辑按钮弹出一个Dialog内含商品表单名称、分类下拉、价格、库存、图片上传、上下架Switch图片上传建议走el-upload组件配置action为后台上传接口拿到返回的图片URL后回填到表单字段删除操作要加ElMessageBox.confirm二次确认避免误删——这条细节在答辩演示时很加分老师能看到你考虑用户误操作问题4.6 播放m3u8这个需求在花店系统里怎么处理看热搜词里有vue播放m3u8虽然花店系统本身不需要视频但既然提到就顺便说一下思路。如果后续想在花店里加鲜花养护视频插花教程视频Vue里播放m3u8格式的视频通常方案是video.js videojs-contrib-hls插件。但这个不是花店系统必需时间充裕可以加时间紧张的话建议别碰毕设的核心是业务闭环完整不是功能堆得多。5. 这些加分项和扣分陷阱大概率会影响你的成绩5.1 分页查询的实现方式千万别偷懒用全表查询商品列表、订单列表、用户列表都必须做分页不能一把梭把所有数据都查出来。MyBatis分页可以直接用PageHelperSpring Boot集成它只需要两个步骤引入依赖然后在查询前调用PageHelper.startPage(pageNum, pageSize)查询结果用PageInfo包装。前端传pageNum和pageSize后端返回total总条数和list当前页数据。分页逻辑代码量少但它是数据库查询的基本功答辩必问之一。5.2 模糊搜索商品名、订单号怎么搜才能不出错后台的商品管理页几乎都要支持输入商品名模糊搜索。SQL写法是SELECT * FROM product WHERE name LIKE CONCAT(%, #{keyword}, %)注意这里不要自己拼% keyword %因为那样有SQL注入风险。用CONCAT函数或者MyBatis的bind标签都行。更安全的是直接参数化查询like参数的占位符写清楚就能防注入。这个细节可以作为安全编码实践写进论文。5.3 库存并发有没有人抢同一束花会不会超卖花店系统虽然并发量不高但库存超卖是电商系统最经典的面试题和答辩题。后端在下单扣库存时不能先select再update因为两步操作之间存在时间窗口并发情况下两个请求都读到剩余1件库存都通过了检查最后都去更新就超卖了。最简单的稳妥方案是用一条原子更新的SQLUPDATE stock SET stock_num stock_num - #{num} WHERE product_id #{productId} AND stock_num #{num}通过stock_num num这个条件让数据库层面保证不会扣成负数。如果受影响行数为0则说明库存不足直接抛业务异常。这个设计讲给老师听就是基于乐观锁思想的库存扣减方案。你说哪个答辩老师能不喜欢5.4 搜索词里xss攻击和OutOfMemory提醒了什么事XSS尤其后台的商品名、公告这些有富文本输入的字段要防止用户往里面塞script标签。后端要做到输出转义前端用v-html时也要小心。最简单的演示级方案是全局配置一个过滤器对请求参数做HTML标签转义或者在后端解析富文本时去掉script标签。你把这个写进论文的安全设计里比写十个功能点都加分。OutOfMemory如果运行Demo时出现过java.lang.OutOfMemoryError: Insufficient memory多半是分配给JVM的堆内存太小或本地环境内存不足。解决办法是调整IDEA或启动脚本里的JVM参数比如-Xms256m -Xmx1024m。这个不算项目功能但如果答辩现场启动就崩那才是灾难。5.5 密码安全明文密码是低分重灾区用户表和管理员表的密码绝对不能明文存储至少要用BCryptPasswordEncoder做哈希加密。Spring Security自带这个工具即使项目不引入完整Security也可以单独引入spring-security-crypto依赖来用。注册时加密存储登录时用matches方法校验。论文里写用户密码采用BCrypt加密存储防止数据库泄露导致用户信息泄漏安全性这块的分数就稳了。5.6 参数校验别让非法数据进入业务层前端表单校验只是体验兜底后端Controller必须做参数校验。最简单的方式是使用Validated注解配合NotNull、NotBlank、Min这些注解并且给每个注解指定message。比如public class RegisterDTO { NotBlank(message 用户名不能为空) private String username; NotBlank(message 密码不能为空) Size(min 6, max 20, message 密码长度需在6到20位之间) private String password; }这样不用手写一堆if判断全局异常处理器统一捕获MethodArgumentNotValidException后返回错误信息。代码干净答辩也说得清楚。5.7 如果调试时遇到支付成功但订单状态没变优先查什么花店系统涉及交易环节最容易出的Bug就是钱扣了模拟支付但订单没变为已支付。我的排查步骤一般是先看后端有没有报异常日志。如果异常被吞掉了会在控制台什么都不显示那就是没加日志或try-catch吞掉了看订单状态更新的SQL是否生效——检查update语句是否带了正确的where条件是不是更新了别的订单确认事务是否提交。如果Transactional方法内部捕获了异常但没有rollback数据库可能回滚了或根本未提交查前端回调地址是否正确——模拟支付成功后前端跳转的路径是对应订单还是写死的这类问题的排查逻辑强烈建议你在答辩前亲手走一遍会极大地增强临场答问的底气。6. 论文和答辩准备的完整思路别让代码白做6.1 论文目录怎么搭才能让老师一眼觉得规范毕设论文的核心逻辑是需求分析 - 概要设计 - 详细设计 - 系统实现 - 测试。建议这样排第一章 绪论项目背景、选题意义、国内外研究现状这部分可以写电商行业的发展、生鲜/鲜花电商的兴起第二章 相关技术介绍SpringBoot、Vue、MySQL、MyBatis-Plus重点讲清楚为什么选它们、它们的核心特性第三章 系统分析可行性分析、功能性需求分析用文字描述用户角色和功能列表、非功能性需求分析性能、安全、易用性第四章 系统设计总体架构前后端分离架构、功能模块设计、数据库设计E-R图、表结构说明第五章 系统实现按模块分别写核心功能实现配关键代码和运行截图第六章 系统测试测试环境、功能测试用例表、测试结果分析每章的截图要真实操作、统一风格不要一张是中文界面一张是英文界面。6.2 每个功能模块写论文时怎么虚虚实实地展现深度论文最忌讳界面截图 贴整段代码这种流水账。高阶写法是每个模块先写业务需求再写设计思路最后只贴核心代码片段并逐段解释关键逻辑。比如订单模块你要写清楚为什么订单和订单明细要分表数据一致性、冗余快照为什么订单状态要集中管理避免乱跳状态事务如何保证一致性Transactional回滚机制库存扣减如何防超卖单条原子SQL用图表、表结构说明、类图、时序图把这些讲清楚论文的工作量感立刻上来了。切忌把权限管理、购物车、订单、商品管理、后台管理全部平均用力一定要重点突出一两个模块的深度。6.3 答辩时的三个演示场景必须提前排练答辩现场最怕的事是老师来了项目跑不起来。日常开发时你可能改了很多地方重启了很多次但临场一紧张各种环境问题全冒出来了。我建议你提前准备三个演示场景分别对应演示的前、中、后段从首页逛到商品详情加入购物车结算下单模拟支付整个流程必须顺畅——这是核心链路最不能出问题后台从商品管理页新增一个商品并上传图片然后在前台能看到它——这个场景展示了数据实时联动库存不足时的提示效果——展示你对边界情况的处理这个往往能让老师眼前一亮答辩前至少完整跑三遍然后重启后端和前端服务再把这三遍跑一遍。因为很多项目开发完直接跑没问题冷启动后却可能因为配置没写好而崩溃。6.4 老师可能问的十个经典问题提前背好答案答辩老师大概率不会刁难你但也会围绕项目追问一些真问题。我帮你列十个高频问题提前准备答案你用的SpringBoot版本是什么为什么选这个版本——答2.7.x为了让JDK8兼容生态资料丰富MyBatis和MyBatis-Plus区别是什么你的项目用哪个——答用MyBatis-Plus它内置通用Mapper和分页插件提高开发效率但复杂SQL还是自己写你设计的数据库有几张表有哪些关联关系——背熟用户、商品、分类、购物车、订单、订单明细6张核心表及其外键/逻辑关联订单超时未支付如何处理——答可以设计一个定时任务扫描待支付订单超过30分钟自动取消并回滚库存如果没做就解释这是后续优化方向如何防止恶意刷新和重复提交订单——前端防抖 后端幂等校验加密方式用的什么为什么不用MD5——BCrypt因为MD5是定长哈希、可预计算彩虹表破解BCrypt加盐且强度可调部署在什么环境用的是什么服务器——本地开发环境内嵌Tomcat打包成Jar后一键运行项目的安全性是如何保障的——JWT、密码加密、参数校验、SQL注入防范、XSS过滤如果要把支付换成真实微信支付需要改哪些地方——支付接口换成微信支付SDK增加支付回调处理订单状态更新逻辑不变你项目中最大的难点是什么你是怎么解决的——可以说库存并发扣减/订单状态流/Token鉴权任选一个深入讲别只说感觉没有特别难的地方如果你的系统确实做了定时关单、防超卖这些都是加分回答。哪怕有些细节你只是从文章里看到的也建议你真的把代码跑一遍、逐行理解答辩时就能自信地讲出来毕竟这本来就是属于你自己的毕业设计。花店销售系统是我觉得所有XX销售系统选题里最适合做深的一个因为它天然带订单、购物车、库存这电商三件套。如果你时间充裕还可以在论文和系统里加一个简单的数据统计看板比如近7天订单趋势、热销花材排行很简单几条SQL就能搞定但答辩时展示给老师的惊喜感非常强。照着最核心的那条链路先把系统完整跑通有余力再把细节打磨好。别贪功能务实一点这套下来分数不会低。本文还有配套的精品资源点击获取