做了小半年的线上水果销售系统，从选题纠结到答辩通过，回头再看这个 SpringBoot + Vue + MySQL 的项目，踩过的坑和沉淀下来的经验都挺值得记录的。很多准备做毕业设计的同学问我是怎么把商城类系统做得完整又能顺利毕业的，其实核心就三点：业务闭环要清晰、技术栈要主流可解释、项目要能真正跑起来。这篇就以我实际开发的精品水果线上销售网站平台为例，把从数据库设计到前后端联调、从部署到论文整理的完整过程拆开讲清楚，希望能给正在选题或卡在开发阶段的你一些直接能用的参考。

这个项目的定位是面向在校学生的毕业设计，同时兼顾课程综合实践，适合有一定 Java 基础、想系统梳理 SpringBoot 后端开发流程的同学参考。整套系统解决的是水果零售线上化的"展示—下单—支付—履约—管理"全链路问题，前端用 Vue 做单页应用，后端用 SpringBoot 提供 RESTful 接口，MySQL 负责数据持久化，业务上覆盖用户端和管理员端两大角色。

1. 项目方向确定与技术选型思路

1.1 为什么选"精品水果线上销售"这个切入点

毕业设计选题最大的忌讳是飘在空中，评委老师第一眼基本都看两件事：业务是否完整、技术是否落地。我最初想过做通用商城系统，但通用商城功能泛化，商品类型、订单流程、库存逻辑都缺少行业特征，答辩时很难讲出"我针对某类业务做了哪些专门设计"。换成精品水果销售场景之后，业务特征一下子就具体了——水果是生鲜品类，对分类管理、库存扣减、订单履约都有更细致的要求。

水果电商的"精品"定位还带来了一个加分项：商品主图、描述详情、价格体系、用户评价这几块内容更丰富，前端页面发挥空间大，视觉呈现效果好，演示的时候不会显得空。再加上水果这类商品天然适合按重量、按份数售卖，订单明细和购物车的设计可以做出差异化，不至于照搬教科书里的标准电商模板。

1.2 三大核心技术的组合逻辑

技术选型直接决定开发效率和答辩说服力。SpringBoot 解决了传统 SSM 项目繁琐的 XML 配置问题，内置 Tomcat 之后直接 jar 包启动，对毕业设计来说省掉了大量环境折腾时间。Vue 则让前端代码模块化、组件化，页面局部刷新体验好，和 SpringBoot 后端开发天然是前后端分离的经典组合。MySQL 作为关系型数据库，对订单、库存这类强事务、强一致性数据场景非常合适，JOIN 查询也顺手。

这套组合的另一个优势是生态成熟，网上资料和对应组件极其丰富。遇到跨域就配 CORS 过滤器，要做前端打包就 npm run build，要写接口文档用 Swagger，每一环都有现成方案可以抄作业。对于一个人完成的毕设项目来说，降低试错成本比追求技术新奇重要得多。

1.3 与其他方案的对比取舍

很多同学纠结该不该用前后端分离，还是退回传统的 JSP 方案。我个人强烈建议，除非天生擅长模板引擎，否则还是拥抱 Vue + SpringBoot 的前后端分离结构。JSP 方案虽然部署简单，但页面逻辑和后端耦合严重，写出来的代码往往像意大利面，论文里的架构图也不好画。

用小程序方案替代 Web 要考虑审查和部署成本，微信小程序的类目审批对"水果销售"这类涉及食品的要上传资质，毕业设计演示反而不方便。所以 Web 端反而是最稳妥的：浏览器直接开，评委手机扫码也能看，部署到云服务器后不需要安装任何客户端。

2. 数据库设计：把电商业务特征用表结构表达出来

数据库是这类项目的底座，我见过太多人一上来就写 CRUD，写到后面发现购物车、订单、库存之间对不上账，根子就在表设计没想清楚。这份数据库脚本最终被我写进了论文的需求分析章节，这里把核心表结构和设计原因逐个讲透。

2.1 整体库表结构与关系梳理

精品水果销售平台一共设计了 7 张核心表：用户表、水果分类表、水果商品表、购物车表、收货地址表、订单主表、订单明细表。这个数量不多不少，既能完整表达电商业务，又不会像企业级系统那样动辄二三十张表，答辩时能把每一张表的用途讲清楚，这本身就是加分项。

用户表存放用户的基本登录信息和注册时间，密码做了 MD5 加盐加密，虽然比不过 BCrypt 安全级别，但做成毕业设计完全够用，也方便在论文里解释加密流程。分类表是水果的一级和二级分类结构，比如"时令鲜果"下挂"夏季瓜果"，用 parent_id 字段做自关联，标准的无限级分类处理方式。

水果商品表是最核心的一张表，除了基本的名称、价格、库存、销量、主图地址、详情描述之外，我特意加了"是否上架"状态字段。这个字段在后端实现时很重要，管理员下架商品后用户端查询会自动过滤下架商品，否则会出现用户能下单但管理员早就删掉商品的脏数据场景。

2.2 订单主表和明细表为什么要拆成两张

订单主表存订单编号、下单用户、收货信息、订单总金额、订单状态，订单明细表存每个商品的下单快照（商品名称、单价、数量、小计）。拆成两表的原因非常经典：一个订单可能包含多种水果，主表不便于横向存储多个商品，明细表则解决一对多问题。

同时明细表字段设计时特意保留了商品名称和单价的冗余快照，而不是直接关联商品表。这么做的原因是商品的价格和名称随时可能变化，而过了一个月用户查历史订单时，应该看到的是下单当时的价格，一旦关联实时商品表，价格会跟着变，订单记录就没有可信度了。这个细节答辩时一提，老师就知道你理解订单快照的含义。

订单状态字段我用整数类型存储：0 表示待付款，1 表示已付款待发货，2 表示已发货，3 表示已完成，-1 表示已取消。用整数而不是字符串，是为了后端判断和前端展示都更高效，前端通过枚举映射成中文描述。还加了两个时间字段：创建时间和支付时间，后续做数据统计和订单筛选都有用。

2.3 建表脚本与初始化数据

数据库脚本是我先手绘 ER 图再生成的，强烈建议大家不要直接写 SQL，先用工具画好关系再导。我用的数据库名是 fruit_sales，下面是商品表的核心建表语句，可以直接参考：

CREATE TABLE `fruit_product` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '商品ID', `category_id` int(11) NOT NULL COMMENT '所属分类ID', `product_name` varchar(100) NOT NULL COMMENT '商品名称', `product_desc` varchar(255) DEFAULT NULL COMMENT '商品描述', `main_image` varchar(255) DEFAULT NULL COMMENT '主图路径', `price` decimal(10,2) NOT NULL COMMENT '销售价格', `stock` int(11) NOT NULL DEFAULT 0 COMMENT '库存', `sales_count` int(11) NOT NULL DEFAULT 0 COMMENT '销量', `is_on_sale` tinyint(1) NOT NULL DEFAULT 1 COMMENT '是否上架：1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间', PRIMARY KEY (`id`), KEY `idx_category_id` (`category_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='水果商品表';

初始化数据建议提前想好六个左右的分类，每个分类下放四到八个商品，主图用本地静态路径。为了让演示效果好看，我给樱桃、荔枝、芒果、蓝莓这类颜色鲜亮的水果配了清晰的图片，答辩时视觉效果确实会比白底文字好很多。

3. 后端核心功能模块实现

后端我用的是经典的分层架构：Controller 控制层接收请求、Service 业务处理、Mapper 数据访问，每一层的职责边界要清晰。实体类放 entity 包，DTO 和 VO 按需创建，统一使用 Result 对象封装返回格式，前端拿到的是"是否正确、提示信息、具体数据"三段式结构。

3.1 用户注册登录与登录态保持

注册逻辑不复杂，但要注意几个细节：用户名要做唯一性校验，注册时校验两次密码是否一致，密码不能明文存库。我在 Service 层对密码做了 MD5 加盐加密，盐值直接取用户名中的一段，这样同一个密码在不同用户账号下的密文完全不同，有效防止了简单的彩虹表碰撞。

登录之后我用 Token 机制保持会话，后端在用户登录成功后生成一个 UUID 字符串作为 token，存储到 Redis 里并设置过期时间，前端每次请求在请求头带上这个 token，后端拦截器统一校验。相比使用 Session 的方式，Token 方案更适合前后端分离项目，也方便后续扩展成真正的分布式登录态。

实际开发中我在拦截器上踩过一个小坑：拦截器默认拦截所有请求，结果把用户的登录接口也拦了。解决方式是在拦截器配置中放行登录、注册、商品列表查询、首页轮播图这类不需要登录即可访问的接口，其余接口都校验 Token。配置类里用排除列表的方式写清晰，代码可读性高很多。

3.2 购物车设计：数据库存储还是本地方案

购物车我选择用 MySQL 表存储，表字段包含用户 ID、商品 ID、数量，通过唯一索引避免同一用户重复加入同一商品。每次加入购物车时，如果已存在同用户同商品，就执行库存累加操作，否则插入新记录。这个方案的好处是用户换设备登录后购物车依然保留，坏处是每次增删改查要多几次数据库交互，但毕业设计的数据量下完全不是问题。

购物车列表联查商品表，返回除购物车基础信息之外还带上商品名称、主图、实时价格、小计等展示字段。前端 Vue 页面循环渲染购物车列表，底部统一计算总金额。我还做了购物车勾选功能，只有勾选的商品才参与总价计算，这是电商购买体验的常见细节，写论文时放在了用户体验设计部分。

这里提醒同学们：购物车存储的是商品 ID 和数量，而不是商品的价格快照，因为购物车里的价格应该跟随商品当前价格动态变化，用户加入购物车到真正下单之间可能隔了几天，价格变更是正常业务。这和订单明细存快照是两套逻辑，不要搞混。

3.3 下单流程与库存扣减的原子性

下单接口是整个系统最复杂的逻辑，涉及验证登录状态、查询商品价格、计算总金额、插入订单主表、批量插入订单明细表、扣减库存、清空购物车多个步骤。我在 Service 方法上加了 @Transactional 注解保证这些操作形成一个事务，任一步骤失败都会整体回滚，不会出现订单建了库存没扣的脏数据。

库存扣减的 SQL 我用的是带条件的更新语句：

UPDATE fruit_product SET stock = stock - #{count} WHERE id = #{productId} AND stock >= #{count}

这样写的好处是扣库存和校验库存是否充足合并成一次原子操作，如果受影响行数为 0，说明库存不足，直接在 Service 层抛出业务异常。高并发场景下这个写法要靠数据库行锁兜底，但毕业设计流量下完全够用，而且面试或答辩时能说出"利用行锁保证原子性"这句就已经是加分项了。

订单编号我没有用数据库自增 ID，而是用时间戳加随机数拼接生成，格式类似 202506011530120001，这样订单号有条理可读，也方便后续对账。业务异常我自定义了 BusinessException，配合全局异常处理器统一返回错误信息。

3.4 管理员后台的统计与订单处理

管理员模块包含商品管理、分类管理、订单管理和简单的销售统计。商品管理的 CRUD 相对基础，重点在图片上传：前端通过 Element UI 的上传组件把图片发送到后端，后端接收 MultipartFile 保存到服务器指定目录，并将访问路径返回给前端存储到商品表。

订单管理对管理员是可操作的订单状态流转：待付款订单可以关闭，已付款订单可以发货，已发货订单可以标记完成。这个流程一定要和前端按钮联动，后端每次修改订单状态时校验当前状态是否合法，比如"已发货"订单不能直接改成"待付款"，防止状态跳变。统计模块我做了按日期的销售金额柱状图数据接口，前端用 ECharts 渲染，两张图就能让页面显得饱满。

4. 前端 Vue 页面结构与交互实现

前端是用户在浏览器里看到的一切，页面设计直接决定项目给评委的第一印象。我选择 Vue 2 + Element UI 的组合，虽然 Vue 3 已经是主流，但 Vue 2 的生态更稳，遇到问题搜到的答案也更多，毕设阶段求稳比追新重要。

4.1 前端路由与页面整体规划

用户端我规划的页面有：首页、商品列表页、商品详情页、购物车页、订单确认页、个人中心页、订单列表页。管理员端独立用一套布局，包含商品管理、分类管理、订单管理、销售统计四个页面。前端路由用 Vue Router 配置，配合路由守卫做登录权限控制，未登录用户访问购物车和订单确认页会强制跳转到登录页。

首页重点突出"精品水果"的视觉调性，顶部是轮播图，中间按分类展示几种推荐水果，底部是热销排行榜。商品列表页通过 URL 参数传递分类 ID 和搜索关键词，支持按销量、价格排序。详情页展示大图、价格、库存、销量、描述，底部是"加入购物车"和"立即购买"两个主按钮。

4.2 前端请求封装与跨域处理

前端所有接口请求统一封装在一个 request.js 里，基于 axios 封装了请求拦截器和响应拦截器。请求拦截器从 localStorage 取出 token 放入请求头，响应拦截器统一处理后端返回的 Result 结构，遇到 code 不等于 200 的情况弹出错误提示并可以拦截到登录页。

跨域问题是前后端分离项目几乎必踩的坑。开发阶段我在 Vue 项目的 vue.config.js 里配置了代理：

devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求 /api 开头的地址会被代理转发到后端 8080 端口，绕开了浏览器的同源策略限制。部署阶段后端再配置跨域过滤器允许指定源访问，两层保障保证线上访问不会有跨域问题。

4.3 Element UI 组件与页面交互细节

Element UI 的组件库让后台管理页面的开发效率直线上升。表格直接用 el-table，表单校验用 el-form 的 rules 规则，弹窗提示用 this.$message，几乎不需要手写任何 UI 样式。用户端则是自己写了手写 CSS，配合 Element UI 的按钮和输入组件，整体风格更偏商城风格，避免每个页面看起来都是一个模子。

购物车页面交互里我做了数量增减按钮和勾选状态联动。数量变化时通过请求实时更新后端数据库，勾选状态只在前端维护，结算时把勾选的购物车条目 ID 传给后端生成订单。这里要注意前端数量增减最好做成防抖处理，否则用户快速点击加减号时会产生大量并发请求，后端可能出现库存扣减异常。

订单确认页展示用户的默认收货地址，支持切换其他已保存地址。地址管理我放在个人信息模块里，用户可以新增、修改、删除收货地址，下单时默认选择最近设置的常用地址。前端表单提交前会做地址完整性校验，收货人、手机号、详细地址三项都填了才允许提交订单。

4.4 管理端的数据可视化实现

销售统计页面我用了 ECharts 折线图和柱状图两种图表。后端提供统计接口，按日期分组返回近七天的订单金额和订单数量，前端拉取数据后构造 ECharts 需要的 option 对象渲染。这点工作量不大，但在论文截图和答辩演示时非常占便宜，图表比表格直观得多，老师一眼就能看出销量增长趋势。

除了订单统计，我还做了商品销售排行榜，按每个商品的销量从高到低排序，用横向柱状图展示。前端初始化图表时注册了 resize 事件，保证浏览器窗口变化时图表自适应，这个小细节能避免演示切换窗口时图表被拉扯变形。

5. 部署流程与避坑实操记录

很多同学数据库表设计和前后端逻辑都写好了，卡在部署上无法运行。我在这里把完整部署流程梳理一遍，从本地开发环境到打包上云服务器都覆盖，按这个顺序操作基本不会出大问题。

5.1 本地环境准备与初始化运行

本地开发需要的环境依次是：JDK 1.8 或以上、Maven 3.6 以上、Node.js 14 以上、MySQL 5.7 或 8.0。后端的 application.yml 里要配置数据库连接信息、端口、文件上传路径，我这里把关键配置列出来作为参考：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/fruit_sales?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: 123456 servlet: multipart: max-file-size: 10MB max-request-size: 20MB

初次运行时先把 fruit_sales.sql 导入 MySQL，确保数据库和表结构创建成功。启动后端项目后浏览器访问 Swagger 或直接调用登录接口验证。前端在项目根目录执行 npm install 安装依赖，然后 npm run serve 启动开发服务器。看到控制台出现编译成功提示后，访问默认端口 8080 的前端页面，系统就算在本地跑起来了。

5.2 前后端打包与云服务器部署

本地调试通过后打包部署，后端的打包命令是 mvn clean package -DskipTests，生成的 jar 包位于 target 目录下。前端打包先修改请求地址的 baseURL 指向后端公网地址或域名，然后执行 npm run build，生成 dist 静态文件目录。

部署时我用了比较省钱的方式：购买一台最低配的云服务器，装好 JDK 和 MySQL，把后端 jar 包直接放到服务器上用 nohup java -jar 命令后台启动。前端 dist 目录里的静态文件用 Nginx 托管，Nginx 同时配置反向代理，把接口请求转发到后端进程。

5.3 常见问题排查与处理速查

整个开发和部署过程中必然会遇到一些问题，我整理了自己遇到的高频问题和解决路径，做成表格方便直接对照。

这里重点说一下图片上传路径的处理。后台上传的商品图是存服务器的，我就吃过亏：理解成把图片存到前端项目的 static 目录就能访问，结果打包后路径完全对不上。正确做法是在后端配置一个静态资源映射，把本机保存上传图片的目录映射成 /upload/ 开头的访问路径，这样商品表里只存 /upload/xxx.jpg 这种相对路径，前端拼接后端地址就能访问图片。

6. 论文组织与答辩准备心得

代码写完只是完成了一半，毕业设计论文和答辩准备的呈现方式同样重要。我当时把论文结构设计成"选题背景—技术选型—系统分析—系统设计—系统实现—系统测试"六个章节，其中技术选型和系统设计放在最重的位置，因为这两章最能体现自己的思考过程。

论文里的架构图我建议手动用绘图工具画清楚三层结构的调用关系，前端页面用截图配文字说明功能点。数据库设计章节不要全部贴 SQL，而是放关键的 ER 图和表字段说明表。每张表用一个表格列出字段名、类型、注释，这样老师不用去翻源码就能快速理解设计层次。

答辩时老师最常问的问题是：库存怎么保证不超卖、订单状态怎么流转、为什么选这个数据库、跨域怎么处理、上线了没有。我准备的思路是每个问题都回到自己的实现细节上去答，比如库存问题就说用了条件更新加事务回滚，跨域问题就说本地用代理上线用 Nginx，每个答案里都有真实代码支撑，讲得越具体越可信。

7. 写在最后的一些实际体会

这套系统从头到尾开发大约用了六周时间，真正花时间最多的不是写代码，而是前后端联调和细节打磨。碰到过一次非常典型的坑：前端购物车点击"去结算"后请求报错，后端日志显示空指针，排查后发现是后端接收前端传的购物车 ID 列表参数名不匹配，前端传的是 cartIds，后端参数名写成 cartIdList，联调问题定位浪费了整整一个晚上。

所以我的建议是，开发过程中前端和后端的接口参数命名一定要提前约定好，甚至可以直接用 Apifox 或 Swagger 生成接口文档，在联调前把数据字典对齐，能省掉大量无效调试时间。数据库备份也要养成习惯，每完成一个阶段就导出一次 SQL 脚本，这样就算改坏了也能快速回滚。

如果时间允许，还可以给项目做一些扩展，比如接入真实支付接口的模拟器、引入 Redis 缓存热门水果列表、增加用户评论功能。这些扩展点不需要在毕设阶段全部实现，但要写进论文的展望章节，让老师看到你对系统进一步演进是有想法的。

好的毕业设计不一定是最复杂的，但一定是最完整、最能自圆其说的。把一个商城类的系统从数据库到前端页面每一层都吃透，甚至能独立部署上云跑起来，"会做"和"能讲清楚为什么这么做"这两点，就已经超过绝大多数人了。这个项目做完之后，我自己对前后端分离的项目结构、电商业务的数据建模、以及从开发到上线的完整链路的理解都有了质的提升。