1. 项目概述与整体设计思路
做毕业设计选“网上花店”这个题目，本质上是一个标准的电商系统，只不过把商品从数码产品、服装换成了鲜花。这个选题在计算机毕业设计里属于典型且稳妥的方向——它覆盖了电商业务的核心链路：商品展示、购物车、下单、订单管理、用户中心，同时数据量级不大，业务逻辑足够清晰，非常适合用来展示Spring Boot + 前端框架的综合开发能力。源码编号09668对应的这套Spring Boot网上花店系统，采用的是前后端分离架构，后端以Spring Boot为骨架，提供RESTful API接口，前端单独部署，通过HTTP请求与后端交互。
先说说这个项目解决的几个核心问题。第一个是花店商品的在线展示与检索，用户不需要到店就能浏览全量商品，按分类筛选、按关键词搜索，这对应的是商品管理模块。第二个是在线下单与支付流程模拟，用户把喜欢的鲜花加入购物车、填写收货信息、提交订单，这对应的是购物车和订单模块。第三个是店铺侧的运营管理，管理员需要维护商品上下架、处理订单状态、管理分类，这对应的是后台管理模块。把这三个痛点解决干净，一个能让毕业答辩老师和课程评审都满意的完整项目就基本成型了。
从技术角度看，这套系统的后端核心是Spring Boot，它解决了传统SSH或SSM框架中繁琐的XML配置问题。Spring Boot通过自动配置和约定优于配置的理念，让开发者几乎不写配置文件就能跑起一个Web应用。整个项目里，Spring Boot承担的角色包括：接收和处理前端请求的Controller层、封装业务规则的Service层、访问数据库的Mapper层，以及贯穿全局的异常处理、拦截器、跨域配置等基础设施。数据持久层用的是MyBatis Plus，这个框架在毕业设计中的优势非常明显——单表CRUD完全不需要写SQL，内置的BaseMapper已经封装好了insert、delete、update、select等方法；遇到多表关联查询时，又可以用@Select注解直接写SQL，灵活度比纯MyBatis更高。
前端部分，这套源码采取的是分离式开发，常见的搭配是Vue + Element UI的Web管理后台，加上用户端的页面。用户在浏览器里访问的是前端站点，由前端框架把页面渲染出来，再调用后端接口获取数据。这里要特别说明一下，如果前端使用的是Vue，那么在开发调试阶段会涉及跨域问题——前端的端口是8080，后端的端口可能是8081或9090，两者不同源，所以后端必须配置CORS跨域支持，或者在前端脚手架里配置代理转发。在实际的毕业设计答辩演示中，最常见的演示方式是在IDEA里同时启动前端和后端，打开浏览器访问本地地址，逐个操作展示功能，所以开发阶段的联调配置是否顺畅，直接影响答辩体验。
作为一个有多年开发经验的人，我给这套项目定位是“麻雀虽小，五脏俱全”。市面上很多毕业设计源码只是把CRUD堆砌起来，没考虑业务闭环。但这套源码的逻辑完整性是可以保证的：用户从注册登录到浏览商品、加购、下单、模拟支付、管理员发货、用户确认收货，整个正向流程是打通的；管理员侧从商品管理、分类管理、订单处理到数据统计，形成了反向的运营闭环。这个闭合的业务流恰恰是指导老师在答辩时最看重的东西——你的项目不是一个“玩具”，而是一个能真实运行的业务系统。
2. 核心技术点拆解与实现方案
2.1 Spring Boot项目的分层架构与启动流程
拿到这套源码，第一步要理解它的包结构。标准的Spring Boot项目采用Controller - Service - Mapper三层架构，这在花店项目中体现得非常明确。以“查询鲜花列表”这个简单需求为例，完整的数据流是这样的：前端发送请求到后端Controller层，Controller接收参数后调用Service层的业务方法，Service层经过业务判断后调用Mapper接口，Mapper通过MyBatis Plus或XML文件执行SQL，最终把结果逐层返回。
这里我想重点说一下Service层的作用，很多初学者容易犯的错误是把业务逻辑写在Controller里，这会导致接口臃肿且难以维护。花店项目中一个比较典型的业务场景是“提交订单”：下单时不仅要向订单表插入一条记录，还要更新对应鲜花商品的库存，同时清空用户的购物车，甚至可能要给首单用户发放优惠券。这三个操作必须保证原子性——要么全部成功，要么全部回滚。实际上这正是Service层发挥作用的地方，通过Spring的@Transactional事务注解，把这个多步操作包裹在一个事务里，任何一步抛出异常都会触发回滚。这背后依赖的是Spring的声明式事务管理机制，它将事务的开启、提交、回滚全部交给容器处理，开发人员只需要加上一个注解。
项目的启动流程也值得一提。Spring Boot应用是一个内嵌Tomcat的独立Java应用，入口是带有@SpringBootApplication注解的类。这个组合注解由三部分组成：@SpringBootConfiguration标明这是配置类，@EnableAutoConfiguration开启自动配置机制——它会读取classpath下的spring.factories文件，根据引入的依赖自动帮你装配各种Bean（比如引入了spring-boot-starter-web就自动配置Tomcat和DispatcherServlet），最后是@ComponentScan组件扫描，自动注册Controller、Service、Mapper等Bean到Spring容器。
在实际的源码阅读中，你可以通过查看项目resources目录下的application.yml文件来确认配置项，比如数据源地址、端口号、Redis连接参数等。需要特别注意的是Spring Boot的版本兼容性问题：如果你本机安装的JDK是8，就尽量选择Spring Boot 2.x版本；如果你用的是JDK 11或17，则可以尝试Spring Boot 3.x。热词里提到的“springboot版本太高”通常就是指Spring Boot 3.x要求JDK 17作为最低版本，如果开发环境是JDK 8就会直接启动报错。还有一个常见问题是IDEA新建项目时发现JDK版本选项是灰色不可选，这通常是因为IDEA自带的Spring Initializr服务路径被网络限制，解决方法是改为从本地Alibaba Cloud镜像创建项目，或者直接用源码里自带的pom.xml配合Maven构建。
2.2 数据库设计：核心表结构与字段规划
网上花店的数据模型是典型电商架构的精简版。我拿到源码后第一件事就是看数据库脚本文件，这套系统的核心表基本覆盖了业务主线。在整个数据库设计中最核心的几张表包括：用户表、商品表、分类表、购物车表、订单表和订单明细表。这些表之间的关联关系可以用几个简明直白的方式来看待：分类表与商品表是一对多关系，每个分类下面可以挂多个鲜花商品（比如“玫瑰系列”下可以有红玫瑰、白玫瑰、香槟玫瑰）；用户表与购物车表是一对多关系，每个用户可以有多条购物车记录；订单表与订单明细表是一对多关系，用户一笔订单里可以用多个商品，所以拆成主表和明细表两张来存。
下面我根据常见的开源花店项目源码整理了一份核心数据表字段说明，你可以用来对照检查自己的源码：
| 表名 | 核心字段 | 作用说明 |
|---|---|---|
| user | id, username, password, nickname, phone, email, avatar, create_time | 存储注册用户与管理员账号信息 |
| flower_category | id, name, parent_id, sort, create_time | 商品分类，支持二级分类结构 |
| flower_product | id, category_id, name, cover_url, price, original_price, stock, sales_count, detail_desc, status | 鲜花商品信息，含价格库存和上下架状态 |
| cart_item | id, user_id, product_id, quantity, checked, create_time | 购物车条目，记录用户加购的鲜花与数量 |
| order_info | id, order_no, user_id, total_amount, pay_amount, freight, receiver_name, receiver_phone, receiver_address, status, create_time, pay_time, send_time | 订单主表，记录订单整体信息和物流状态 |
| order_item | id, order_id, product_id, product_name, product_image, price, quantity, sub_total | 订单明细表，记录快照式的商品信息快照 |
| comment | id, user_id, product_id, content, rating, reply_content, create_time | 商品评价信息，用户在收货后可发表评论 |
在设计这些表的时候有一个重要原则叫“冗余存储”。例如在订单明细表中直接存了product_name和product_image，而不是只存product_id再关联查询。为什么会这样设计？因为订单是历史数据，如果总是去关联商品表，一旦商品改名或删除，用户的订单历史就会因外键缺失而无法显示。快照式的冗余设计能保证用户任何时候回看历史订单，看到的都还是当时购买的商品信息。
2.3 权限认证方案与Spring Boot Security的取舍
后台管理功能只允许管理员访问，用户下单、查看订单需要登录权限，游客只能浏览商品——这是网上花店系统权限控制的基本要求。源码中权限认证的方式，我见过两类比较主流的实现：一种是基于JWT + 拦截器的轻量方案，另一种是集成Spring Security的完整方案。
对于毕业设计项目而言，JWT + 拦截器的方案性价比更高。花店系统不需要Spring Security那么繁琐的过滤器链配置，也不需要OAuth2那样复杂的授权流程。JWT的本质就是一段由服务器签名的JSON字符串，用户在登录成功后获得令牌，之后每次请求都带上这个令牌。服务器通过拦截器校验令牌的有效性，解析出用户ID，从而识别请求者的身份。
具体实现思路是：在Interceptor中创建一个处理逻辑——先判断请求的路径是否需要登录才能访问，如果请求头携带的Token存在且校验通过，就放行；如果校验失败则返回401状态码，前端收到后自动跳转到登录页面。Redis在这里的作用是二级校验——Spring Boot默认生成的JWT是无状态的，但如果你希望实现“用户修改密码后所有端同时下线”的效果，就需要把Token存到Redis里做状态管理，这比纯JWT方案更安全可靠。
我看到题目相关的热词里还有“springboot totp登录口令”，这是基于时间的一次性密码认证，属于双因子认证的范畴。虽然毕业设计未必涉及，但如果想给项目加分，可以在用户登录环节增加一个动态口令验证：用户登录时除了用户名密码，还要输入当前时间窗口内有效的6位数字验证码。这个验证码可以通过Hutool工具类或Google Authenticator算法生成。不过要提醒一下，为纯后端接口实现TOTP在演示时流程比较复杂，容易喧宾夺主，除非你的创新点特意做了双因子认证方向，否则把JWT做好做透就足够支撑答辩。
3. 核心业务功能实操与关键代码解析
3.1 用户端购物流程的实现：从商品列表到订单提交
网上花店的用户端购物流程，我建议你在答辩时按这个链路演示：用户注册账号 → 登录系统 → 在首页按分类浏览鲜花 → 进入商品详情页查看信息和用户评价 → 点击加入购物车 → 在购物车页修改数量或删除商品 → 点击结算填写收货地址 → 提交订单 → 模拟支付 → 在“我的订单”中看到待发货状态的订单。
以“加入购物车”这个最基础也最关键的接口为例，后端Controller接收请求后，会校验当前用户是否已登录（从JWT解析出的userId），然后判断该商品是否已存在于购物车表中。如果已存在，则执行update操作将数量累加；如果不存在，则执行insert操作新建购物车条目。这里应对并发请求的考虑是：如果用户快速点击两次“加入购物车”，可能会同时查出商品不存在，插入两条重复记录。解决方案有两种，一种是给cart_item表加上userId + productId的唯一索引，让数据库层面去重；另一种是使用Redis的分布式锁，但这个对花店项目来说属于过度设计，加唯一索引就够了。
提交订单模块是整个系统最核心的业务代码。我在该类业务中看到过结构相近且典型的实现流程，其步骤可以概括如下：
- 从购物车中选出勾选的商品条目，计算出订单总金额。
- 检查每件商品库存是否充足，以及商品是否仍处于上架状态。库存校验必须先做，防止用户下单时商品已售罄。
- 生成唯一订单号。订单号的生成策略通常用时间戳加随机数，或者采用雪花算法。雪花算法的好处是全局唯一趋势递增，还能从订单号中解析出生成时间，应对并发场景不重复。
- 向order_info表插入主订单记录，向order_item表批量插入订单明细。这一步要注意受事务保护，出现任何异常必须回滚。
- 扣减商品库存（库存量减，销量加），然后清空购物车中对应的条目。
- 返回创建成功的订单对象，前端带着订单号跳转到支付页面。
这个过程里最容易出错的步骤是库存扣减。如果不假思索地使用先查库存再update库存的写法，在并发情况下很容易出现超卖问题。正确做法是使用原子更新的SQL语句来对库存进行有条件的扣减，比如一条update语句内联判断库存大于下单数量才执行更新，然后检查受影响行数。如果受影响行数为0，说明库存不足，则释放已创建的订单行，提示用户购买失败。这套逻辑在毕业设计的并发量场景下已经够用了。
订单状态机的设计同样重要。常见的订单状态码可以参考以下定义：0表示待支付，1表示待发货（已支付），2表示已发货，3表示已收货，4表示已取消，5表示已退款。后端在service层中提供订单状态流转的校验方法，比如只有已支付状态才能被商家发货，只有已发货状态用户才能确认收货。把状态校验写到业务逻辑而不是前端硬控，是为了防止用户通过接口伪造状态变化。
3.2 后台管理模块：商品管理与订单处理的关键接口
后台管理模块是给花店运营人员用的，功能包括商品管理、分类管理、订单管理、用户管理、数据统计等。这部分在源码实现上大量依赖MyBatis Plus的条件构造器QueryWrapper，它允许你以链式编码的方式添加查询条件，不用手写SQL就能完成大部分列表查询和筛选操作。
商品管理中最常用的两个操作是条件分页查询和上下架切换。条件查询是指通过商品名称做模糊搜索、按分类筛选、按价格区间过滤、按销量排序，这些在MyBatis Plus中通过QueryWrapper的组合使用就能实现，比如用like()方法处理模糊匹配，用eq()处理精确条件过滤，用orderByDesc()处理排序，然后把Page对象传给分页方法，框架自动生成limit语句完成分页。需要注意MyBatis Plus的分页需要配置PaginationInnerInterceptor插件，否则分页方法不生效，版本兼容性也常在这里出问题，这一点在源码配套说明文档里应该会写明。
商品上架或下架操作本质上是修改status字段的值，但这里有一个实操中的细节问题：如果商品正在被用户浏览，管理员把商品立即下架，用户再点击“加入购物车”时会被后端拦截，提示商品已下架。所以库存充足商品下架要在订单提交环节判断status，而不是仅仅在前端隐藏入口。处理方案是在订单查询商品时，将status=1（上架状态）作为条件之一，若查不到商品则直接抛业务异常。
订单处理模块的常见操作包括：查看订单详情、订单发货、修改收货人信息、处理退款申请。发货是商家端的高频操作，在管理后台的操作是填写快递单号并点击发货。后端接口接收到快递单号和订单号后，更新订单状态为已发货，并记录发货时间。如果系统集成了短信服务，可以在发货时发送短信给用户手机号，但考虑到短信服务需要申请签名、模板和充值，毕业设计项目通常会去掉这个功能，用一个状态变更通知代替。
3.3 安全防护要点：上传文件与全局XSS过滤
安全是毕业设计中容易被忽视但实际很重要的模块。网上花店系统中，管理员上传鲜花图片和用户在评论区发带有HTML或JavaScript脚本的内容，都可能引入安全风险。热词中出现过“springboot项目全局过滤器处理上传pdf文件时xss攻击”这样的话题，这说明在校生在课程设计时确实会遇到这类问题。
XSS（跨站脚本攻击）的核心手段是攻击者在输入框提交可执行的JS代码，服务端如果不过滤就存入数据库，其他用户浏览页面时这段脚本就会在浏览器中执行，造成Cookie窃取、页面篡改等危害。Spring Boot项目应对XSS的常规方案是编写一个全局过滤器，在请求进入Controller之前统一清洗请求参数中的危险字符。在我们的花店项目中，对评论内容、收货地址、商品详情等文本字段做XSS过滤非常有必要。
实现方案上，可以通过注册一个Filter来完成。核心思路是自定义一个Wrapper类对HttpServletRequest进行包装，重写getParameter、getParameterValues、getInputStream等读取方法，在对每一个参数值时调用工具方法去清洗HTML标签和危险字符。使用过滤器的好处是，项目里所有接口的输入都会自动经过清洗，不用在Service层一处一处地手动过滤。需要特别注意的是不要对富文本编辑器的内容也做彻底清洗，否则会把正常的排版标签如
、 等也清掉，你需要在过滤器中配置白名单，只过滤script标签、onclick、onerror等危险属性和javascript:协议地址。
另外一个毕业设计容易忽视的地方是文件上传校验。花店项目中有商品图片上传功能，Controller接收MultipartFile后如果只校验文件大小、不限制文件类型，攻击者就可能上传JSP木马，通过路径拼接访问到可执行文件，进而控制服务器。比较稳妥的做法是双端校验：前端限制选择文件的扩展名为jpg、png、webp，后端同时校验Content-Type和文件扩展名的一致性，并且把文件存储到项目之外的独立目录（不是WEB-INF或classpath内），避免被当作静态资源直接访问执行。
3.4 数据统计报表：给系统增加数据分析能力
很多毕业设计会忽略数据统计功能，但其实这是一个低成本、高回报的面加分点。网上花店在完成基本业务闭环后，可以增加一个数据面板页：统计今日订单量、今日销售额、总用户数、总商品数这些核心指标。后端实现思路是使用Mapper中自定义的统计SQL，配合Group By进行销售额或销量的分组汇总。
比较有技术含量的是销售趋势图数据的生成。以“近七天销售趋势”为例，前端EasyUI或ECharts展示折线图，后端接口返回日期和销售额两个数组。如果直接查询order_info表并按日期分组，会出现某天没有订单时对应的销售额是缺省的尴尬情况。成熟方案是在Java代码里循环补全近7天的日期，把查询结果放入Map中，没有数据的日期销售额补0，前端就能画出连续的折线图。这段代码逻辑不复杂，但在答辩时可以重点讲一下“日期补全”这个小细节，老师会觉得你考虑问题很全面。
数据统计相关接口的另一个好处是可以使用@Scheduled定时任务来自动生成日报表。项目run起来后，每天凌晨2点自动统计昨天的销售额、订单数和热销商品排行，存储到一张统计表中。用了Spring Boot的@Scheduled注解就能实现定时调度，仅需在启动类上加上@EnableScheduling开关。这算是工作学习中比较常用的场景，加强项目的功能完整度的同时也展示了你在Spring Boot上的深入度。
4. 部署上线与常见问题排查技巧
4.1 环境搭建与IDEA启动全流程指南
拿到源码后，很多同学卡在第一步：项目跑不起来。这里我给出一个经过验证的启动流程，按这个顺序操作基本不会遇到大坑。
首先确保本机环境三件套齐全：JDK 1.8或11、Maven 3.6及以上、MySQL 5.7或8.0。这三者的版本匹配关系是：JDK 8对Spring Boot 2.x友好，JDK 11可以运行Spring Boot 2.x，如果源码用的Spring Boot 3.x则必须用JDK 17以上。你可以看pom.xml里的parent节点来确定版本，再去检查自己电脑环境，避免启动时报新版JDK与旧版Boot不兼容的问题。
接着用IDEA打开源码根目录，选择以Maven项目方式导入。IDEA会读取pom.xml并自动下载依赖，网络不佳时这个过程容易非常漫长甚至卡住。建议在Maven的settings.xml中配置阿里云镜像仓库，依赖下载速度会快很多。如果出现某个jar包下载失败导致项目报红，优先在IDEA右侧Maven面板中点击clean和package重新构建，若还不行则删除本地仓库里对应的缓存目录后重试。
数据库导入是容易被忽略的一步。在MySQL中先创建数据库，编码统一选择utf8mb4，然后在Navicat或命令行中执行源码根目录下sql文件里的脚本。从数据表中含有中文的情况来看，如果不指定utf8mb4会出现中文乱码，非常折腾。导入成功后修改application.yml中的数据源配置：url格式为jdbc:mysql://localhost:3306/数据库名?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai，账号密码改成你自己的。
之后启动Application方法类，看到“Started XXXApplication in X.XXX seconds”的日志说明Spring Boot启动成功。此时可以打开postman测试后端接口，或者直接启动前端项目。前端如果是Vue项目，在命令行执行npm install后使用npm run dev启动。使用正确的启动顺序和恰当的配置调整，从打开源码到完整跑起来，大概率能控制在一个小时内。
4.2 常见的启动报错与业务逻辑问题排查
我在指导大量类似项目时总结了一份“毕业设计实战中最容易遇见的启动报错”清单，这里分类整理成表格，你可以直接对照排查：
| 报错信息 | 出现原因 | 解决办法 |
|---|---|---|
| Failed to configure a DataSource: 'url' attribute is not specified | application.yml中未配置数据库连接或配置项写入错误 | 配置spring.datasource.url、username、password三个核心属性 |
| Access denied for user 'root'@'localhost' | MySQL账号密码错误或连接被拒绝 | 核对密码，检查MySQL服务是否启动，允许root远程连接 |
| java.sql.SQLSyntaxErrorException: Table doesn't exist | 数据库未导入SQL脚本或表名不一致 | 重新执行SQL文件，核对实体类注解里的表名是否与库表完全一致 |
| Invalid bound statement (not found) | Mapper接口的方法与XML中的id不匹配 | 检查Mapper XML文件的namespace、id与接口中的方法名一致 |
| The server time zone value is unrecognized | MySQL连接串时区参数缺失 | 在jdbc url后追加serverTimezone=Asia/Shanghai |
| Port 8080 was already in use | 端口被其他进程占用 | 改application.yml中的server.port，或使用命令行查看占用进程 |
| java.lang.NoClassDefFoundError: javax/xml/bind/... | JDK 11以上版本缺少JAXB模块 | 在pom.xml中引入javax.xml.bind相关依赖，或换用JDK 8 |
| jwt signature does not match | JWT密钥不一致导致Token解析失败 | 确认Token生成和校验使用的secret是同一个 |
| 中文乱码 | 数据库编码或前端请求编码不一致 | 统一数据库为utf8mb4，在Spring Boot配置中设置server.servlet.encoding.force=true |
除了工程报错，业务逻辑问题也值得关注。有一种典型情况是“订单已经生成了但库存没有变化”，这类问题几乎都是没有在Service层实现类上标注@Transactional，或者Spring只对RuntimeException回滚，而你抛的是受检异常Exception。排查时先用本地测试环境复现，在关键步骤前后打印日志，根据日志定位到是更新库存失败还是事务没生效。定位到具体某一个步骤后再调整，不要盲目重启项目反复试。
热词里还出现过“docker部署springboot项目”，如果你的毕业设计要求演示部署，用Docker会显得更加专业。将项目通过Maven打成jar包后，编写一个Dockerfile文件，基础镜像使用openjdk:8-jre-alpine，将jar包复制进容器，暴露端口，再用docker build和docker run启动。数据库如果也容器化部署，需要使用docker-compose编排两个容器，并配置内网网络使Spring Boot容器能够通过服务名访问数据库容器。
4.3 项目中MyBatis Plus分页与条件查询的实战用法
MyBatis Plus可以说是Spring Boot毕业设计里最实用的利器。项目中所有单表操作都可以用它来简化。以花店商品的搜索功能为例：在Controller层接收keyword和categoryId两个参数，把它们传给Service层。Service中构造一个LambdaQueryWrapper，通过链式条件构造器组合查询条件，然后调用selectPage方法完成分页。
public Page<FlowerProduct> pageProducts(int page, int size, String keyword, Long categoryId, Integer status) { Page<FlowerProduct> pageParam = new Page<>(page, size); LambdaQueryWrapper<FlowerProduct> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), FlowerProduct::getName, keyword) .eq(categoryId != null, FlowerProduct::getCategoryId, categoryId) .eq(status != null, FlowerProduct::getStatus, status) .orderByDesc(FlowerProduct::getSalesCount); return flowerProductMapper.selectPage(pageParam, wrapper); }这段代码中，每个条件的第一个参数是布尔值——只有当前一个判断成立时，后续条件才会真正拼接到SQL中。这样做的好处是，你可以同一个方法同时服务于“全部分类展示”和“按关键词搜索”两种场景，前端传什么参数就筛选什么，参数为空就不加条件，避免写出大量if-else拼接查询语句的样板代码。
需要提醒的是，一定要在配置类中注册MybatisPlusInterceptor并添加PaginationInnerInterceptor分页插件，否则selectPage传入的Page对象会返回全部数据，分页不生效。这个插件实在过于基础，报错的频率在我的经验中很高，很多人在网上查了很久找不到原因，其实就是忘了注册拦截器。
5. 经验总结与项目扩展建议
这套Spring Boot网上花店源码从架构完整度和代码规范度上来说，在整个“Java课程设计源码”类别里算是一个质量不错的参考项目。它清晰展现了Spring Boot项目从分层架构到数据库设计再到业务实现的全链路能力，业务闭环完整，也很容易在此基础上做创新点扩展。
如果想把项目拔高到一个新的层次，我的建议是围绕以下几个方向做扩展：第一个方向是接入Redis缓存热点数据。把首页推荐的鲜花列表、商品详情这类读多写少的数据缓存到Redis中，配合“缓存穿透”“缓存雪崩”的应对措施，能在答辩时展示你对高并发场景的思考。实际做法是在Service中先查Redis，未命中则查数据库并回写缓存，并设置合理的过期时间。第二个方向是集成消息队列处理订单超时未支付场景。当用户下单后15分钟未付款，系统要自动关闭订单并释放库存。用定时任务轮询是实现的方法之一，进阶做法是用RabbitMQ或RocketMQ的延迟消息来做，延迟队列把“订单超时检查”这件事解耦出来，从架构合理性上看比定时任务要好。第三个方向是引入WebSocket主动推送通知。管理员发货后，系统通过WebSocket实时推送“您的鲜花已发出”消息到用户浏览器。前端用原生的WebSocket对象监听，后端用Spring的TextWebSocketHandler处理消息，整体实现难度适中，演示效果却很惊艳。
在用户信息和相关功能方面，还可以增加积分体系和优惠券玩法——用户每次购物获得积分，积分可以抵扣现金；新注册用户发放优惠券，下单时如果订单金额满足门槛即可使用。积分和优惠券在数据库中用两张表维护，与订单主流程的耦合度不高，适合作为独立的创新功能快速开发。
不管选择哪个方向，一个原则值得记住：毕业设计项目的深度和说服力，取决于你能否讲清楚“为什么选择这个方案”。只要你能对每个模块的设计理由、每个技术选型的对比过程娓娓道来，即便项目功能本身不算多，答辩老师也会认可你的工程素养和解决问题的能力。
