基于SpringBoot+Vue的攀枝花鲜花销售系统毕设解析

每年到了毕业季，计算机相关专业的同学都在为一个东西头疼：毕业设计。选题、开题、搭建框架、写代码、写论文、准备答辩，一环扣一环。而电商类的系统因为业务逻辑完整、技术栈通用、展示效果好，一直是毕设选题里的热门方向。

今天这篇就围绕“基于SpringBoot的攀枝花市鲜花销售系统”这个毕业设计案例来聊。用的是Java + SpringBoot + Vue + MySQL这套非常主流的技术组合，主打的是区域化的鲜花零售电商场景。这套东西的价值在于：麻雀虽小五脏俱全，从前台购物到后台管货，从用户登录到订单流转，一个电商系统该有的核心环节它都有。不管你是正在找选题、已经动手在做、还是临近答辩想补细节，这篇内容都有参考价值。我会把项目整体怎么拆、数据库怎么设计、前后端各自怎么实现、论文怎么写、答辩怎么讲，以及实操中容易踩的坑一并说清楚。

1. 项目整体设计与技术选型

1.1 为什么选SpringBoot + Vue这套组合

毕设选型，有点像开餐厅选厨具——不用追求最贵的，但一定要选自己最熟的、能稳定出菜的那套。SpringBoot + Vue这套组合在近几年几乎是毕设标配，不是没道理的。

后端走SpringBoot，最直接的好处是“开箱即用”。以前用SSM（Spring + SpringMVC + MyBatis）搞一套项目，光是XML配置就能让人怀疑人生。SpringBoot通过自动配置把大部分繁琐的样板配置消化掉了，注解驱动、内嵌Tomcat、一键打包成Jar就能跑。对于毕设来说，能在短时间内把系统跑起来比什么都重要，你总不想把整个学期都耗在配置文件的泥潭里。

前端选Vue，核心优势是“组件化 + 响应式”。以鲜花销售系统为例，前台的商品卡片、购物车角标、订单状态标签，这些在Vue里都是一个一个组件，改起来非常干净。v-model和computed这种双向绑定机制，在处理搜索条件联动、购物车数量加减这种交互时，写代码的效率比操作DOM高太多了。

MySQL作为数据库没什么好争议的，成熟稳定、资料多，适合这种中小体量的业务系统。

这套组合还有一个隐性的好处：社区资料极其丰富。你在开发过程中遇到任何报错，比如跨域、JWT过期、分页查不出来，基本都能在搜索平台上找到现成的讨论帖。对于经验不算充足的同学来说，这大概率能救命。

1.2 项目功能模块的前台与后台拆分

电商系统的功能模块，切入点通常就是“面向谁”。我习惯把它拆成两个端：前端商城（面向买花的用户）和后台管理（面向运营人员）。

前台商城模块，核心是：

• 用户模块：注册、登录、个人信息维护、收货地址管理。登录我用的是JWT（JSON Web Token）做无状态认证，后面会细说。
• 商品模块：鲜花分类浏览、商品列表、按关键词搜索、商品详情展示，包括价格、库存、花语描述、图片轮播。
• 购物车模块：加入购物车、修改数量、勾选结算、删除失效商品。
• 订单模块：确认订单、选择收货地址、提交订单、在线支付模拟（毕竟毕设一般不接真实支付渠道）、订单状态查询、确认收货。
• 评价模块：对已完成的订单写评价，方便其他用户参考。

后台管理模块，核心是：

• 管理员登录验证。
• 商品管理：商品的增删改查、上下架、库存调整、图片上传。
• 分类管理：花材分类的维护，比如玫瑰、百合、康乃馨、绿植等。
• 订单管理：订单列表查看、订单状态流转处理（发货、完成、取消）。
• 用户管理：用户信息查看、账号禁用/启用。
• 轮播图/公告管理：给首页曝光位做维护。

这套模块划分基本覆盖了电商demo的完整链路。做的时候建议脑子里绷一根弦：每一个功能都不是独立的，是串成一条链的：注册登录之后才能下单，下单之后库存才会减，减完库存后台才能发货，发货之后用户才能确认收货并评价。把这条链路理清楚，答辩的时候你讲业务流程时自然就顺了。

1.3 攀枝花市本地化场景的价值所在

有些同学可能会问，为什么要限定“攀枝花市”？直接做一个通用版鲜花销售系统不行吗。这就要说到毕设评分里一个很关键的隐性指标：业务场景的真实性与完整性。

把系统定位为某个具体城市，带来的不只是标题上的差异化，更是业务逻辑上的“落地感”。比如：

• 花材本地特色：攀枝花本身气候温暖，是四川重要的花卉产地之一，本地市场对鲜切花、盆栽绿植的需求有自己的特点。你在商品分类里可以设置“本地基地直供”“热带绿植专区”等栏目。
• 配送范围的区域化：配送方式可以做成按区域计算——分东区、西区、仁和区等几个城区，不同区域的配送费和预计送达时间不同。这就比单纯写一个固定运费要更有业务深度。
• 区域促销逻辑：可以设计“攀枝花本地热销榜单”“节日鲜花预定”等模块，贴合实际经营场景。

从答辩角度来说，“为什么不做通用版”是一个很容易被问到的问题。这时候你就可以回答：限定攀枝花市是为了让系统更贴合实际的区域性鲜花零售业务。因为鲜花是短保商品，配送时效与区域强相关，不同城区的配送策略不同，这样设计能让订单、配送、库存之间的逻辑更加清晰。这一番话讲下来，评委对你的业务理解能力观感会明显不一样。

2. 数据库设计与核心模块拆解

2.1 数据表结构设计的核心思路

数据库设计对于电商毕设来说，是真正的地基工程。表建得烂，后面写代码寸步难行。

我建议你按照业务对象来拆表，拆到“用户”、“商品”、“分类”、“购物车”、“订单”、“订单明细”、“收货地址”、“评价”、“管理员”这几个实体就够了。不要贪多，但关键的关联关系必须建对。

以我的经验，核心表的字段设计大致是这样：

用户表（user）：主键ID、用户名、密码（BCrypt加密）、昵称、手机号、头像、注册时间、状态。

分类表（category）：分类ID、分类名称、父级ID（支持二级分类）、排序值、是否显示。鲜花分类经常有“玫瑰”“百合”这种大类，下面还可以有“红玫瑰”“白玫瑰”这种细分类，所以父级ID这个字段很重要。

商品表（product）：商品ID、分类ID（外键关联）、商品名称、商品描述（花语）、主图URL、详情图片（可以用逗号分隔存多张图）、价格、库存、销量、上架状态、创建时间。

购物车表（cart）：主键ID、用户ID、商品ID、加入数量、勾选状态。注意这里要加一个唯一约束，通常是（user_id, product_id），防止同一个用户把同一件商品插入两遍。

订单表（orders）：订单ID、订单编号（唯一，可用时间戳+随机数生成）、用户ID、总金额、配送地址快照、订单状态、支付方式、下单时间、支付时间、发货时间、完成时间。这里要敲个黑板：订单表一定要保存收货地址的“快照”，而不是去关联用户地址表。因为用户的收货地址以后可能会改，但订单发出时的地址不该跟着变。

订单明细表（order_item）：主键ID、订单ID、商品ID、购买数量、单价、小计。它的作用非常多，既有库存扣减的凭据，也有评价功能的数据来源，还能用来做销量统计。

地址表（address）：主键ID、用户ID、收货人、联系电话、所在区域、详细地址、是否默认。

评价表（comment）：主键ID、订单ID、商品ID、用户ID、评分、评价内容、回复内容、评价时间。

管理员表（admin）：主键ID、账号、密码、昵称。

这套表设计看起来常规，但有几处是经过实战验证的坑位避让：订单状态用int类型维护状态码（0待支付、1待发货、2待收货、3已完成、4已取消），是业界约定俗成的做法，可读性靠后端常量类来兜住，而不是靠数据库varchar存中文状态；价格字段用DECIMAL(10,2)而不是float/double，这个很关键，浮点数有精度损失问题，金额算错这种低级错误在答辩时极丢分，用DECIMAL才能保证小数精确。

2.2 数据库E-R关系怎么画才清晰

画E-R图是论文里必备的一环。很多人这一个图画得乱七八糟，关系箭头到处飞，答辩时被老师一问就短路。

画之前先想清楚实体间的关系：

• 用户与商品：多对多。一个用户能买多件商品，一件商品能被多个用户买。多对多关系建议通过订单明细表来拆解。
• 分类与商品：一对多。一个分类下有很多商品，一个商品只属于一个分类。
• 用户与订单：一对多。
• 订单与商品：通过订单明细表构成多对多。
• 用户与地址：一对多。
• 用户与评价：一对多，评价本身关联订单和商品。

E-R图绘制可以用Visio、ProcessOn或者其他在线画图工具。我的建议是，图里用矩形框表示实体，菱形表示关系，椭圆表示属性，这一套标准符号体系千万别自创。

一个整洁的E-R图，通常是一个主实体在中心（用户），订单和商品分成两翼，地址、评论在侧边做好关联。你把关系理得越清晰，代码层写MyBatis的关联查询时就越省事。

2.3 索引设计与通用字段的扩展

数据库设计时别只顾着建表，索引和通用字段一开始就要规划好。

需要建立索引的字段：用户表的用户名（唯一索引）、订单表的用户ID（查某用户订单列表的快路径）、订单表的订单编号（唯一索引，查询订单详情用）、商品表的分类ID（分类页列表用）、购物车表的用户ID。

通用扩展字段上，我的习惯是给核心业务表都加create_time和update_time两个时间字段。这两个字段的妙处在于：做列表排序时直接用create_time倒序，天然就是“最新商品在前”的效果；后台做数据统计时，按这两个字段做时间分组也方便。MySQL从8.0开始支持DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP，建表时直接写上省心省力，不用在代码里手动维护。

举个实际DDL片段帮助理解：

CREATE TABLE product ( id BIGINT AUTO_INCREMENT PRIMARY KEY, category_id BIGINT NOT NULL COMMENT '分类ID', name VARCHAR(100) NOT NULL COMMENT '商品名称', description TEXT COMMENT '花语/描述', main_image VARCHAR(255) COMMENT '主图URL', images TEXT COMMENT '详情图，逗号分隔', price DECIMAL(10,2) NOT NULL COMMENT '价格', stock INT NOT NULL DEFAULT 0 COMMENT '库存', sales INT NOT NULL DEFAULT 0 COMMENT '销量', status TINYINT NOT NULL DEFAULT 1 COMMENT '1上架 0下架', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_category (category_id), KEY idx_create_time (create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='鲜花商品表';

注意，商品描述用TEXT类型没问题，但主图路径这种字段用VARCHAR(255)就够。还有一点：MySQL建表建议默认utf8mb4字符集，为什么？因为utf8mb4才是完整支持emoji和生僻字的字符集，用户的商品评价里可真有可能出现emoji表情，用utf8会报错。

3. 前后端实现的关键细节与实战思路

3.1 后端分层的标准姿势

后端代码如果全部堆在Controller里，前期写起来确实快，后期会让你痛不欲生。做电商这类业务逻辑密集的系统，分层要严格走标准四层：Controller → Service → Mapper → Database。

Controller层职责单一：接收前端请求参数、调用Service、封装返回结果。不要在里面写任何业务判断，连库存校验这种看似简单的都不要放。

Service层是业务逻辑的核心。下单时扣库存、订单状态流转校验、购物车“勾选结算后再移除”的联动，都在这层处理。写Service的时候多体会一下“事务”的概念：下单要同时完成“插入订单主表 + 插入订单明细 + 扣减库存 + 清空对应购物车”，这四步要么全部成功，要么全部失败回滚，否则就会出现“订单生成了但库存没减”的严重数据不一致。用@Transactional注解把四步包起来，Spring的声明式事务就帮你解决了。

Mapper层就是数据访问，基本是单表操作。复杂的多表关联查询（比如订单列表要展示商品信息）就写一条自定义SQL在XML里完成，避免多次查询在Java代码里手动组装带来的性能和代码复杂度问题。

返回给前端的统一格式，很多人第一次做会忽略。我建议定义一个统一的返回体，包含三个字段：code（状态码）、message（提示信息）、data（业务数据）。不管成功失败，前端拿到的永远是这种结构。这样在axios的响应拦截器里统一判断code，一次性解决后端所有接口的异常处理。

JWT登录这块也值得展开。我用的方案是：用户登录成功后，后端生成一个token返回给前端，前端存在localStorage里，之后每次请求在请求头里带上Authorization: Bearer token。后端写一个拦截器，放行登录注册接口，其他接口都校验token有效性。这样做的好处是可以支撑前后端分离部署的架构，后端无状态，随便横向扩容。

有一个细节：拦截器里校验token时，不要在拦截器里直接查数据库判断用户是否存在，而是解析token拿到用户ID，在需要的时候再按需查询。一次性把“无效token”和“用户不存在”两种情况都在拦截器处理了，逻辑会更干净。

3.2 前端路由与状态管理

Vue这边，我通常用Vue CLI构建工程，配Vue Router做路由管理，配Vuex或Pinia做状态管理。

路由设计上，前台商城和后台管理建议完全分开。前台一级路由：首页、商品列表页、商品详情页、购物车页、订单结算页、订单列表页（需要登录后才能访问）。后台一级路由：仪表盘、商品管理、分类管理、订单管理、用户管理。

拦截器的思路是：在路由的meta字段里标记requiresAuth，在全局前置守卫里判断用户是否登录。没登录但访问了需要登录的路由，就跳转到登录页并带上redirect参数，登录后跳回原页面，这个体验细节加上去之后，答辩时是可以主动提一句的亮点。

状态管理里，全局要存的东西包括：用户信息、购物车数量、管理员信息。购物车数量这个变量，因为会被导航栏+购物车页面多处引用，很适合放在全局状态里维护，改一次全局联动。

3.3 商品列表的搜索、分页与筛选联动

商品列表页是商城系统里交互逻辑最密集的单页，很能体现一个开发者的细节把控力。

推荐的实现方案是：

• 搜索框输入关键词。
• 分类导航点击切换分类。
• 价格排序、销量排序切换。
• 列表数据由后端分页返回。

前端需要维护一个查询条件对象，通常包含这些字段：keyword、categoryId、sortField、sortOrder、pageNum、pageSize。任何筛选条件的变更，都重置页码为1然后调用查询接口。这样用户点分类、改排序、搜关键字，所有的行为都收敛到同一个queryProducts方法里，代码不会散。

后端对应的查询接口，用MyBatis动态SQL来拼条件，核心写法大致是这样：

<select id="selectPage" resultType="com.example.entity.Product"> SELECT * FROM product <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> AND status = 1 </where> ORDER BY ${sortField} ${sortOrder} </select>

这里有个安全提醒：sortField和sortOrder如果要支持前端传值，务必在后端做白名单校验，只允许白名单内的字段和升降序值。否则直接把前端参数拼进ORDER BY里，存在SQL注入风险。毕设里虽然不会真有人来攻击，但这种漏洞要是被答辩老师指出来，印象分会很难看。

分页插件用PageHelper就好，一行代码搞定分页查询，十分省事。但要注意，PageHelper有它的分页原理，基于拦截器在第一次查询时自动拼接LIMIT语句。使用时要确保库的分页API不被重复执行，否则前端拿到的总条数会变奇怪。

3.4 购物车与订单的状态流核心逻辑

购物车里有一个初学者容易出问题的点：结算时传什么数据。

我见过有些同学把整个购物车对象传给后端，后端拿着这个对象直接下单。这存在隐患：前端传过来的价格是不可信的，用户可以篡改价格，按1分钱下单。

正确的做法是：前端只传“选中的购物车条目ID列表”和“地址ID”。后端收到之后，通过ID去数据库查出真实的商品、单价、库存，重新计算总金额，再做扣库存、生成订单等后续操作。这样既保证了安全性，也把业务逻辑收敛在后端，前端只负责收集用户的意图。

订单状态流转这块，我用状态图来理解会非常清晰。可以定义五个状态：

后端在更新订单状态时，一定要校验当前状态与目标状态是否构成合法流转。例如“待支付”可以直接跳“已取消”，“待发货”则不能直接跳“已完成”，必须经过“待收货”。如果你在后端接口里不校验状态流，任何人都可以通过调接口把订单状态改成任意值，这就是严重的逻辑漏洞。

库存扣减要放在提交订单（待支付状态下）还是支付成功后？实践上，行业通用做法是：提交订单时锁定库存（库存减一），支付超时取消订单后释放库存回补。如果你选择“支付成功后才扣库存”，就会面临一种尴尬情况：用户下单锁住了库存，但他不支付，另一个想买的人却看到缺货。毕设做到“提交订单扣库存 + 取消订单释放库存”这个水平，已经明显超出平均值了。

关于订单的超时自动取消，两个方向可以选：

• 定时任务：例如Spring Boot的@Scheduled注解，每分钟扫一次，把创建时间超过30分钟且处于待支付状态的订单统一改成已取消。这个方案最简单，能跑，只是存在一定的延迟。
• 延迟队列：用RabbitMQ或Redisson的延迟队列来做精确控制。复杂度高不少，但如果你的项目偏分布式方向，可以在论文里作为扩展点来写。

3.5 文件上传不要再把图片存数据库了

商品图片上传，是实操中出现率极高的配置坑。

很多初学者图省事，把图片转成Base64直接存到MySQL的TEXT字段里。确实能跑，但后果是数据库体积迅速膨胀，查询性能掉得很快。图片这种非结构化数据，正确做法是存上传后的文件路径或者URL。

实现方案有两种：

方案A：上传到本地磁盘的指定目录，然后把这个文件映射成一个静态资源URL访问。需要在SpringBoot中配置资源映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

好处是实现简单，不需要引入额外中间件。缺点是项目换一台机器部署，图片文件夹不跟着走，图片会全部失效。对毕设来说，这个缺点可以接受，但注意你的upload目录不要放在target编译目录里，要放到一个磁盘上的固定目录，否则每次重新打包后图片就全没了。这是我当年踩过最痛的坑。

方案B：引入云存储。如果自己开通云服务存储，桶配置成公开读，上传成功后拿到一个公网URL存到数据库里。效果确实好，但有独立部署成本，每年还要续费。按毕设项目的规模来看，方案A就够了，云存储可以作为论文里的“系统进一步优化方向”来提及，既不增加成本，又能体现你了解业界方案。

前端图片上传组件的交互流程一般为：用户选择文件上传到后端存储，后端返回一个URL，前端把这个URL作为商品的图片地址保存到表单里，提交时随商品信息一起传给后端。

3.6 联调阶段跨域问题与接口规范

前后端分离开发，跨域问题是100%会遇到的，不用慌张，它的解决方案已经非常成熟。

前端开发服务器端口和后端Tomcat端口不一致，比如后端在8080端口，前端在8081端口。前端的浏览器请求会被同源策略拦下。

解决方式通常有两种：

方式一：后端添加CORS跨域配置，允许指定来源访问。这是最简单的做法，全局配置一个过滤器即可。

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

注意，在较新的Spring Boot版本中，addAllowedOrigin("*")可能会有兼容问题，官方推荐使用addAllowedOriginPattern("\*")。

方式二：前端脚手架devServer里配置proxy代理。Vue CLI的vue.config.js里这样写：

module.exports = { devServer: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

但我个人更推荐方式一，原因很简单：你最终打包后是后端把前端dist文件夹塞进resources/static下，让SpringBoot直接托管静态资源，也就是单端口部署。这种方式下没有跨域问题。但在本地开发时前后端分离，你依然需要CORS来支撑联调。所以本质上是CORS几乎必然要用到，直接配置CORS是成本最低的方案。

再补充一个项目部署阶段的核心技巧——单端口部署：在前端工程执行npm run build生成dist目录后，把dist整个文件夹复制到SpringBoot项目的src/main/resources/static目录下，然后打成jar包，只需要启动这一个jar包，用户访问同一个端口就能看到完整网站。这对毕业设计的最终演示来说最稳妥，不需要你现场配置Nginx反向代理，少一堆幺蛾子。

4. 核心业务模块的操作流程与展示要点

4.1 从注册登录到下单支付的完整演示路径

答辩现场演示环节，是评委评分的重要参考点。我强烈建议你提前规划好一套“演示主线”，把系统最有含金量的功能串成一条有头有尾的完整流程。

我经常建议的演示主线是：

1. 打开首页，展示轮播图、热销专区，快速体现系统的美观程度。
2. 点击某个商品进入详情页，介绍花语、价格、库存信息。
3. 注册/登录。建议提前准备好一个测试账号，现场登录，少一点不确定性。
4. 搜索一个关键词，展示搜索结果列表，体现搜索功能。
5. 把商品加入购物车，到购物车页面调整数量，勾选结算。
6. 进入结算页，选择收货地址，提交订单。
7. 支付方式可以用模拟支付，点击后直接置为已支付。
8. 切换到后台管理，用管理员账号登录，展示订单列表。
9. 管理员点击发货，订单状态变为待收货。
10. 回到前台，用户点击确认收货，再进入订单详情页给商品写评价。

最后可以再给一个高光操作：把商品库存改成0，回到前台展示“下架/缺货”状态。这一个动作可以非常直观地体现前后台数据联动能力，比在代码里翻数据库表数据要高级很多。

4.2 管理端的数据可视化与统计维度

后台管理不要只做增删改查，一个统计信息的仪表盘会让整个系统档次和专业感上升一个台阶。

用前端图表库（比如ECharts），可以轻松展示：

• 近7日销售趋势图（折线图）。统计维度是“订单创建时间”，数据从订单表按天分组查询。
• 商品分类销量占比（饼图）。关联商品表和订单明细表，按分类汇总销量。
• 热门商品Top5（横向柱状图）。按商品销量排序，取前五。
• 待发货订单数量（数字卡片）。一个count查询就能搞定。

这些统计图表从实现复杂度上并不高，但对系统完整度的加分非常明显。评委打开后台，看到的不只是一堆表格，而是有一些“驾驶舱”的感觉，整个项目的完成度评价会在心底自动升一档。

统计数据的SQL也不难写，以近7日销售额为例，可以按日期分组统计已支付订单的金额总和：

SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS day, SUM(total_amount) AS total FROM orders WHERE order_status IN (1, 2, 3) AND create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY day ORDER BY day;

前端拿到这个数据直接用ECharts的折线图接口渲染，过程很顺滑。

4.3 论文结构怎么组织才符合评审口味

论文是毕业设计里和代码分庭抗礼的另一大板块。代码写得再好，论文写成一团乱麻，也一样可能被挂。我的经验是，论文结构严格走如下章节排布：

第一章 绪论。写课题背景与意义、国内外研究现状、主要研究内容。这里的“国内外研究现状”不要乱抄，也别直接搬整段，尽量用自己的话转述，效果更好，查重也能过一点。

第二章 相关技术介绍。SpringBoot、Vue、MySQL分别介绍，以及用到的其他辅助工具。这一章不用写太深，但关键特性要准确。

第三章 需求分析。系统目标、功能性需求、非功能性需求、用例分析。用例图建议画3-4张：用户用例、管理员用例。

第四章 系统设计。总体架构图、技术架构图、功能模块图、数据库表设计、E-R图。这是论文核心章节，内容要占整篇论文的百分之三四十以上。

第五章 系统实现。按功能模块展开，每个模块放核心代码片段加页面截图。代码不要整段大篇幅贴，只放关键方法、核心逻辑片段，配合文字说明。

第六章 系统测试。功能测试用例表、测试结果、性能测试简单说明。测试用例表要写清楚用例编号、操作步骤、预期结果、实际结果、是否通过。

第七章 总结与展望。写完成了什么工作、还存在哪些不足、以后可以优化哪些方向。不要只写“我们实现了所有功能”，也不要过度自贬，诚恳地写两三条真实的扩展方向就足够。

4.4 答辩讲解的核心主线与高频问题准备

答辩时，评委最讨厌什么？最讨厌学生对着PPT念定义，念概念，念代码。评委最想看的是，你对自己做的系统是否真的理解。

把讲解主线围绕“技术实现的亮点 + 业务逻辑的闭环”来讲述，讲的时候有一条不错的顺序可以参考：

• 先用一句话介绍项目定位：这是一个面向攀枝花市本地鲜花零售场景的电商系统，实现前台购物与后台管理一体化。
• 再讲核心功能，快速带过主要功能模块。
• 重点讲解三个技术亮点。比如：JWT无状态登录认证、订单状态机与数据一致性保障、基于动态SQL的分页多条件搜索。
• 然后展示实现效果，把演示主线完整走一遍。

答辩现场高频问题我列一个清单，每条都提前准备一个完整的回答内容：

Q1：为什么选择SpringBoot而不是SSH/SSM？答：SpringBoot简化了配置，内嵌服务器，方便快速构建和部署，同时生态成熟，更适合敏捷开发场景。

Q2：如何保证商品库存和订单数据的一致性？答：下单操作使用事务管理，扣库存和生成订单在同一事务中执行，任何一个环节异常都会回滚。线程安全方面可以通过数据库乐观锁机制补充说明。

Q3：如果你的系统有100万用户，哪些地方会成为瓶颈？答：数据库查询压力会成倍增长，需要增加缓存层；图片等静态资源需要迁到云存储和CDN；单机Tomcat的并发连接数会达到上限，需要考虑集群部署。

Q4：这个系统还有什么不足？答：目前的支付是模拟支付，没有接入真实第三方支付渠道；订单超时取消依赖定时任务，时效精度不够；如果后续要扩展，可以把这些作为升级方向。

Q5：JWT和Session有什么区别？答：Session是服务端保存会话，JWT是无状态的，服务端不保存，每次请求通过签名验证即可，更适合前后端分离的架构。

这些问题提前准备过，答辩时心里就稳。记住，答不上的东西不要强行编，承认是自己的盲区，然后补充说明你的改进计划，这种态度反而更容易获得认可。

5. 常见问题与避坑经验

5.1 开发环境与工具链的版本匹配

这套系统的开发环境，最稳妥的搭配是：

• JDK 1.8或JDK 11，Spring Boot 2.x（推荐2.7.x，资料最多）。
• Node.js 14或16，Vue CLI 4或5。
• MySQL 5.7或8.0。
• IDE用IDEA社区版或专业版，前端可以用VS Code。

为什么我特意提醒版本匹配？因为很多同学在这里栽过跟头。比如你本机装的是JDK 17，但Spring Boot 2.6不带适配会有各种奇怪的反射异常；你装的是Node.js 20，Vue CLI 4可能装都装不上依赖，报一堆因OpenSSL导致的错误。如果之前没接触过这套技术栈，我为你好，还是建议一步到位复制上面这套经典版本组合。

还有一个容易忽略的问题：IDEA里Maven下载依赖默认走中央仓库，国内网络下经常拉不动。建议配置阿里云Maven镜像，体验完全不同。

5.2 开发期容易卡住的三类Bug

第一类是MyBatis的Mapper绑定问题。报错信息通常是Invalid bound statement (not found)。原因是接口和XML映射没有正确绑定。排查三步走：检查XML文件里namespace写的是不是Mapper接口的全限定名；检查接口方法名与XML里的statement id是否一致；检查application.yml里是否有mapper-locations配置指向XML目录。定位到问题后修复通常非常快。

第二类是前端接口401或者跨域问题。前端请求一直报401，先看控制台请求带着没有token；请求发出去了但无响应或提示跨域，优先看后端有没有CORS配置，以及前端请求的baseURL是否写对。

第三类是启动后端口被占用。本地端口报错时，在终端执行netstat -ano | findstr 8080查端口占用，再用taskkill /PID 进程号 /F清理。但更好的方案是直接在application.yml里把端口改掉：

server: port: 8080

顺带提醒一句，在application.yml里配置数据库连接串时，如果你的MySQL密码里带了特殊字符，比如@、#、:, 一定要做urlencode编码，否则解析会错乱，报连接失败或密码错误。

5.3 让系统看起来完成度更高的几个细节

有些很小的工作，能明显提升系统观感：

• 幂等控制：支付回调或重复提交订单时做一个幂等判断，防止重复提交生成两条订单。可以在后端用token机制，通常叫防重复提交令牌：进入结算页时后端生成一个唯一token下发给前端，提交订单时校验token有效性并删除，第二次提交时token已失效则拒绝。
• 友好的空状态和加载态：商品列表为空时展示“暂无商品”插画，加载时展示loading动画，这些是前端体验感的关键。
• 统一的日期时间格式：后端返回给前端的LocalDateTime，如果不做统一格式化，前端会拿到一串很难看的数组或者带T的字符串。在配置里设置全局jackson时间格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

• 对非法参数做后端校验：使用JSR-303的@Valid和@NotBlank等注解对请求参数做基础校验，避免前端绕过限制传空数据，导致数据库写入脏数据。

5.4 我踩过且希望你绕开的坑

最后把我个人实操中踩过的一些坑、总结的经验分享给你。

关于代码量：不要迷信“代码写得多=项目做得好”。评审看的是业务闭环能否跑通，核心逻辑是否有深度。一个干净清晰的核心链路，比堆一大堆冗余功能有用得多。

关于时间规划：很多同学喜欢先学框架再动手做，导致真正留给开发的时间不够。我的建议是按阶段推进：第一周完成需求分析和数据库设计，第二三周完成后端接口，第四五周完成前端页面与联调，第六周写论文和准备答辩。留出缓冲时间，前后端联调永远比你想象中更耗时间。

关于备份：每完成一个阶段，建议把项目压缩打包到网盘或者仓库做一次备份。不要问我为什么提醒，等你某天不小心把整个项目目录覆盖了却没备份，你会理解的。

关于启动演示的稳定性：答辩前最后三天，不要大幅改动代码。我见过不少临到答辩还在连夜加功能，结果答辩当天启动都启动不了的情况。毕业设计的评分维度里，一个稳定能跑的系统，比一个炸裂但跑不起来的系统重要得多。把演示主线上所有环节的功能，在正式答辩前完整多走几遍，闭着眼睛都能流畅操作，这比新增任何花哨功能都更有价值。

这套基于SpringBoot的鲜花销售系统，认真做完一遍，你收获的不只是一份毕业设计。你会真正理解一个前后端分离的电商项目是怎么从零长成完整形态的，包括账号体系、购物流程、库存扣减、订单流转、后台管理这些业务模块之间的逻辑关联。这套经验，要比学分本身值钱得多。