企业官网建设流程全解析

1. 项目核心拆解：这个“鲜花销售管理系统”到底要做什么

选课题是计算机毕业设计的第一步，也是最容易翻车的一步。很多人一上来就奔着“高难度”去，结果做了三个月连需求都理不清，最终只能降低标准、东拼西凑糊弄过去。“基于Spring Boot的鲜花销售管理系统”这个题目，听起来平平无奇，但它在毕设选题里算是相当聪明的选择：业务场景完整、功能边界清晰、技术栈有代表性、扩展空间大，而且最关键的——它不会让你陷进“为了技术而技术”的泥潭。

先把这个系统当成一家真实的花店来看。花店要活下来，必须把进销存管明白：货架上有哪些花、每种花库存多少、价格怎么定、顾客下单后怎么处理、订单状态怎么跟踪、日常营业额怎么统计。放在系统里，就是商品管理、库存管理、购物车、订单流程、用户注册登录、后台数据统计这几条主业务线。你在PPT或论文答辩时只要把这条逻辑讲清楚，评委马上就能理解你的系统是干什么的，而不是听完之后一脸懵。

从功能边界来看，这个系统天然被分成两个角色：普通用户（C端）和管理员（B端）。普通用户的操作路径非常典型：注册登录、浏览鲜花列表、按分类筛选或搜索、查看商品详情、加入购物车、提交订单、查看订单状态。管理员的职责则是：维护商品分类、上架下架商品、调整库存、处理订单（发货、取消、退款）、管理用户状态，必要时再配一个数据看板展示销售统计。

所以这套毕设表面上是在写代码，实际上是在做一个缩小版电商系统。它麻雀虽小，五脏俱全，把登录鉴权、RBAC权限模型、Restful接口设计、关系型数据库建模这些核心知识点全部覆盖了。对于求职面试也有帮助——你完全可以把项目里“购物车合并”“订单状态机”“库存扣减”这些细节拿出来和面试官聊，比简历上写一堆“熟悉Spring Boot”有说服力得多。

顺便说一下“适合谁”。如果你是Java方向的大四学生，或者正在准备跨项目经历的开发者，想用一套业务完整、能写进简历、又能在三天内跑起来的管理系统来撑场面，这类题目是性价比最高的。反观那些“基于Spring Boot的XX管理系统”蹭热门词却无业务逻辑的题目，比如“基于Spring Boot的大学生兼职平台”“基于Spring Boot的体育馆预约系统”，往往会死在需求不清上——你连“兼职平台”谁发布任务、谁接单、佣金怎么结算都想不清楚，后面每一步都是加倍的痛苦。

2. 技术选型与架构设计：为什么非Spring Boot不可

技术栈这块，毕设默认不要整花活，越主流越好。系统名里写了“基于Spring Boot + Java”，这就是在告诉你：用Java的主流生态，别搞Python、Node.js、Go这些。原因很简单，毕业设计的评审系统里，Java和Spring Boot的组合覆盖率最高，查重、答辩、运行环境都成熟，出了问题网上随手一搜就有答案，不像冷门技术栈报个错都找不到人问。

2.1 技术栈组合与各组件职责

后端我建议用一套极简组合：Spring Boot 2.7.x + MyBatis Plus + MySQL 8.0 + Lombok，身份认证用Sa-Token或JWT二选一。Spring Boot负责把整个Web应用的骨架撑起来，内嵌Tomcat让你不用额外部署容器；MyBatis Plus在MyBatis的基础上给了你单表CRUD的BaseMapper，写增删改查不用自己拼SQL，这对大量重复的数据操作来说是实打实的效率提升。

前端可以是纯HTML + Bootstrap + jQuery开发的后台页面，也可以用Vue + Element UI做单页应用。我的建议是：如果目标是稳妥毕业，优先选服务端渲染页面，也就是用Thymeleaf模板引擎，页面直接放在Spring Boot的src/main/resources/templates目录下，控制器返回视图名就能渲染。别小看这个选择，它直接决定了你项目的复杂度天花板——前后端分离意味着你要维护两套工程、处理跨域、写接口文档，对毕设来说工作量至少多出40%。如果你已经熟练掌握了Vue，那就另说，用它做出来的界面确实更现代，答辩时视觉分更高。

数据库选MySQL不做第二想，MySQL 8.0的窗口函数、JSON类型都是加分项，但你用到的基础还是那几张表的增删改查关联查询。需要注意的一点是，MySQL 8.0的驱动类名变成了com.mysql.cj.jdbc.Driver，时区要显式配置serverTimezone=Asia/Shanghai，很多第一次跑Spring Boot项目的人就死在这个细节上。

2.2 架构分层与目录结构

毕设代码最忌讳的就是把所有逻辑都塞在Controller里，表面看着代码量很多，实际上一坨浆糊，答辩时被问“你项目怎么分层的”就会现出原形。

典型的分层结构是四层：Controller接收请求、Service写业务逻辑、Mapper处理数据库交互、Entity对应数据库表结构。以及一个放通用结果的包，比如统一的返回体Result<T>、全局异常处理器GlobalExceptionHandler。

com.example.flowershop ├── controller ├── service │ ├── impl ├── mapper ├── entity ├── config ├── common │ ├── result │ ├── exception └── FlowershopApplication.java

这里每个包都有明确的职责，写代码时不会迷路，论文的“系统设计”章节也有内容可写。Controller层只做三件事：接收参数、调用Service、包装返回值。Service层处理业务规则，比如下单时要校验库存，减库存和创建订单一定要放在同一个事务里，这些都是Service层的活。在答辩时，你可以主动告诉评委：“我的分层结构是参照阿里巴巴开发规范设计的，Controller层只做参数接收与结果包装，业务逻辑全部沉淀在Service层，这样每个方法都可以做单元测试。”这句话一出来，基本上技术环节的评分就稳了。

2.3 Spring Boot版本与其他框架的兼容性坑

版本选择是个无声吃人的坑。很多人直接下载了Spring Boot 3.x，结果发现javax.servlet变成了jakarta.servlet，MyBatis Plus的旧版分页插件直接失效，一大堆教程代码全部报错，项目被卡在建工程的第一个星期。这不是危言耸听，Spring Boot 3.0是一个分水岭，它把JavaEE规范从javax迁移到jakarta命名空间，很多第三方框架没有跟上。

我在这个项目里推荐的组合是：

• JDK 1.8或JDK 11（这两种对企业级项目最友好，且网上资料占比最高）
• Spring Boot 2.7.18（2.x最后一个版本，修复了大量漏洞且稳定性极佳）
• MyBatis Plus 3.5.3
• MySQL 8.0
• Maven 3.8+

这组版本在大量毕设项目中验证过，兼容性最好。不要在毕设阶段当版本控，你淋过的雨都有前人替你踩完了。

提示：如果你在pom.xml中引入了spring-boot-starter-parent的版本号，那么依赖的传递性版本全部由父POM统管，不要手动给Spring Boot的starter钦定版本号，否则会触发依赖版本冲突。只需要为MyBatis Plus等非Spring Boot管理的依赖单独指定版本即可。

2.4 为什么不用前后端分离架构

我见过太多人咬着牙上了前后端分离+Vue，最后死在跨域、Token刷新、打包部署上。对于毕设来说，简单可靠是第一原则。采用Thymeleaf服务端渲染，Controller和页面天然同域，不存在跨域问题，部署的时候直接mvn package打完一个jar包就完事。你只需要记住：能用一套工程解决的问题，绝不拆成两套。

当然，如果题目写了“基于Spring Boot + Vue”，或者你们学校明确要求前后端分离，那就得用分离结构。后端返回JSON，前端用Vue3 + Vite + Element Plus渲染页面。这种情况下你前期要额外做好三件事：统一响应体Result<T>的设计（code、msg、data三段式）、跨域配置（CorsFilter或@CrossOrigin注解）、接口文档的维护。这些都做到了，分离架构才会真的香。

3. 数据库设计与核心表结构：这几张表设计对了，系统就成功一半

数据库设计是毕设的重头戏，也是论文里占篇幅最多的一部分。E-R图、数据字典、表结构说明都是从这里出的。我下面直接讲核心表的设计思路，你照着这个骨架去填充自己的业务字段就行。

3.1 六张核心业务表

用户表（user）：简单的字段就够用，id、username、password、avatar、phone、role、create_time。密码一定要加密存储，用MD5加盐或BCrypt。如果你在论文中写“用户密码明文存储”，答辩时必被问“安全性怎么考虑”，这就很尴尬了。正确做法是引入spring-boot-starter-security或者只用hutool的DigestUtil做MD5加盐，代码量不大，但回答“密码安全”这个问题时瞬间就有底气了。

分类表（category）：这个表结构非常简单，id、name、sort、create_time。注意加一个sort排序字段，因为页面上要按顺序展示分类，“全部鲜花”之类的前端写死即可。

商品表（product）：这是信息量最大的一张表。核心字段有：id、category_id、name、cover_image、images（多个图片用JSON或逗号分隔）、price、original_price、stock、unit（单位，如“枝”“束”“盆”）、sales_count、status（0下架/1上架）、description、create_time。这里有两个细节值得写进论文：cover_image只存单张封面图，images用JSON数组存轮播图；sales_count记录销量，用于“热销排行”排序；status字段控制上下架，不用的商品直接下架而不是删除，保留历史数据。

购物车表（cart）：id、user_id、product_id、quantity、checked（是否选中）、create_time。需要注意唯一约束，同一用户同一商品不能插入两行，如果用户重复点击“加入购物车”，应该执行数量加一而不是插入新记录。这是数据库层面约束和代码层面逻辑的结合点。

订单表（orders）：order_id（订单编号，业务上不能用自增id暴露订单量）、user_id、total_amount、pay_amount、status、address_id或receiver_name/receiver_phone/receiver_address、remark、create_time、pay_time、ship_time、finish_time。订单状态是重点：0待付款、1待发货、2已发货、3已完成、4已取消、5退款中。有时间戳字段记录状态变化的关键节点，这在数据分析中很有价值。

订单明细表（order_item）：id、order_id、product_id、product_name、product_image、price、quantity、total_price。为什么在这里冗余product_name和product_image？因为商品名称和图片随时可能被修改，订单属于交易快照，必须记录下单那一刻的信息。这个冗余设计在答辩时会成为你的加分点，你要说出“快照避免历史订单被商品改动污染”这个理由。

评论表（comment）：id、user_id、product_id、content、rating、create_time。若系统规模小可以不做，但如果想要界面丰满一点，一定要有评论功能。

3.2 订单状态机设计

订单状态不是简单的几个数字，而是一个状态机。我在设计这个项目时用了一组常量去定义状态，然后在Service层严格约束状态流转路径：

1（待付款）→ 2（待发货）→ 3（已发货）→ 4（已完成） ↓ ↓ 5（已取消） 6（退款）

这里有一个隐藏很深的技术点：状态流转要在代码里做校验。比如一个订单当前状态是“已发货”，用户就不能直接调取消接口把状态改到5，否则整个业务逻辑就乱了。我在OrderService里写了一个changeOrderStatus(orderId, expectedStatus, targetStatus)方法，用乐观锁的思想去校验当前状态，确保状态只能按图中箭头方向转移。这个设计可以完整地写进论文的“订单模块设计”小节，既体现出你对业务的理解，也展示了你对并发数据一致性的基本认知。

3.3 外键与索引策略

很多人在自制表结构时喜欢乱加外键，但真正到了企业级开发中，外键通常是避免使用的。原因很简单：外键约束会带来额外的锁开销，影响高并发写入性能，而且分布式场景下外键根本没法用。毕设数据库设计的最佳实践是：逻辑外键，即在order_item表中有一个product_id字段指向product表，但不在数据库层面创建FOREIGN KEY约束，由应用代码来保证引用完整性。

索引方面，基本规则是：主键一定是聚集索引；user_id、order_id、category_id、product_id这些高频查询字段要建普通索引；登录名username要建唯一索引防止重复。使用联合索引时要注意最左前缀原则，比如查询条件是“某个分类下价格区间内的商品”，那么应该建(category_id, price)的联合索引，而不是单独建两个索引。

4. 核心功能模块实现要点：从登录到下单的完整链路

这一部分我就直接上实际编码过程中的核心思路了，每个功能模块我都会点出该踩的坑和该注意的设计点。

4.1 注册登录：Session还是JWT？

若采用前后端不分离的Thymeleaf方案，用Session保存登录态是最简单自然的。登录成功后session.setAttribute("userId", userId)，在需要登录的接口上通过拦截器检查Session中是否有用户信息，没有就重定向到登录页。

前后端分离方案则用JWT。用户登录成功后，后端生成一个Token返回前端，前端存在localStorage中，并在每次请求的Headers里携带Authorization: Bearer <token>，后端写一个JwtInterceptor解析Token。JWT的好处是无状态，缺点是你没法服务端主动踢人下线，且一定要设置过期时间（常见的是2小时），不然Token泄露后等同裸奔。

我在这个项目中用的是JWT + Sa-Token。Sa-Token是一个轻量级的Java权限认证框架，比起Spring Security，其配置要简单太多，包含登录认证、权限认证、Session会话、踢人下线等功能，API设计非常直观，几个核心方法就能搞通一套认证鉴权体系。最关键的是毕设项目里它的中文文档极其详尽，遇到问题查起来不费劲。若你想在论文里装点门面，可以写“使用Sa-Token实现了基于Token的无状态认证机制，支持分布式部署场景下的会话共享”，这比“用Session存了一下”要高级得多。

4.2 角色权限：管理员和用户的接口隔离

用户和管理员的操作权限天然不同。简单方案是在后端接口上做区分：/admin/**路径下的接口全部走管理员拦截器，校验当前登录用户角色是否为管理员；其余路径普通用户可访问。注意这里一定要处理未登录用户访问购物车、下单接口的情况，不要返回500错误，而应该返回统一的JSON提示“请先登录”。

MyBatis Plus的多租户和逻辑删除功能也可以顺手用上。逻辑删除就是在实体类上给deleted字段加@TableLogic注解，删除操作变成更新操作，数据不会真消失，这在毕设里是安全性上的一个加分点，写论文时也能体现你对数据完整性的思考。

4.3 购物车与下单流程：事务与并发

购物车逻辑不复杂，难点集中在“提交订单”这个操作上。一个正确下单流程应该是：

1. 根据购物车选中的商品，计算出总金额
2. 冻结商品库存（预扣库存）
3. 插入订单表和订单明细表
4. 清空购物车中已下单的商品
5. 提交事务

这里最关键的一点是：第2步和第3步必须放在同一个事务里。如果在减了库存之后、插入订单之前系统报错，但事务没有回滚，就会出现“库存扣了但订单没生成”的脏数据。解决办法就是加@Transactional注解。但@Transactional有个大坑——它默认只对RuntimeException进行回滚，如果你在方法中捕获了异常但没有抛出来，事务是不会回滚的。正确做法是try { ... } catch (Exception e) { TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); }或者直接不捕获异常让它向上抛。

另一个隐藏问题是库存超卖。高并发场景下，多个用户同时购买同一商品，两条update语句同时执行可能把库存减成负数。毕设项目虽然不会有真正的高并发压测，但你只要在简历或面试中谈到这个场景，就该知道解决方案。最简单的方式是在SQL上做限制：UPDATE product SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}，影响行数为0就说明库存不足，需要提示用户。这条SQL被很多企业项目用来做库存扣减，简单有效。

4.4 后台管理：数据看板和文件上传

后台管理模块通常用Bootstrap后台模板搭界面，但推荐使用一个简单的可视化图表库ECharts。引入ECharts之后，后端提供一个统计接口（按周统计订单量、按分类统计销售额），前端用Ajax拉数据渲染成折线图或饼图，这样一个“数据报表”功能瞬间撑起后台管理页面的专业度。整个统计接口不用写复杂的SQL，用MyBatis Plus的QueryWrapper配合GROUP BY就能搞定，注意SQL里DATE_FORMAT的使用。

文件上传功能基本逃不掉，鲜花商品的图片总得有地方传。简单可靠方案是上传到本地服务器指定目录，然后配置静态资源映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceMapping("/upload/**") .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/"); } }

这里记录一个极易踩的坑：IDEA中项目重新编译时，target目录会被清理，有人把图片直接放在src/main/resources/static/upload里，会时常丢失。正确姿势是将上传路径彻底独立于项目目录之外，比如在项目根目录建一个upload/文件夹，并且这个路径最好在配置文件中可配置。

5. 毕设论文撰写与项目文档组织：代码只是工作量的一半

代码写完了不算完，毕业设计的最终呈现是论文、答辩PPT和系统演示。论文写得好不好，直接影响导师对你工作量的判断。我见过太多代码写得很扎实、论文却逻辑混乱的学生，最后只拿到中等成绩，非常可惜。

5.1 论文大纲与每个章节核心内容

标准论文结构通常包含以下章节，每一章我都标注了要写的内容重点：

• 第一章 绪论：研究背景与意义、国内外研究现状、论文组织结构。写背景不能空谈“随着互联网发展”，而是要结合具体的鲜花零售行业场景，比如鲜花作为非标品的损耗率高、实体花店辐射范围有限、即时配送需求强烈。
• 第二章 相关技术介绍：对Spring Boot、MyBatis Plus、MySQL、Thymeleaf或Vue的介绍。不要照抄框架官网简介，要写清楚你用它干了什么、为什么选它不选其他。
• 第三章 需求分析：可行性分析、功能需求（用例图+用例描述）、非功能需求（性能、安全、易用性）。
• 第四章 系统设计：系统架构图、功能模块图、E-R图、数据库表结构设计。这一章是论文篇幅最大的部分，务必把表结构的设计理由讲清楚。
• 第五章 系统实现：按模块展示核心代码截图 + 运行效果截图 + 关键逻辑说明。注意代码不要贴一大堆没用的重复代码，要选择每个模块里面最有技术含量的那一段，通常是事务处理、权限校验、库存扣减这几类逻辑。
• 第六章 系统测试：测试用例表格 + 测试结果截图。多写几条边界值和异常用例，比写“登录成功”这种没营养的用例强得多。

画用例图、E-R图时不要用Word自带的绘图工具，丑到会让导师怀疑你的审美。推荐用processon.com在线画图，或者PlantUML快捷键画出来再截图贴进Word，专业度立马上来。架构图和时序图，用draw.io或者Visio都可以。

5.2 开题报告与任务书怎么写

开题报告的核心是研究内容和预期成果。研究内容部分不要只写一句“开发鲜花销售系统”，而是要拆成几块，比如“基于RBAC模型的用户权限管理”“基于状态机的订单全生命周期管理”“基于ECharts的销售数据可视化分析”。预期成果部分写清楚交付物：可运行的Web系统一套、项目源码、数据库脚本、以及一篇不少于XX字的毕业论文。好的开题报告，是在任务明确的前提下，让导师知道你的工作量是清晰可量化的。

5.3 答辩PPT的逻辑线

答辩PPT我建议控制在15页以内，核心逻辑线是：问题（花店管理痛点）→ 方案（系统能做什么）→ 技术（怎么实现的）→ 演示（跑一遍关键流程）。时间线大概是5分钟讲解 + 3分钟演示 + 2分钟回答问题。

PPT页面不要贴大段代码，要去贴关键截图。比如订单模块，贴一张“订单状态状态机图”，比贴20行代码更能展示你的理解。每一页讲解完毕，都要“挖一个坑”让评委老师顺着你的思路来问，比如你讲完库存扣减的WHERE条件，导师大概率会追问“高并发情况下会不会有问题”，你接着就把乐观锁那套讲出来。这种节奏在答辩中被称作“主动输出”，比被导师牵着鼻子问要舒服得多。

6. 常见问题与Debug实录：运行的每一步都可能踩坑

开发过程中有几个高频bug几乎是每个做Spring Boot毕设的人都会遇到的。我盘点了一些最常见的场景、原因和解决方案，做成一张速查表供你避坑。

6.1 环境与项目启动类问题

第一个坑：IDEA中Spring Boot项目启动失败，端口被占用。Error信息会提示Port 8080 was already in use。根本原因一般是后台有残留的Java进程或者另一个项目占用了端口。解决办法是netstat -ano | findstr 8080查PID，taskkill /F /PID <pid>杀掉进程。也可以在application.yml中改server.port换一个端口。

第二个坑：数据库连接失败 The server time zone value 'Öйú±ê׼ʱ¼ä'。乱码样的时区错误让很多人以为是编码问题，其实只是MySQL连接URL缺少时区参数。在jdbc连接串后加上?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8即可。

第三个坑：MyBatis Plus查询报错 Invalid bound statement (not found)。原因通常是Mapper接口和XML映射文件没有绑定成功。检查一下：@MapperScan是否扫描到了Mapper所在的包路径；XML文件中的namespace是否和Mapper接口的全限定名完全一致；配置文件里mapper-locations路径是否指向classpath*:mapper/*.xml。

第四个坑：Maven依赖下载速度极慢。换上阿里云镜像仓库，这是每个Java人必备的常识。在Maven安装目录/conf/settings.xml中加入：

<mirror> <id>aliyunmaven</id> <mirrorOf>central</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/central</url> </mirror>

6.2 业务功能实现类问题

登录功能逻辑看似没问题但始终进不去系统。排查步骤：先确认前端表单的name属性与后端实体字段对齐。典型的错误场景是用Bootstrap模板时，用户名输入框的name="username"，却写成了name="userName"，后端@RequestBody解析时找不到对应字段，到位就是null。这种问题，用浏览器F12查看Network里的请求Payload，一眼就能看穿。

下单时库存减少但订单表里没有数据。这个就是事务问题。按我前面说的，检查@Transactional注解是否加在了public方法上，以及异常是否被吞掉。可以临时在Catch里加日志输出，确认事务是否回滚。

Thymeleaf直接返回JSON字符串而不是页面。要是你发现浏览器显示的是大括号里一串JSON，说明Controller上多了@ResponseBody注解或类上有@RestController。Thymeleaf是视图解析器，两者不能混用。要么去掉@ResponseBody，要么改方法返回值为正常页面视图。

图片上传后访问404。这多半是静态资源映射没有生效，检查WebMvcConfigurer配置是否正确，路径拼写、上传文件所在目录是否存在，以及前端img标签的路由是否与addResourceHandler中的模式匹配。如果用了Nginx或Tomcat的外置部署方式，还需检查路径是否映射到了外部文件夹。

6.3 环境迁移部署的常见翻车点

如果你的系统换了一台电脑就跑不起来了，大概率是三个原因。一是JDK版本对不上，本地用11编译、服务器只有8，会报UnsupportedClassVersionError；二是数据库迁移时只导了业务数据，没把函数的定义一起导出；三是application.yml里写了本机绝对路径，换机器后找不到文件。规范做法是：将所有配置文件中的路径改成相对路径，数据库连接信息和文件路径统一提取到配置文件中，部署时通过外部配置覆盖。

7. 项目扩展与定制方向：从“能毕业”到“有亮点”

如果你的定位只是“能毕业”，那做到上面这些就已经完全够用了。但如果你想拿高分，或者想把项目作为求职简历的项目经历来写，我建议你再额外做以下扩展，这些扩展技术成本不大，但呈现出的效果完全不一样。

7.1 功能性扩展方向

鲜花推荐功能：这不需要多高深的算法。最简单的实现方式是“基于购买记录的协同过滤”，统计用户历史购买的分类分布，在首页推荐其最常购买分类下的热销商品。SQL用GROUP BY category_id ORDER BY COUNT(*) DESC就能提取用户偏好分类，然后再查该分类销量前N的商品作为推荐结果。论文里你可以把这个模块称为“基于用户行为的个性化推荐系统”，是不是档次一下就上去了？

批量导入导出：用EasyExcel组件给商品模块增加Excel批量导入，给订单模块增加导出功能。这对管理员来说是非常实用的功能，在答辩现场演示“一键导入500条商品数据”绝对比手动一条一条添加更有说服力。

数据备份与恢复：做一个小工具页面，核心逻辑是调用MySQL的mysqldump命令进行定时备份，备份文件存到服务器目录中，再在管理页面保留最近N份备份列表。这个功能对花店老板来说可能平时感受不到，但它属于企业级应用必备的安全能力，放在论文中“系统应用与部署”这一块很加分。

7.2 技术性扩展方向

接口缓存：对商品分类、热销榜单这种读多写少且不经常变化的数据，引入Spring Cache + Redis缓存，缓存命中率提升、数据库压力下降，这是一个非常标准的企业级解决方案，写进论文里就能体现出你在高性能设计上有意识。

限流与熔断：在提交订单接口上加一个简单限流，使用Guava RateLimiter或Redis计数器实现滑动窗口限流。答辩时你就能说“防止恶意刷单”，这比单纯说“我做过XX系统”显得更贴近实际生产环境。

部署Docker化：把Spring Boot应用打成Docker镜像，再写一个docker-compose.yml把MySQL、Redis、应用一次拉起。这套技能栈是当前企业的主流部署方式，写到简历里非常硬核。虽然毕设演示不一定需要Docker，但你在项目文档中附上部署的Dockerfile和启动脚本，体现的是工程化思维。

每个扩展方向都值得花心思完善。我个人的体会是，毕设项目的价值不在于炫技，而在于每个功能点都能讲清楚“为什么这样做”。当你把底层逻辑想透了，无论是答辩还是面试，问到你任何一个细节，你都能从容接住，这个项目才会成为你职业道路上一个真正加分的作品。