基于Spring Boot的水果购物管理系统：设计实现与答辩指南

1. 项目定位与设计思路拆解

2026年这个时间节点，Spring Boot早就不再是毕设里的“少数派选项”，而是绝大多数Java方向的默认选择。如果你正在找一套能做出来、讲得清楚、答得上去的项目，基于Spring Boot的水果购物管理系统（编号14197）是一个非常稳的切入点：它业务模型完整，前有商品展示、中有购物车与订单、后有用户与库存管理，几乎把一个在线购物系统该有的模块都覆盖到了，又不会像电商平台一样复杂到失控。

这个项目的核心定位很清晰：面向水果零售场景的Web购物管理系统，解决线下水果店在进货、库存、订单和会员维护上的手工管理难题。水果本身有鲜明的行业特点——保鲜周期短、价格随季节波动明显、品类多且分类高频调整、损耗率偏高。如果你把水果换成图书或者数码配件，系统也能跑，但那些品类的业务逻辑不足以体现“库存敏感”和“订单时效”这两个设计要点。选择水果这个场景，意味着你在设计数据库和业务规则时，必须把“库存变化频繁”“上下架灵活”“订单状态可追踪”这些诉求用功能语言表达出来，这恰好是评委想看到的能力。

从毕业设计选题角度分析，这套项目有几个非常务实的好处：

• 业务链路完整但不臃肿，覆盖用户端、管理端两个视角，功能拆分空间足够大。
• 技术栈主流，以Spring Boot为核心，整合MySQL、MyBatis-Plus、Spring Security、JWT等常用组件，每一项都能单独展开讲。
• 演示效果好，水果彩图数据天然比空白的管理系统界面更有视觉说服力。
• 扩展性强，你想加个报表统计、加个推荐算法、加个在线支付模拟，都不会伤筋动骨。

1.1 核心需求拆解

做毕设最忌讳的事情，是拿到项目就急着写代码。先花一个晚上把需求拆透彻，后面会省下大把返工时间。水果购物管理系统的需求可以拆成两个视角来看：

从普通用户（买家）的视角，核心诉求是四个字：逛、挑、买、查。逛对应水果分类浏览和首页推荐；挑对应关键词搜索和价格/销量/上新排序；买对应加入购物车、提交订单、填写收货信息；查对应查看个人订单列表、订单详情和物流状态。围绕这四个动作，还需要支撑性的功能设计，比如商品收藏、取消订单、订单评价等。

从管理员（卖家）的视角，核心诉求恰好是对称的：管商品、管库存、管订单、管用户。管理员要能对水果商品做增删改查，尤其要能快速调整上下架状态和库存数量；要能看到所有用户订单并按状态筛选，比如待发货、已发货、已完成、已取消；要能封禁违规用户；最好还能看到简单的销售统计，比如今日销售额、热门商品Top10。

把这两个视角的需求叠在一起，就得出系统的总体功能清单：

• 用户端：注册登录、指纹/短信验证可放后期，保持JWT登录即可；商品分类浏览、关键词搜索、分页排序；商品详情与库存展示；购物车管理（增删改查、勾选结算）；订单提交与状态流转；个人中心（地址管理、订单管理、收藏管理）。
• 管理端：后台登录（与管理端权限控制，普通用户无权限），水果分类管理、商品信息管理、库存与上下架管理、用户管理与禁用、订单处理（发货/取消/完成）、基础数据统计看板。
• 公共能力：统一异常处理、接口参数校验、图片上传与静态资源访问、页面分页组件、数据初始化脚本。

1.2 为什么选Spring Boot而不是老框架

我见过不少人在纠结用Spring MVC还是Spring Boot做毕设，有的学校教材还在教SSH（Spring + Struts2 + Hibernate），如果你不想自己给自己挖坑，选Spring Boot就好。理由很简单：

第一，减少配置心智负担。Spring Boot的自动配置机制把大量Bean装配、数据源配置、Web Starter初始化都接管了，你只需要在application.yml里写关键参数。这意味着你的精力可以放在业务代码上，而不是花三周时间去解决XML配置里的各种诡异报错。

第二，内置了部署运行能力。内置的Tomcat容器让项目打包成JAR后可以直接java -jar运行，答辩现场换一台电脑也能快速起服务，完全不需要在评委面前折腾Web服务器的安装配置。

第三，生态整合成熟。MyBatis-Plus、Redis、Spring Security、Swagger这些毕设常用组件都有对应的Starters，引入依赖、写配置、开跑，整个流程平滑得多。

第四，追问深度可控。Spring Boot的底层原理（自动配置、条件注解、启动流程、内嵌容器）本身就是答辩时可以展开讲的高频考点，你选了这个框架，等于给自己准备好了几个现成的深度话题。

1.3 项目的技术难度等级判断

说句实在话，水果购物管理系统的难度定位在“中低偏中”这一段。它比纯CRUD的图书管理项目要复杂，因为涉及订单事务、库存并发、角色权限，但相比完整的电商系统，它又省掉了支付网关对接、消息队列、分布式事务、秒杀等重环节。

这个难度区间对绝大多数毕设场景都是合适的：代码量足够撑起论文的第三章和第四章，功能完整度支撑得起演示环节，同时又能保证一个基础扎实的同学在三到四周内做完并顺利跑通。如果你在答辩时导师问“你觉得这个系统的难点是什么”，你可以答库存并发扣减和订单状态一致性，这属于“有深度的知识点”，但你又确实用乐观锁或事务机制解决了，这就形成了闭环。

2. 核心技术栈与数据库设计

这个项目的技术选型表，建议你在论文和答辩PPT里都列出来，评委一眼扫过去就知道你做的是正经项目还是水出来的Demo。

2.1 数据库表设计与关系说明

数据库设计是评委提问的重灾区，同时也是你展示基本功的最好机会。水果购物管理系统最少需要落八张表，我按业务依赖顺序给你列出来：

• 用户表（user）：用户ID、用户名、密码（加密存储）、昵称、手机号、头像URL、角色标识（admin/user）、状态（正常/禁用）、创建时间。角色字段也可以用单独权限表，但毕设场景下直接在用户表加一个role字段要简单许多。
• 水果分类表（fruit_category）：分类ID、分类名称、上级分类ID（支持二级分类）、排序字段、状态。例如“热带水果”下挂“芒果”“香蕉”，“浆果类”下挂“蓝莓”“草莓”，实际业务里还可以加产地、标签等冗余字段。
• 水果商品表（fruit_product）：商品ID、分类ID、商品名称、商品主图、轮播图集合、商品描述、规格/单位（如500g/份）、原价、售价、库存数量、销量、上下架状态、创建时间、更新时间。售价和原价两个字段分开保存，便于做促销展示。
• 购物车表（cart_item）：购物车ID、用户ID、商品ID、购买数量、勾选状态、加入时间。可以用Redis替代，但用MySQL表更稳妥，也更容易在答辩时讲清楚。
• 订单表（orders）：订单ID、订单编号（唯一业务单号）、用户ID、订单总金额、优惠金额、实付金额、收货人姓名、收货手机号、收货地址、订单状态（待付款/待发货/已发货/已完成/已取消）、创建时间、支付时间、发货时间、完成时间。订单表是核心中的核心，状态字段建议用整数或字符串枚举，别用布尔值。
• 订单详情表（order_item）：明细ID、订单ID、商品ID、商品名称快照、商品图片快照、单价（下单时价格）、购买数量、小计金额。注意价格一定要做快照，否则商品改价后历史订单会显示错误金额。
• 收货地址表（address）：地址ID、用户ID、收货人、手机号、省市区、详细地址、是否默认地址。
• 收藏表（favorite）：收藏ID、用户ID、商品ID、收藏时间，联合唯一约束（user_id + product_id）。

核心业务关系的逻辑是：一个用户可以有多个地址、多个购物车记录、多个订单；一个订单对应多条订单明细；一个分类下面挂多个商品；一个用户和多个商品之间通过收藏表建立多对多关系。

2.2 表结构设计避坑经验

数据库设计这些坑，我当年做类似项目时几乎全踩了一遍，现在提前帮你排掉：

第一，金额字段一律不用float/double。浮点数在计算金额时会出现0.1+0.2不等于0.3的问题，做订单合计时差额会让你挠头。直接用DECIMAL(10,2)，精确到分。

第二，用户表密码字段长度别省。不管你是用MD5还是BCrypt，加密后的字符串至少是32位或60位，数据库字段varchar(255)是最保底的方案。很多同学把密码长度设计成varchar(20)，一加密就报Data too long，超级尴尬。

第三，订单号和主键ID是两码事。主键ID是数据库自动生成的数字，订单编号是给用户看的业务单号，推荐用时间戳+随机数或雪花ID生成，不要用自增ID直接当订单号，避免被别人推断出你的单量。

第四，订单表要预留冗余字段。收货人、手机号、收货地址、商品名称、商品快照，这些字段在订单表或订单明细表里各存一份，别去联表查。等用户在三个月后说“我要查去年买的那个芒果当时多少钱”，你能立刻调出快照数据，这就是专业和业余的区别。

第五，所有时间字段统一用datetime且带默认值。MySQL的timestamp有2038年的上限，datetime比它安全，生产环境规范也倾向datetime。create_time统一在插入时由代码填充或数据库默认值兜底，避免空值。

2.3 数据初始化脚本的重要性

一套能直接跑起来的数据脚本，价值比你想象中大得多。除了必须的管理员账号（用户名admin/admin123这种答辩账号），建议把水果分类和商品的数据做得像样一点：五大类、每类六到十个商品、每个商品都有图片URL（可以用本地静态资源路径也行）、合理的价格区间、精确的库存数字，比如“阳光玫瑰青提 500g 29.9元 库存128”，而不是“水果1 10元 库存10”。数据像样了，演示页面的说服力马上不一样。

初始化脚本可以在启动时通过Spring Boot的sql.init机制自动执行，也可以用Navicat手动导入SQL文件。建议第二种，答辩时你可以说“这是我在业务分析阶段梳理的模拟数据，用于测试核心流程”，比说“脚本自动生成的”更显真实。

3. 核心功能模块与实现方案

这一部分我按“登录认证 → 商品展示 → 购物车与订单 → 库存扣减”这条主线来拆，因为这条主线的每一步都决定了系统能不能闭环演示。任何一步断了，答辩演示就会出现“点了下单没反应”的致命事故。

3.1 用户认证与权限控制模块

登录方案我建议用JWT + 拦截器，这套组合在毕设场景里兼顾了实现简单和原理可讲。实现链路分四步：

第一步，用户提交用户名密码，密码用BCryptPasswordEncoder做加密比对，比对通过后生成一个包含用户ID、用户名、角色标识的JWT Token，设置有效期（比如24小时），返回给前端。 第二步，前端把Token存在localStorage，每次请求在Header里带上Authorization: Bearer token。 第三步，后端写一个拦截器，拦截需要登录的接口路径，每次请求时从Header解析Token并校验合法性，把用户信息放入当前请求上下文。 第四步，使用Spring Security或简单拦截器做角色判断，管理端接口（如/admin/**）校验role是否为admin，不是则返回403。

这里有一个实现取舍：Spring Security功能强大，但配置门槛对新手不太友好；自己写拦截器更可控，但答辩时容易被问“安全吗”。我的建议是：如果时间充裕，用Spring Security + JWT，这是目前最主流的企业方案，答“为什么选Spring Security”时有话讲；如果时间紧张，写一个自定义HandlerInterceptor也行，关键在于你能把Token校验、角色判断的代码逻辑讲清楚，这同样是加分项。

3.2 商品浏览与搜索模块

这个模块是用户端体验的核心，最重要的是把“分类筛选 + 关键词搜索 + 排序 + 分页”组装成一个不卡的接口流程。流程大概是：

• 用户进入商城首页，默认加载全部分类下的上架商品，按创建时间倒序。
• 点击左侧某个分类，请求带上categoryId，后台查询该分类下的商品。
• 在搜索框输入“芒果”，请求带上keyword，后台对商品名称做模糊查询。
• 选择“按销量排序”，后台在查询语句里ORDER BY sales DESC。
• 上述条件可以组合，比如“搜索芒果 + 价格区间10到30 + 按销量排序”。

实现时用MyBatis-Plus的LambdaQueryWrapper可以快速拼出查询条件，但组合条件一多，建议直接用注解SQL或XML里的动态SQL，可读性更好。商品列表的返回结果建议封装成一个统一对象：当前页数据列表、总记录数、总页数、当前页码、每页条数。前端拿到这个对象直接渲染分页条，体验很顺。

分页查询有一个容易被忽视的性能点：不要用MyBatis-Plus的PageHelper在关联查询时做count，如果有联表需求，建议先查出主表分页ID，再用IN查询子表数据。不过对毕设的数据量来说，性能问题不明显，答辩被问到的话答出“我了解这个优化方向”就足够。

3.3 购物车与订单模块

购物车的标准操作是：加购、修改数量、勾选、删勾选、结算。核心字段就是用户ID、商品ID、数量、勾选状态。需要注意的细节是：同一用户重复加购同一商品，不要新增记录，应该把数量+1；库存不足时直接提示加购失败；结算时只统计勾选状态的购物车条目。

订单模块最重要的一环是状态机设计。我的建议是订单状态在数据库用int或varchar表示，在代码里维护一个常量类或枚举类，定义如下状态流转：

• 待付款（0）：用户提交订单后生成，库存预扣或者先不扣，取决于你的策略，简单方案是提交订单即扣库存。
• 待发货（1）：用户完成支付（毕设一般用模拟支付，直接点“确认支付”即可）后进入该状态。
• 已发货（2）：管理员在后台发货，填写物流单号（模拟）。
• 已完成（3）：用户确认收货，订单关闭。
• 已取消（4）：用户主动取消或超时未支付，库存回补。

每次状态变更都要在service层做校验，比如“已发货的订单不允许用户取消”，“已取消的订单不能再次支付”。这个校验逻辑看似简单，但能有效防止答辩时演示“异常流程”翻车。

订单创建的事务逻辑值得单独强调：创建订单主记录 + 批量插入订单明细 + 扣减商品库存 + 清空对应购物车条目，这四步必须放在同一个事务里。任何一个环节失败，整体回滚，避免出现“订单生成了但库存没扣”“购物车清了但订单没失败”这类数据不一致问题。

3.4 水果库存扣减的并发安全方案

库存问题是答辩时最容易展开讲的技术点。水果店促销时，用户同时下单“红颜草莓500g”，如果没做并发控制，就会出现两个人都买到最后一件，但库存只扣了两次中的一次，最终超卖。解决方案按复杂度从低到高有三种：

最基础的办法是“数据库乐观锁”，在商品表的库存字段上通过版本号或条件更新来实现。核心SQL类似：UPDATE fruit_product SET stock = stock - #{count} WHERE id = #{id} AND stock >= #{count}。受影响行数为0时说明库存不足，代码里抛出“库存不足”异常，业务回滚。这种方案实现简单，性能损耗小，对毕设场景足够用。

更严格的方案是“悲观锁”，在查询库存时使用SELECT ... FOR UPDATE锁定行记录，事务提交后释放锁，这是数据库层面最可靠的方式，但并发量高时性能会下降，而且需要配合事务才能发挥作用，适合对一致性要求高的核心场景。

再往上就是Redis分布式锁或乐观锁 + Lua脚本扣减，这些方案在企业项目中常见，但是毕设里属于“加分项”，如果你的论文想写高并发优化章节，可以把这个作为扩展方向提一嘴，不必真的实现。

我的建议是：主体代码用乐观锁条件更新，论文里把这个方案的选型理由讲透，再在“不足与展望”一节提到Redis分布式锁是未来优化方向，这就是一个完整的问答闭环。反复问“你看过哪些锁方案”，你能从乐观锁讲到分布式锁，分数自然不一样。

4. 从零到一：一套能答辩的项目本地复现指南

很多同学拿到项目压缩包第一步就是盲跑，报错就慌了。复现一套Spring Boot项目，本质就是解决好“环境依赖”和“配置项匹配”两件事。你把下面的步骤按顺序走一遍，二十分钟到半小时内能起服务。

4.1 环境准备与版本匹配

兼容比跟风更新更重要的一句话：不一定要最前沿的版本，但一定要能匹配的组合。这套项目推荐用以下组合，踩坑最少：

• JDK版本：1.8或11，JDK 17也能跑Spring Boot 2.7，但部分老依赖会有兼容问题，建议稳妥用1.8。
• Maven：3.6.3及以上，低于3.5的版本拉取依赖容易出错。
• IDE：IntelliJ IDEA（社区版就够），注意首次导入项目时让IDEA自动识别为Maven项目。
• 数据库：MySQL 5.7或8.0，记得确认端口是默认的3306，密码自己记住。
• 连接工具：Navicat或DataGrip，用来导入SQL脚本和查看表数据。

新建数据库时三个细节：数据库字符集选utf8mb4，排序规则选utf8mb4_general_ci，这样能正常存储水果名称里的生僻字和表情符号；导入SQL脚本前先建库，不然脚本里的USE db_name会报错；导入完成后随便打开一张商品表看看数据是不是中文不乱码。

4.2 配置文件与启动步骤

打开src/main/resources/application.yml，需要重点核对三块配置：数据源、Redis（如果有）、文件上传路径。下面是我修改过多次后觉得最容易出错的配置区：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/fruit_shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

启动项目的标准姿势是在IDEA右侧Maven面板先点clean，再点package或直接运行主启动类。如果你发现启动过程中报错，排错优先级是：数据库连不上（最常遇到）→ 端口被占 → Redis没启动（如果依赖了）→ 依赖没拉全。启动成功的标志是日志输出“Started Application in XX seconds”，如果你看到这行字，说明后端已经就绪。

前端页面如果是静态页面或Thymeleaf模板，直接访问http://localhost:8080；如果是前后端分离的Vue代码，通常还需要在dist目录起静态服务，或者把打包后的dist文件放在resources/static下，让它由Spring Boot直接托管。

4.3 账号数据与演示用例设计

答辩演示最核心的准备工作是准备一套“演示剧本”，而不是打开系统现场乱点。建议你按这个节奏走一遍：

第一步，拿管理员账号登录后台，展示商品管理页，添加一个新商品“海南金钻凤梨 1个装”，设置价格和库存，上传一张图片，前台立刻能看到——这叫“信息同步演示”。 第二步，切换普通用户账号，演示注册登录、搜索“凤梨”、加入购物车、提交订单、模拟支付、查看订单状态，这叫“全链路闭环演示”。 第三步，切回管理员账号，在订单列表找到新订单，点击发货，再切回用户端刷新查看“已发货”，这叫“双端状态联动演示”。

这三步走完，系统从商品到订单的管理闭环就被完整展示了一遍。答辩时每一步都要提前练熟，尤其是切换账号的操作路径，演示翻车往往不是功能有问题，而是操作路径不熟。

5. 答辩高频问题与避坑指南

5.1 评委最常追问的八个问题

把项目做完只是第一步，答辩时要能接住问题，以下八个问题是我反复见到导师提问的高频点，提前准备对策：

• 项目用了什么架构？为什么分层？标准答法是：Controller层接收请求并做参数校验，Service层承载业务逻辑并管理事务，Mapper层负责数据持久化，Entity/VO负责数据模型分层，每一层各司其职，修改某一层不会影响其他层。
• JWT和传统Session登录有什么区别？关键点：Session存在服务器内存，需要会话保持，扩展时要做Session共享；JWT无状态，Token里携带用户信息，服务端不需要存会话，适合分布式部署，但也有过期撤销难问题。
• 数据库表之间有哪些关联？建议你提前准备好说清楚：分类表和商品表是一对多，订单表和订单明细表是一对多，订单明细里的商品信息是快照字段，和商品表不是强外键关系。
• 怎么防止库存超卖？简答：用条件更新UPDATE ... WHERE stock >= count，受影响行数小于1就说明超卖，事务回滚。扩展讲：如果并发再大，可以加Redis分布式锁和Lua脚本。
• 订单和购物车之间是怎么衔接的？答：结算时读取勾选的购物车条目，在事务里创建订单主表和明细表，扣减库存，清理购物车，保证要么全成功要么全失败。
• 密码是怎么存储的？答：BCrypt加密，每次校验用encode后的密文和明文做match比对，即使数据库泄露也无法反向还原明文密码。千万不要说“我用的MD5没加盐”，这是减分项。
• 项目的核心难点和你解决它的过程？把库存并发问题和订单事务一致性讲透，顺带提一句“我通过日志和单元测试验证了并发场景下超卖被正确拦截”，这就是实证思路。
• 如果要上线，哪些地方需要改进？建议从三个方向答：支付接入真正第三方渠道；引入Redis做缓存与分布式会话；文件存储迁移到OSS对象存储；日志链路引入AOP或ELK。不用展开细节，但要让评委知道你看到了项目的边界。

5.2 实操中我踩过的坑

这套项目我前后帮人调试过不少次，有些坑几乎是每年都会遇到的，直接给你避雷清单：

• 首次启动报“Failed to configure a DataSource”：99%是配置文件里的数据库名、用户名、密码哪里没对上，或者SQL脚本忘导入了。先点开左侧Database面板实际连接测试，能连上数据库再看项目。
• 前端页面接口404或者CORS报错：大概率是后端接口路径和前端请求不一致，或者没加跨域配置类。解决方式是看浏览器Network面板里的实际请求路径，和后端Controller的@RequestMapping一一核对。跨域问题加一个WebMvcConfigurer配置类，允许所有源访问。
• 加了新商品图片显示不出来：先确认图片有没有进静态资源目录，再检查图片URL是不是项目访问前缀 + 文件相对路径拼接的。注意Windows和Linux路径分隔符不一致，不要写死反斜杠。
• 高并发测试时订单表和库存表数据不一致：多半是事务没加在正确位置。在Service层的创建订单方法上加@Transactional，并且确保这个方法内部的所有数据库操作都走同一个数据源，没有出现自己调用自己的this.method()导致事务失效的情况。
• MySQL连接报Public Key Retrieval is not allowed：在JDBC URL后面加上allowPublicKeyRetrieval=true。这是MySQL 8.0使用caching_sha2_password认证插件时的常见问题。

5.3 常见问题速查表

6. 项目二次开发方向：让成绩从“良好”冲到“优秀”

如果你想把这套项目的档次往上再抬一个台阶，不需要推倒重来，在现有骨架上做几个“精准增强”就够了。

第一个值得做的方向是数据可视化看板。在管理后台增加一个统计页面，用ECharts或AntV G2渲染折线图、饼图、柱状图，展示近七天销售额趋势、分类销售占比、热门商品Top10、用户增长曲线。数据从订单明细表和用户表里聚合查询，写几个SQL就够。这会让管理后台一眼看上去“有数据驾驶舱”的感觉，答辩演示时非常加分。

第二个方向是搜索性能优化。当前如果用的是LIKE模糊查询，可以扩展引入Elasticsearch或MySQL全文索引。不过毕设论文写这个方向要注意尺度，你只需要在管理后台加一个“搜索日志”表，记录用户搜索的关键词，再基于关键词频次做热词推荐，这就把一个小功能点做成了有分析价值的小模块，投入不大，但能讲的故事很多。

第三个方向是订单全流程监控。给订单系统增加“超时未支付自动取消”的定时任务，用Spring Schedule定时扫描待付款且超时的订单并回补库存。再加一个“操作日志表”，管理员每次发货、取消订单、修改商品库存都记录操作人、操作时间、操作内容和变更前后值，这让系统的审计性更强。

第四个方向是快递物流模拟。在订单发货后写一个模拟物流状态表，定时更新“已出库、运输中、派送中、已签收”等状态，用户端查物流能看见动态流转。这不仅丰富演示效果，还能展示你对状态机和时间调度的理解。

6.1 扩展后的技术栈演进

二次开发后，技术栈可以顺势扩展成：Spring Boot + Spring Schedule + ECharts + Redis + OSS模拟存储。每一项都可以在论文里单独写一小节做技术调研，项目的工作量和创新点看起来会充实很多。不过一定注意：扩展功能必须在核心链路全部跑通并稳定之后再做，别本末倒置——答辩时评委最在意的是主流程能不能完整跑通，花哨功能是锦上添花，不是雪中送炭。

6.2 文档协同的重要性

做毕设做到后期，很多人只顾着写代码，却忘了论文和项目的对应关系。我的经验是：每完成一个模块，立刻用一段两百字把“该模块的功能描述、涉及表、接口设计、技术要点”写进文档草稿。比如做完购物车模块，就记下“购物车模块主要涉及cart_item表，接口包括增减商品、修改数量、删除条目、结算预览，使用事务保证结算原子性”。等真正写论文时，你会发现这些素材直接就能组织成第三章和第四章，工作量直接减半。

从个人经验来看，基于Spring Boot的水果购物管理系统属于“下限稳定、上限开阔”的选题。你花两周能把主流程跑通，花一个月能把它打磨得相当精致。核心业务链路清晰、技术栈主流且可深度追问、业务场景贴近日常生活，这三点决定了它特别适合作为毕业设计的载体。如果你正在选型阶段反复纠结，不妨就把这套项目跑一遍，自己动手加一个小功能，比如“按产地筛选”，信心马上就有了。代码永远是自己亲手跑起来才算真正属于你的，祝顺利。