简介这是一套面向计算机专业本科生的高分毕业设计级花店销售系统实战资源适用于毕业设计、课程设计及期末大作业场景解决传统花店线上化运营中商品管理、订单处理与用户交互等核心业务需求。资源包共1405个文件含164个Java后端逻辑文件、242个Vue前端页面组件、318个SVG图标资源、154张JPG商品图及126个JS交互脚本辅以MySQL建库脚本sql、Spring Boot配置文件yml和批处理部署脚本bat整体压缩包大小为52.69MB。已有100人学习下载资源经导师指导并通过答辩所有模块均严格调试可直接运行。读者可获得完整前后端源码、可一键导入的数据库结构与初始数据、配套Navicat可视化操作支持以及清晰分层的项目目录结构——包括admin后台管理、user用户中心、cart购物车、order订单流程等标准电商模块开箱即用无需二次适配。 本文以一套完整的花店销售系统毕业设计项目为切入点从技术选型、数据库设计到前后端实现详细拆解了基于 Java SpringBoot Vue MySQL 的全栈开发全过程。文章中不仅还原了核心功能模块的设计思路还补充了大量实操经验、避坑指南和常见问题排查方法。无论你是正在准备毕业设计的学生还是想学习主流前后端分离架构的初学者这份内容都可以直接对照参考。1. 项目整体设计与技术选型分析很多同学拿到“花店销售系统”这类题目时第一反应通常是“又是一个简单的 CRUD”。但如果你真的只做几个增删改查页面那这个毕业设计大概率只能拿个中等分数。这篇博客里我会结合这套花店销售系统项目把整个设计和开发逻辑完整拆开讲帮你搞清楚真正有价值的技术点在哪里以及你自己做的时候该把精力花在什么位置。先说技术选型。Java SpringBoot Vue MySQL 这套组合是国内全栈开发领域最主流的搭配之一。SpringBoot 负责后端接口服务Vue 负责前端页面渲染和交互MySQL 负责数据持久化存储。这套架构的好处是分工明确、生态成熟、学习资料多而且非常贴近企业实际开发环境。你面试时如果说“我独立完成过一个 SpringBoot Vue 的前后端分离项目”这个加分效果是很明显的。再往细了说SpringBoot 本质上是 Spring 框架的进一步封装它通过自动配置和起步依赖把过去 Spring 项目里那些繁琐的 XML 配置全部干掉让开发者能快速搭建一个可运行的 Web 服务。Vue 则是一个渐进式 JavaScript 框架它最舒服的地方在于组件化开发和响应式数据绑定写页面的时候逻辑很清楚不会像传统 jQuery 那样到处都是 DOM 操作的影子。MySQL 就不用多说了关系型数据库里的老大哥稳定、可靠、文档全用它做毕业设计的数据库没有任何问题。回到花店销售系统这个具体场景。它的核心业务其实是典型的电商模型但又和纯线上商城不太一样——花店商品的时效性强、鲜花配送有特殊性、节日订单会暴增。这些业务特点都会直接影响你怎么设计数据库、怎么写业务逻辑。比如鲜花这种商品库存管理就比普通商品要复杂得多你不能只记录一个数字还得考虑保质期、批次管理、损耗处理这些现实因素。这些点如果你能在设计文档里写出来答辩的时候会显得非常有深度。那这套系统需要什么功能呢站在用户角度用户要能浏览商品、查看商品详情、注册登录、下单购买、管理收货地址、查看订单状态站在管理员角度要能管理商品分类和商品信息、处理订单、管理用户、查看销售统计数据。去重之后大概就是商品管理、订单管理、用户中心、购物车这四大核心模块。这套系统的设计里有两个地方值得特别关注一个是商品模块和订单模块之间的数据联动另一个是前端页面和后端接口的数据契约。这两个问题解决好了整个项目的骨架就算是立住了。下面我会分章节详细拆解每个模块的实现思路。2. 核心模块设计与功能拆解2.1 用户端功能模块用户端是购买者直接接触的系统体验好坏直接影响成交率。花店销售系统的用户端功能主要包含注册登录、商品浏览、购物车、订单管理以及个人中心五大部分每一部分都有一些需要特别留意的细节。游客登录后先要看到首页。首页通常包含轮播图展示、分类导航、热销商品推荐和最新商品推荐几个区域这些信息都要从后端接口动态拉取而不是写死在页面里。商品列表页则支持按分类筛选、按销量或价格排序还有关键词搜索。我建议你这里用 MyBatis-Plus 的分页插件做分页查询一次性加载全部数据会严重拖慢响应速度性能上很吃亏。用户点击商品卡片进入详情页时前端发出带商品 ID 的请求后端返回商品完整信息包括多张图片、详细介绍、价格、库存。这里有个技术细节商品详情页的图片通常要支持多图展示数据库中一般存的是图片 URL 列表而不是一张图片存一个字段。实现时可以在商品表里用 JSON 字符串存图片路径集合也可以单独建一张商品图片表。前者查询方便后者扩展性更好看你个人偏好。购物车是电商系统的标配功能实现方式有两种一种是把购物车数据存到后端数据库另一种是存在浏览器 localStorage 里。前者需要登录后才能使用好处是换设备数据不丢失后者无需登录省服务端资源但用户清浏览器缓存后数据就没了。这套系统采用的方案是用户登录后购物车数据关联到用户账户存到数据库中。这个方案更规范也能避免用户因为在不同设备上切换导致购物车数据不一致的问题。订单模块是用户端的核心也是技术点最密集的部分。用户从购物车结算时系统要一次性处理多个商品的库存扣减、订单创建、价格计算等操作。这里要注意两个容易出问题的地方第一库存扣减和订单创建必须放在同一个数据库事务里不然会出现订单创建成功但库存没扣、或者反过来库存扣了订单却失败的数据不一致问题第二下单时要判断商品是否处于上架状态防止用户通过构造请求买到已经下架的商品。个人中心包含用户信息编辑、收货地址管理、订单列表展示等功能。订单列表要按状态分类展示通常分为待付款、待发货、待收货、已完成、已取消等几个 Tab 页。这里前端可以用 Vue Router 实现页面切换后端则提供按状态查询订单的接口。2.2 管理员端功能模块管理员端是运营人员使用的后台管理界面功能要比用户端复杂不少。主要包括数据看板、商品管理、分类管理、订单管理、用户管理五大模块。数据看板是进入后台后的默认页用于展示核心经营数据包括今日销售额、今日订单量、商品总数、用户总数等汇总信息还可以用 ECharts 画一张近 7 天的销售趋势折线图。这类统计功能如果前端做会导致页面加载慢、数据不准确正确做法是后端通过 SQL 聚合函数sum、count、group by来统计前端只负责展示接口返回的结果。比如查询今日销售额SQL 类似这样SELECT IFNULL(SUM(total_price), 0) AS today_sales FROM orders WHERE create_time CURDATE() AND order_status 已完成;商品管理是后台最常用的模块要求管理员能发布新商品、编辑商品信息、上下架商品、删除商品和查看商品详情。这里有个小坑物理删除商品会导致历史订单里的商品信息失效因为订单详情里引用了商品 ID一旦商品被删用户查看历史订单时就会显示异常。稳妥的做法是采用逻辑删除给商品表加一个 delete_flag 字段删除操作只是把标志位改成 1查询时默认过滤掉这些记录。这套系统用的就是逻辑删除方案。分类管理比较简单就是商品分类的增删改查。但如果你想让系统更专业建议做成两级分类比如“鲜花”下面分“玫瑰”“百合”“康乃馨”等子类。实现方式是在分类表里加一个 parent_id 字段为 0 表示顶级分类否则表示子分类。这样一个二级分类模型就出来了后端接口也能相应提供按父分类查询子分类的功能。订单管理是后台最核心也最容易出错的模块。管理员需要能查看全部订单列表、按订单号或用户模糊查询、查看订单详情、修改订单状态发货、取消订单。这里最容易出现的问题是并发场景下多个管理员同时处理同一笔订单。比如管理员 A 正在点击发货管理员 B 同时取消了这笔订单如果不做状态校验就会出现已取消订单被发货的严重 bug。解决思路是每次执行状态更新时在 SQL 的 WHERE 条件中带上当前状态作为前置校验。用户管理模块负责查看注册用户列表、启用或禁用用户账号、重置用户密码。重置密码时要注意密码不能以明文存储必须经过加密后再入库。Spring Security 或 Sa-Token 都自带 BCrypt 密码加密工具直接调用即可。2.3 购物车与订单流转购物车与订单的联动是整个系统业务逻辑最密集的区域也是面试官最喜欢提问的地方。我单独拿出来详细讲一下。用户把商品加入购物车此时购物车记录包含用户 ID、商品 ID、数量这些关键信息。前端展示购物车页面时要显示每件商品的小计价格和整个购物车的总价。商品价格可以从商品表实时查询这样做的好处是如果商品价格发生变动用户看到的始终是最新价格避免以旧价格结算的纠纷。从购物车结算时前端把购物车中选中的商品 ID 列表和对应数量传给后端后端一次性完成校验商品状态、计算总价、创建订单、生成订单详情、清空对应购物车记录、扣减库存等一连串操作。这一步里事务管理是绝对不能省的。Spring 的 Transactional 注解可以保证这个方法内任何一步出错所有数据库操作都会回滚。我在项目里把库存扣减的 SQL 设计成了条件更新即只有当库存充足时才扣减UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity};这样写的好处是用数据库的行锁机制天然规避了超卖问题。如果更新影响行数为 0说明库存不足直接抛出异常交给事务回滚即可。这个设计值得你仔细体会它比先查库存再扣减的方式要安全得多因为两步操作之间是有时间窗口的并发场景下容易出问题。订单生成以后用户端的订单列表会显示待发货状态管理员端也能看到这笔新订单。管理员发货后订单状态变为待收货用户可以点击确认收货订单最终变为已完成状态。整个状态流转可以用一个状态机来描述但注意不要用 Mermaid 画图直接用文字说明即可待付款 →支付→ 待发货 →发货→ 待收货 →确认→ 已完成另外从待付款和待发货状态都可以进入已取消状态。3. 数据库设计与关键表结构详解3.1 表关系整体规划数据库设计是毕业设计中分值很高的一部分也是答辩老师几乎必问的板块。花店销售系统的数据表我总共规划了八张核心表用户表、商品分类表、商品表、购物车表、订单表、订单详情表、收货地址表、管理员表。其中订单表和订单详情表是主从关系一个订单对应多个订单详情用户表和订单表是一对多关系商品表和分类表是多对一关系用户表和收货地址表是一对多关系。理解这些表之间的关系是设计好整个数据库的起点。订单为什么拆成订单表和订单详情表两张表因为一个订单里可能包含多个不同商品例如用户同时买了玫瑰和百合此时订单基本信息只需要记录一次订单编号、总价、收货人、状态等等而不同商品的信息则要单独记录在订单详情表里。如果把它们全部塞进同一张表就会产生大量重复数据既浪费存储空间又容易产生数据不一致。3.2 关键表的字段设计下面我把核心表的字段设计逐一提一下给你一个直接可用的参考。用户表是最基础的表字段包括 id、username、password、nickname、phone、email、avatar、gender、status、create_time。password 字段我建议设置长度为 100因为 BCrypt 加密后的字符串长度超过 60 位以前的 32 位不够用。status 字段表示账号状态1 正常 0 禁用。这个设计是通用的用户模型几乎任何系统都能套用。商品分类表字段有 id、parent_id、name、sort_order、create_time。这里的 sort_order 用来控制分类在页面上的展示顺序数字越小越靠前。设计的时候哪怕是二级分类我也建议从一开始就预留 parent_id不要嫌字段多后面功能扩展时你会感谢这个设计。商品表是整个系统中最核心的一张表。字段包括 id、category_id、name、sub_title、main_image、detail_images、price、original_price、stock、unit、sales、status、delete_flag、create_time、update_time。其中 detail_images 字段用 JSON 格式存储商品的详情图片列表前端拿到后遍历展示。status 是上下架状态1 上架 0 下架。delete_flag 是逻辑删除标记这样商品删除后不会影响历史订单的数据完整性。购物车表字段有 id、user_id、product_id、quantity、checked、create_time、update_time。checked 表示是否被选中用于结算时区分用户勾选了哪些商品。注意要建立唯一索引防止同一用户把同一商品重复加入购物车而产生两条记录。唯一索引的建立方式是在联合字段 user_id 和 product_id 上创建 unique index。订单表字段较多这里重点说一下。id、order_no、user_id、total_price、receiver_name、receiver_phone、receiver_address、order_status、payment_method、remark、create_time、update_time。order_no 是订单号生成时要保证全局唯一常见方案是时间戳加随机数的组合也可以使用数据库 UUID。order_status 是整个订单流转的状态标识建议用数字代表状态0 待付款、1 待发货、2 待收货、3 已完成、4 已取消。订单表中创建时间和支付时间建议都记录方便后续统计“下单但未支付”的订单数量在运营分析中很有价值。订单详情表字段有 id、order_id、product_id、product_name、product_image、price、quantity、total_price。注意这里我冗余存储了 product_name 和 product_image原因是这些商品信息是下单那一刻的快照即使管理员后续修改了商品名称或删除商品用户在历史订单里看到的依然是购买时的样子。如果不冗余存储一旦商品被编辑用户看到的订单历史就会被篡改这在业务上是不可接受的。这个冗余设计思路在很多真实企业项目中都会用到值得记住。收货地址表字段有 id、user_id、receiver_name、receiver_phone、province、city、district、detail_address、is_default。is_default 表示是否为默认地址下单时可以优先选中默认地址用户体验会好很多。这里要注意如果用户设置了新的默认地址旧的默认地址要能被取消默认状态。3.3 数据库设计的几个常见坑先来说说表和字段命名。很多同学喜欢用驼峰命名法给字段起名比如 userName、createTime这在 Java 里是标准写法但放在 MySQL 字段名里就有点不协调。MySQL 不区分大小写所以 userName 和 username 其实是一个字段容易引起混淆。业界更常见的做法是使用下划线命名比如 user_name、create_time然后在 MyBatis 的配置里开启驼峰映射Java 属性名用 userName数据库字段名用 user_name两边自动对应。外键的使用也需要谨慎。很多教程推荐在表之间建立物理外键约束来保证数据一致性但实际开发中我更倾向于不设置物理外键只保留逻辑关联关系。原因是物理外键在插入、更新、删除时都会触发数据库的完整性检查会拖慢性能而且在分库分表或微服务场景下根本无法使用。常规做法是在 MyBatis 的 XML 里通过手动编写 JOIN 查询来实现表间的逻辑关联。字段类型的选择同样容易踩坑。价格字段不推荐使用 float 或 double因为浮点数在计算机中是以近似值存储的计算金额时会出现精度丢失。比如 0.1 0.2 在浮点数运算中结果是 0.30000000000000004。金额类字段应该使用 BigDecimal 类型对应 MySQL 中的 decimal 类型。库存字段要注意不能用无符号整型不然扣减库存时如果库存不足数据库会直接报错而不是返回表示库存不足的结果。4. 后端 SpringBoot 功能实现要点4.1 项目初始化和依赖配置后端部分用的是 SpringBoot 2.7.x 版本搭配 MyBatis-Plus 3.5.x 作为数据访问框架。SpringBoot 本身的版本选择我建议别用太新的 3.x因为 3.x 是基于 Spring Framework 6 和 Jakarta EE 9 构建的很多老教程的写法都不兼容你从网上复制代码时可能踩坑。2.7.x 版本既稳定又成熟互联网上能找到的海量参考资料都适用于这个版本对于新手写毕业设计是更合理的选择。创建项目可以用 Spring Initializr 网站来生成基础骨架也可以直接用 IDEA 内置的 Spring Initializr。选择依赖时勾选 Spring Web、MySQL Driver、MyBatis-Plus需要手动添加坐标、Lombok 这几个就好。MyBatis-Plus 没有在 Initializr 的默认列表里要在 pom.xml 里手动添加dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version /dependencyMyBatis-Plus 的好处是单表 CRUD 基本上不用写 SQL它内置的 BaseMapper 已经提供好了 insert、deleteById、selectById、updateById 等常用方法。为了判断数据查询是否成功我的习惯是额外添加一个 MyBatis-Plus 的代码生成器插件它可以根据数据库表结构自动生成实体类、Mapper 接口、Service 类和 Controller 类节省大量手写代码的时间。不过自动生成的代码质量参差不齐建议你把它当作骨架核心业务逻辑还是自己手写。application.yml 配置文件是启动项目的关键。数据源配置要放在最前面包含数据库 URL、用户名和密码。这里有个细节SpringBoot 2.x 默认的数据库驱动是 com.mysql.cj.jdbc.Driver同时要在连接地址后面加上 serverTimezoneAsia/Shanghai 参数否则访问数据库时报时区错误。还要加上 useUnicodetruecharacterEncodingutf-8 来保证中文正常读写。4.2 统一响应结构和异常处理前后端分离项目里后端接口返回给前端的数据格式是开发前就要约定好的。我用的方案是统一封装一个 ApiResponse 类包含 code、message、data 三个字段。code 为 200 表示成功400 表示业务错误500 表示服务器异常。所有 Controller 的返回值都包装成这个格式前端根据 code 字段判断请求是否成功。这样做的好处是前端处理逻辑统一清晰不用每个接口单独判断不同的返回结构。统一异常处理则使用 SpringBoot 提供的 RestControllerAdvice 注解。我在类里定义了两个核心方法一个处理自定义的业务异常类比如库存不足、未登录等场景返回 code 400 和具体错误信息给前端另一个处理系统异常返回 code 500 和通用错误提示。用这个方式代码里就不需要到处写 try-catch 了业务代码能保持干净可读性也会高很多。登录认证这块我用的方案是 Sa-Token它是一个轻量级 Java 权限认证框架相比 Spring Security它的上手难度低很多。用户登录成功后框架会生成一个 token 返回给前端前端把 token 存储起来后续每次请求都在请求头里带上这个 token后端通过拦截器解析 token 来识别用户身份。拦截器里还需要判断请求路径是否在白名单内比如登录接口、商品列表、商品详情等页面不需要登录就能访问而下单、购物车、订单查询等接口则必须携带有效 token。4.3 核心业务接口实现思路商品列表接口支持按分类筛选、按关键字搜索、按价格区间过滤、按销量或价格排序同时实现分页查询。用 MyBatis-Plus 的分页插件时我先把分页拦截器配置成一个 Bean 注册到容器中然后在 Service 层调用 page 方法即可。但如果是多表关联查询比如商品表 JOIN 分类表筛选分类名称就不能直接用 MyBatis-Plus 的现成方法了需要自己在 XML 里写 SQL先用 Page 对象作为参数传入 Mapper 方法再在 XML 中写带 动态条件的 SELECT最后返回分页结果。这样既保留了分页能力又能自定义复杂 SQL。订单模块的 Service 方法是最值得设计的。我定义一个 createOrder 方法参数是接收前端传来的地址 ID、备注信息以及购物车中勾选商品 ID 列表。方法内部先查出所有购物车记录再逐个校验商品状态和库存如果任何一个商品库存不足就抛出异常。然后计算总价、生成订单号、插入订单主表数据。接着遍历购物车列表逐条插入订单详情表。最后批量删除购物车记录、批量扣减商品库存。全部操作之后Transactional 注解保证整个方法的原子性。如果中间任何一步失败所有数据库变更都会回滚不会出现脏数据。统计接口这块用 MyBatis-Plus 的 Wrapper 条件构造器能完成简单条件统计比如统计用户总数使用 count 方法配合条件。但像“查询每个分类的商品数量”这种分组统计需求就得自定义 SQL 了。类似地“查询近 7 天每天的销售额”也需要用到函数例如 date_format 和 group by。这类统计 SQL 建议单独写在 XML 文件里保持 Mapper 接口的整洁。5. 前端 Vue 页面搭建与交互实现5.1 Vue 项目结构和路由配置前端部分用的 Vue 2.7 搭配 Element UI 组件库。Vue 的脚手架工具 Vue CLI 可以快速创建项目。创建完成后src 目录下主要包含 api、router、store、views、components 五个文件夹。api 文件夹放所有后端接口请求的封装router 文件夹放路由配置store 文件夹放全局状态管理views 文件夹放页面组件components 文件夹放公共组件。路由配置需要区分用户端和管理员端两种布局。用户端首页路由是 /商品列表是 /product-list商品详情是 /product/:id购物车是 /cart结算页是 /checkout订单列表是 /orders。管理员端所有页面都挂在 /admin 路径下包括数据看板 /admin/dashboard、商品管理 /admin/product、分类管理 /admin/category、订单管理 /admin/order、用户管理 /admin/user。路由守卫是特别重要的一环。全局前置守卫 beforeEach 每次路由跳转前都会执行先判断目标路由是否需要登录权限如果需要且本地没有 token就重定向到登录页如果用户已经登录再去访问登录页也应当重定向到首页避免重复登录。管理员路由还需要额外校验当前用户的角色码只有角色码是管理员才能访问。这个逻辑看起来简单但能有效防止未授权用户通过直接输 URL 的方式访问后台页面。5.2 Axios 请求封装与拦截器前端请求后端接口用的 HTTP 库是 Axios它功能强大而且支持拦截器机制非常适合做统一封装。我在 api 文件夹里创建了一个 request.js 文件使用 axios.create 方法创建实例设置 baseURL 为后端接口地址前缀超时时间设置为 10000 毫秒。然后在请求拦截器里每次发请求前从 localStorage 里取出 token如果存在就添加到请求头的 Authorization 字段。在响应拦截器里如果后端返回的 code 是 200就正常返回 data如果 code 是 401说明 token 失效需要清除本地登录信息并跳转登录页如果 code 是其他业务错误使用 Element UI 的 Message 组件弹出错误提示直接告诉用户。封装好 request 工具后每个 API 模块就是一个独立的 JS 文件。比如 product.js 里定义 getProductList、getProductDetail、addProduct、updateProduct 等方法每个方法内部调用封装好的 request 并传入对应参数。这样组件代码里只需要引入这些方法不需要接触 Axios 底层逻辑代码干净也方便维护。5.3 主要页面实现逻辑商品列表页是用户端访问最频繁的页面之一。页面左侧放分类导航右侧是商品卡片列表。分类数据进入页面时全部加载点击某个分类时前端把分类 ID 作为参数传给 getProductList 方法后端返回对应分类的商品数据。商品卡片上方可以加一个排序区域点击“综合”“销量”“价格”三个维度切换排序条件并重新请求数据。分页用 Element UI 的 Pagination 组件实现切换页码时触发重新查询。商品详情页的核心是图片画廊和商品信息展示。图片支持切换大图展示还可以放大预览。商品信息包括价格、库存、销量、描述底部是“加入购物车”和“立即购买”两个按钮。点击“加入购物车”时如果用户未登录就跳转登录页已登录则调用后端接口携带商品 ID 和数量。系统要能处理“重复加入同一商品”的问题接口设计上检查到购物车中已有同商品时直接把数量累加。加入成功弹出提示并更新右上角购物车角标数量。购物车页面用表格展示商品信息每行左侧是勾选框中间是商品名和价格右侧是数量控制组件和删除按钮。表格底部展示商品总价。点击“去结算”按钮时先判断是否勾选了至少一件商品然后跳转到结算确认页。结算确认页展示商品明细、总价下面有收货地址列表用户可以选默认地址或新建地址最后点击“提交订单”按钮。提交成功后跳转到订单列表页并显示刚生成的订单编号。管理员端的商品管理页面用 Table 组件展示商品列表每条记录后面有“编辑”“上下架”“删除”操作按钮。点击“新增商品”或“编辑”弹出一个 Dialog 对话框里面是一个很长的表单包含分类选择、商品名称、主图上传、图片列表、价格、库存等字段。图片上传我用的 Element UI 的 Upload 组件上传时调用后端接口保存到服务器并返回 URL。表单校验用 Element UI 自带的 rules 规则点击提交时先触发校验再调用接口。5.4 前后端接口联调与数据格式约定联调阶段是项目中比较消耗耐心的环节。后端接口返回的结构统一是 { code, message, data }前端在响应拦截器里已经处理过 code所以页面直接使用 data 部分。比如分页查询接口返回的 data 是一个对象包含 records当前页数据列表和 total总记录数两个字段。前端拿到后直接给表格和分页组件赋值即可。联调时建议打开浏览器开发者工具的 Network 面板请求发出后可以查看 URL、请求参数和响应内容快速定位到底是前端参数传错了还是后端返回数据有误。6. 数据库初始化与环境配置指南6.1 数据库创建和数据初始化拿到项目后第一步是准备数据库环境。我用的是 MySQL 5.7 版本你也可以用 8.0 版本两者在 SQL 写法上差别不大。启动 MySQL 服务后打开命令行工具或 Navicat执行数据库创建脚本。脚本文件中通常包含了建库、建表以及测试数据插入等操作。CREATE DATABASE IF NOT EXISTS flower_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE flower_shop;创建数据库时我特意指定了 utf8mb4 字符集这是 MySQL 8.0 和 5.7 都支持的完整 UTF-8 实现可以正常存储生僻字和特殊符号。如果你使用默认的 utf8mb3一些生僻字比如某些表情符号会存储失败。建表 SQL 一般直接执行脚本就行不用手动每条命令单独执行除非你需要按自己的逻辑调整字段。导入完成后可以执行 SHOW TABLES 命令确认所有表都创建成功。测试数据方面分类表建议预置 5 到 10 个常见分类如玫瑰、百合、康乃馨、向日葵、绿植盆栽等。每个分类下再添加几个模拟商品。价格、库存、图片地址都填真实一些这样前端页面展示效果更好。用户表至少预置一个管理员账号和一个普通用户账号密码要存 BCrypt 加密后的密文不能存明文。注意管理员密码的密文必须和后端代码里的初始化逻辑一致不然登录不了。6.2 后端项目配置与启动数据库准备好后接下来配置后端项目。修改 application.yml 中数据库连接的用户名和密码部分改成你本机 MySQL 的账号密码。SpringBoot 项目还需要配置 MyBatis-Plus 的日志输出便于调试时看到实际执行的 SQL 语句mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl启动类直接运行 FlowerShopApplication 的 main 方法观察控制台输出。如果看到类似 “Started FlowerShopApplication in 5.42 seconds” 的日志就说明启动成功。然后打开浏览器访问 http://localhost:8080 测试后端接口是否正常。这一步如果访问不了先检查 8080 端口是否被占用再检查防火墙是否拦截了请求。6.3 前端项目启动与反向代理配置前端项目用 npm 或 yarn 安装依赖并启动npm install npm run serve默认启动地址是 http://localhost:8081。但前端调用后端接口时如果请求的 URL 是 http://localhost:8080就会遇到跨域问题。解决方案是在前端 vue.config.js 文件里配置 devServer 的反向代理devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }配置完成后前端请求 /api/product/list 实际上会被代理转发到后端的 /api/product/list 地址浏览器看到的请求是同源的跨域问题就解决了。注意后端接口的路径前缀也要是 /api这样代理规则才能匹配。如果项目后端没有统一加前缀也可以在后端配置 ServletContext 的 context-path 来统一加上。7. 常见问题与排查技巧7.1 数据库连接失败排查启动项目时报数据库连接错误是最常见的问题。控制台报错信息一般是 “Access denied for user ‘root’‘localhost’ (using password: YES)” 或者 “Communications link failure” 这类。前者说明密码错误或者用户被禁用了后者说明 MySQL 服务没启动或端口不对。排查步骤是先用本机命令行工具试一下 mysql -u root -p 能不能登录成功能登录就说明数据库没问题问题出在项目配置里再检查 application.yml 中 URL 和密码是否一致命令行登录失败就说明 MySQL 服务没启动去系统服务里把 MySQL 服务启动起来。7.2 跨域请求异常处理前后端分离项目中跨域问题几乎每个开发者都踩过。报错表现为浏览器控制台出现 CORS error或者请求显示为 failed。如果已经使用了上面的反向代理方案那基本不会出现跨域问题。如果你不想用代理还有另一种方案是在后端自定义一个 CorsFilter 配置类设置允许跨域的来源、方法、请求头等直接放行跨域请求。两种方案选一个就行不要同时配置不然反而可能出问题。7.3 中文乱码问题中文乱码主要出现在两个方面。一个是前端页面显示数据库中的中文时出现问号或乱码这基本是数据库字符集或连接参数的问题解决办法是检查建库语句是否指定了 utf8mb4以及 JDBC 连接 URL 末尾是否加了 characterEncodingutf-8 参数。另一个是前端把中文数据通过 JSON 传给后端时出现乱码解决办法是在 SpringBoot 的 application.yml 中配置服务器编码server: servlet: encoding: charset: UTF-8 force: true7.4 数据重复插入问题购物车应用中容易出现重复插入问题。比如用户疯狂点击“加入购物车”按钮或者连续发出多个请求可能造成同一个商品在购物车里有两条记录。解决办法有两个层面。第一个是在数据库层给购物车表在 (user_id, product_id) 上建联合唯一索引这是兜底防线第二个是在业务层每次加入购物车前先查询一下如果已存在就执行数量累加的更新操作而不是重复插入。两招都用上才能彻底避免问题。7.5 端口占用问题项目启动时报端口被占用常见于前一次运行没彻底关闭或电脑上其他服务占了相同端口。解决办法是找到占用进程并关闭它。Windows 下执行 netstat -ano | findstr 8080 查看哪个进程占用了 8080 端口然后根据 PID 在任务管理器中结束该进程macOS 下执行 lsof -i :8080 查进程号再用 kill -9 结束。如果是自己修改了端口配置确保前后端代码里引用的端口是一致的。8. 毕业设计答辩中的亮点提炼与经验总结这套花店销售系统项目做完以后如果只是把代码跑起来给老师看一眼那太浪费了。我更建议你把整个项目打磨成三个能加分的重点在答辩时重点展示。第一点是业务上的融合设计。花店销售不是一般的通用电商它有鲜明的行业特征——鲜花的时效性、配送的时效性、节假日的需求激增。如果你能在论文里往“季节性销售预测”“节日订单峰值的库存调配”这个方向延展哪怕只写一小节就能拉开你和其他同学的差距证明你思考过真实业务问题而不只是把教科书里的电商系统换个皮。第二点是技术上的安全性设计。密码加密存储、登录 token 鉴权、接口参数校验、逻辑删除防数据丢失、事务保证订单数据一致性、库存条件更新防超卖这些都是你能够在答辩时直接讲出“为什么这样做”的点技术含量比单纯的 CRUD 高出一个档次。第三点是数据分析功能。在本项目已有销售统计的基础上可以扩展出“销售 Top 10 商品排行”“分类销售占比饼图”“月度销售趋势柱状图”这些可视化统计页面。用 ECharts 在前端画图后端提供对应的统计接口即可。这个功能对老师来说非常直观看到一堆图表比看到一堆表单更有说服力。开发完成后我强烈建议你把自己的项目代码做一个整理按后端、前端、数据库脚本、论文文档分门别类放好然后在 README 里写清楚技术栈说明、环境要求、启动步骤、功能清单。无论是否把项目放到自己的简历作品集里这套完整规范都会让它在后续的展示中给人更专业的印象。同时我自己的习惯是把核心功能的实现思路写成简短笔记尤其是事务处理、鉴权、统计这三块的技术细节遇到问题时翻查起来效率很高。最后再分享一个深有体会的经验毕业设计的周期里前面 70% 的时间可能会花在环境搭建和基础功能上给你的感觉是进度条迟迟不动但只要你把用户登录、商品列表、购物车这些核心链路彻底理顺了剩下 30% 的功能开发速度会飞快。所以遇到环境配置或框架版本问题时不要内耗多花点时间一次性把环境稳定下来后面的开发体验会顺畅很多。本文还有配套的精品资源点击获取