SpringBoot+Vue网上购物系统毕设实战：从零搭建到答辩全记录

刚拿到这个毕设题目的时候，我第一反应是“又是网上购物系统”。但等我把整个项目从零搭完，发现这个看起来烂大街的题目，其实恰恰是最能检验Web开发综合能力的“试金石”。一个基于SpringBoot与Vue.js的在线商城交易平台，不是简单的增删改查，它涵盖了数据建模、接口设计、前端交互、权限控制、订单状态流转、支付对接等多个环节，几乎把JavaWeb开发的主干知识全部串了一遍。

这篇文章不是从教科书角度讲原理，而是把我实际做完这套系统的思路、步骤和踩坑记录写出来。不管你基础一般还是已经入门，只要打算用SpringBoot+Vue做毕设或项目实战，这篇内容都可以直接参考。

1. 为什么“网上购物系统”能成为毕设常青树

1.1 一个题目覆盖完整Web开发链路

很多人觉得购物系统太老套，想选个“智能推荐”“大数据分析”之类的题目来显示技术含量，结果往往在开题之后就卡住了。我的看法是：毕设评分最看重三样东西——选题价值、技术难度、工作量，而网上购物系统这三样都能占住，关键看你怎么做。

从开发链路看，商城项目要求你完成数据建模，用户、商品、订单、购物车这些实体之间有明确的主外键关联；要求你设计RESTful接口，前后端通过JSON交互；要求你处理前端动态渲染，Vue组件、路由、状态管理全都要用上；还要求你搞定权限控制，普通用户和管理员是不同的角色；更别说订单状态机、支付回调这些东西了，每一块单独拿出来都能当成一次小型面试题。

我做这套系统时的真实感受是：它不像纯管理系统的CRUD那样枯燥，也不像算法类项目那样脱离实际业务。商城每一个功能都对应真实电商场景，做起来有画面感。能力一般的同学可以做简化版，单商家、纯CRUD、页面直接套模板；能力强的同学可以做多级商品分类、SKU库存扣减、JWT鉴权、分布式会话、管理端数据图表。同一套题，深浅自由，这也是它长盛不衰的根本原因。

1.2 难度分层与适合人群

我接触过的同学里，做这个题目的无非三种情况。

第一种是后端还没完全吃透，主要想通过项目把SpringBoot的流程走通。这种情况建议把重点放在接口代码质量和数据库设计上，页面可以少写一点，用简化版Vue页面展示核心功能就够。

第二种是前后端都想练，目标是一份完整的前后端分离项目经验。这种情况最适合按本文的完整方案来做：SpringBoot提供API，Vue独立部署，联调时自己处理跨域、Token、文件上传。

第三种是想拿高分、冲优秀毕设。这种情况不能只做基础功能，至少要有订单事务一致性处理、库存防超卖方案、JWT拦截器、以及一个有说服力的亮点模块，比如数据可视化报表或者基于Redis的热点商品缓存。

很多人问这个题目是不是太“大众化”了，我的回答是：题目大众化不可怕，实现深度大众化才可怕。同一个题目，有人做到60分，有人做到90分，评阅老师一眼就能分辨出来。

2. 技术路线权衡：从JSP到SpringBoot+Vue的取舍

2.1 为什么放弃传统SSM+JSP

前几年JavaWeb毕设的主流配置是Spring + SpringMVC + MyBatis，页面用JSP。学校教材更新慢，很多实验室项目还在用这种方式。但说句实在话，现在出去找工作，或者看开源社区的热门项目，已经很少有人再从JSP写页面了。

JSP的痛点在于前后端耦合太严重。Java代码和HTML标签混在一起，改个页面样式要重启服务，接口和页面根本没法独立调试。SpringBoot解决了后端配置繁琐的问题，把传统SSM的三层XML配置压缩成少量注解和自动配置，内嵌Tomcat让项目一键启动。这不是要抛弃SpringMVC的思想，反而SpringBoot底层就是SpringMVC那一套，学校教的内容没有浪费。

对于毕设来说，还有一个很现实的考量：搭环境的时间越少，留给业务实现的时间越多。SpringBoot + Vue这个组合能让前后端开发完全并行，我当时就是先和后端同学约定好接口格式，两个人同时开工，联调阶段反而比传统方式更顺利。

2.2 前后端分离到底带来了什么

有人觉得前后端分离只是个时髦概念，放到毕设项目里意义不大。实际上它的价值非常具体。

第一，页面不再依赖后端模板引擎渲染，前端是一个独立工程，用Vite启动后浏览器实时刷新，开发体验比JSP不知道舒服多少。第二，后端接口可以单独用Postman测试，不需要页面配合，出现问题时能快速定位是接口问题还是页面问题。第三，管理端和用户端虽然是两套界面，但Vue组件化之后，很多公共组件可以复用，比如商品卡片、分页组件、弹窗确认框。

审阅老师看项目演示的时候，一般会要求启动一个后端服务和一个前端服务，看到前后端分离的工程结构，本身就是一个印象分。

2.3 技术栈清单与选型理由

下面是我实际使用的技术栈清单，每一项的选择都有明确理由。

这里有一个实际注意事项：如果学校硬性要求使用SSM框架，也不要慌，你可以用SpringBoot的底层能力去兼容SpringMVC的编程模型，只是在开题报告里把技术路线描述成“基于Spring生态的JavaWeb方案”，答辩时重点讲清Controller、Service、Mapper的分层逻辑，基本都能过关。

3. 商城系统的核心模块拆解与数据库建模

3.1 用户端功能模块的边界划分

前台用户端并不是模块越多越好，而是要把每个模块的边界理清楚。

我最终保留的用户端模块是这些：注册登录、首页商品展示、商品分类筛选与搜索、商品详情、购物车、确认订单页、订单列表与订单详情、取消订单与确认收货、个人中心地址管理。听起来很常规，但每一个模块拆开都有细节。比如商品详情页要展示图片轮播、价格、库存、规格参数；购物车要支持修改数量、勾选结算、删除条目；确认订单页要选择收货地址、展示商品清单、计算总金额。

如果时间紧张，模块优先级应该这样排：商品浏览（必须完整，这是门面）→ 下单主链路（注册登录、购物车、订单，必须打通）→ 个人中心（地址管理、订单操作）→ 辅助功能（搜索、分类筛选）。先把主干跑通，再考虑锦上添花。

3.2 管理端功能模块的优先级排序

管理端是很多人容易轻视的部分，但老师演示时第一件事往往就是打开后台，看你能不能添加商品、修改价格、处理订单。

管理端我建议按顺序完成四块功能。商品管理是核心中的核心，包括商品维护、上下架、库存修改，这些直接支撑用户端展示；订单管理紧随其后，包括订单列表、查看详情、发货操作、取消订单；分类管理相对简单，但必须做，否则商品无处归类；用户管理只需要做到分页列表和状态禁用即可，不要过度设计。

如果还有精力，可以在后台加一个简单的数据统计页面，统计商品数量、用户数量、订单总量、销售额总和。这个页面在答辩时特别出彩，因为它让系统看起来像一个完整的产品，而不是一堆功能的拼凑。

3.3 数据库建模：最容易被卡住的关键点

数据表设计决定了项目能走多远。我第一版表结构就是随手建的，结果做到一半频繁加字段，差点推倒重来。后来我按下面的核心表重新建模，一次到位。

核心表包括：用户表（user）、商品分类表（category）、商品表（product）、购物车条目表（cart_item）、订单主表（orders）、订单明细表（order_item）、收货地址表（address）、管理员表（admin）。

-- 订单主表 CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL COMMENT '订单编号', user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL COMMENT '订单总金额', status TINYINT NOT NULL COMMENT '0待付款 1已付款 2已发货 3已完成 4已取消', receiver_name VARCHAR(50) NOT NULL, receiver_phone VARCHAR(20) NOT NULL, receiver_address VARCHAR(200) NOT NULL, create_time DATETIME NOT NULL, pay_time DATETIME, update_time DATETIME ); -- 订单明细表 CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, product_id BIGINT NOT NULL, product_name VARCHAR(100) NOT NULL COMMENT '商品快照名称', product_image VARCHAR(255), price DECIMAL(10,2) NOT NULL COMMENT '成交单价', quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL, KEY idx_order_id (order_id) );

为什么要拆成订单主表和订单明细表？因为一个订单对应多个商品，每个商品的单价、数量、小计必须单独记录。这里有个很容易忽略的细节：订单明细里的商品名称和价格是“快照”，不是外键关联实时商品表。如果商品后来改了名字或改了价格，历史订单里的记录也必须保持不变，这就是快照字段存在的意义。

金额字段必须用DECIMAL(10,2)，Java实体里用BigDecimal，绝不能使用double或float。用double存钱，累计几笔之后就会出现0.0000004这种精度问题，这在订单系统里是不可接受的。

商品表一定要留逻辑删除字段deleted，不要物理删除。因为订单表可能还引用着这个商品ID，一旦物理删除，关联查询就断了。逻辑删除的做法是加一个TINYINT字段，0正常1已删除，查询时统一过滤。

4. 从零搭建的完整实操记录

4.1 后端工程初始化与代码组织

创建SpringBoot项目时，建议直接使用Spring Initializr。JDK选8或11都可以，依赖选Spring Web、Lombok、Validation，然后手动引入MyBatis-Plus和MySQL驱动。

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>

application.yml里的核心配置要写清楚数据源、MyBatis-Plus的驼峰映射和日志输出。

spring: datasource: url: jdbc:mysql://localhost:3306/shop?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

包结构我推荐这样组织：controller、service、mapper、entity、dto、config、common。controller只负责接收参数和返回结果，业务逻辑全放service，mapper只写数据库操作。这个分层能在答辩时直接展示“高内聚低耦合”的工程思想。

一开始就要写统一返回结果类R和全局异常处理器，不然后面几十个接口会写出一堆重复代码。

@Data public class R<T> { private Integer code; private String msg; private T data; public static <T> R<T> success(T data) { R<T> r = new R<>(); r.setCode(200); r.setMsg("success"); r.setData(data); return r; } public static <T> R<T> fail(Integer code, String msg) { R<T> r = new R<>(); r.setCode(code); r.setMsg(msg); return r; } }

全局异常处理的思路是统一捕获业务异常和未知异常，避免把堆栈信息直接暴露给前端。

4.2 前端工程初始化与路由设计

前端我选择Vue3 + Vite + Element Plus。创建工程之后，先安装依赖，然后规划路由结构。我的做法是把用户端和管理端拆成两套布局，通过路由前缀区分。

用户端路由长这样：

const routes = [ { path: '/login', component: Login }, { path: '/', component: Layout, redirect: '/home', children: [ { path: 'home', component: Home }, { path: 'cart', component: Cart, meta: { requiresAuth: true } }, { path: 'orders', component: OrderList, meta: { requiresAuth: true } }, { path: 'product/:id', component: ProductDetail } ] } ];

管理端单独设一块区域，路径以/admin开头，并且路由守卫要求管理员角色。前端路由守卫只负责用户体验，真正的权限校验必须在后端完成，这个意识要建立起来。

Axios封装是我强烈建议认真做的一步。给axios实例设置baseURL为/api，请求拦截器从localStorage取Token并放进请求头，响应拦截器统一处理业务码。这样所有页面调用接口时不用重复写Token逻辑，代码会清爽很多。

service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res; } if (res.code === 401) { localStorage.removeItem('token'); router.push('/login'); } return Promise.reject(new Error(res.msg)); }, error => Promise.reject(error) );

4.3 前后端联调：跨域、Token与图片路径

前后端分离项目里，联调阶段最容易出问题的就是跨域和Token传递。

开发环境跨域，我推荐用Vite的proxy代理，而不是在后端开CORS。配置vite.config.js：

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

前端所有请求都走/api前缀，Vite在开发时把它转发到后端8080端口，浏览器看到的始终是同源请求，跨域问题就绕开了。

Token传递要注意请求头的命名一致。登录成功后后端返回token，前端存到localStorage，之后每次请求在拦截器里带上。后端用一个拦截器校验请求头里的token，解析出用户ID和角色。这里有一个细节：拦截器是Spring MVC层面的实现，比过滤器更合适，因为它可以注入Service去查数据库，而过滤器拿不到Spring容器管理的Bean。

文件上传路径是个容易翻车的细节。商品图片上传后如果直接存到项目运行目录，重新部署可能丢失。建议把上传目录放到项目外部的固定路径，然后通过后端配置虚拟路径映射对外暴露访问地址。

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceLocations("file:D:/shop-uploads/"); } }

这样前端图片地址可以写成window.location.origin + '/uploads/xxx.jpg'，无论开发还是部署都一样。

5. 毕设级项目必须避开的坑

5.1 功能堆砌：先主链路后亮点

第一个坑是功能规划失控。商城能加的东西太多了，秒杀、优惠券、积分、推荐算法，每个听起来都能当亮点。但毕设周期有限，功能每多一个，开发和调试成本就翻一倍。我见过有同学一口气规划了十几个模块，结果到答辩前一周购物车还是坏的。

我建议把项目切分成“必须完成的主链路”和“有余力才做的亮点区”。主链路是：注册登录 → 浏览商品 → 加入购物车 → 下单 → 支付 → 管理端发货 → 确认收货。这条链路里任何一个环节断了，系统都是不能演示的。先把主链路打磨到稳定无bug，再考虑秒杀、报表这类加分项，顺序不能颠倒。

5.2 金额精度：用double算账就是给自己埋雷

金钱计算是电商系统最容易出bug的地方。如果金额字段在Java里用double存，数据库用FLOAT存，结算时加减乘除会出现很诡异的精度问题，比如订单金额总和变成了199.9999999。这个问题不是玄学，是二进制浮点表示的天生缺陷。

Java侧必须统一使用BigDecimal，数据库侧金额字段统一DECIMAL(10,2)，前端传递金额参数时，后端一律用字符串接收再转BigDecimal。计算总价时用BigDecimal的add和multiply方法，不要用原生运算符号。这个规则从建表第一天就要执行，不要等出了问题再改。

5.3 订单事务：多表操作不能掉以轻心

下单这个操作涉及多张表：插入订单主表、插入订单明细表、扣减商品库存、清空购物车。任何一个步骤失败，前面的操作就要撤销，否则就会出现“订单没生成但库存被扣了”或者“库存扣了但订单不存在”的脏数据。

解决思路就是给下单方法加@Transactional事务注解，让这四步操作在同一个事务里，要么全部成功，要么全部回滚。

@Transactional(rollbackFor = Exception.class) public Long createOrder(OrderCreateDTO dto) { // 1. 生成订单主表记录 Orders order = buildOrder(dto); ordersMapper.insert(order); // 2. 批量插入订单明细 for (OrderItemDTO item : dto.getItems()) { orderItemMapper.insert(buildItem(order.getId(), item)); } // 3. 扣减库存 stockMapper.deductStock(item.getProductId(), item.getQuantity()); // 4. 清空购物车 cartMapper.deleteByUserId(dto.getUserId()); return order.getId(); }

但这里有几个事务失效的经典场景必须提醒：同类内部方法调用会绕过Spring的代理，导致事务注解不生效，所以事务方法必须从外部入口调用；异常如果被try-catch吃掉，事务也无法回滚，所以catch之后要抛出RuntimeException；方法必须是public的，private方法上的@Transactional根本没意义。

5.4 登录鉴权：后端校验才是安全底线

前端路由守卫只是控制页面跳转，真正的接口安全必须后端把关。我见过一些项目只在前端判断了有没有token，后端接口全部裸奔，这等于把整个系统的数据都暴露了。

后端实现鉴权有三步：写一个JWT工具类生成和解析token；写一个Spring MVC拦截器，从Header里取token并解析用户信息；在WebMvcConfig里注册拦截器，设置哪些接口放行、哪些接口必须登录。管理员接口还要额外校验角色。

这里我建议把用户信息放到ThreadLocal里，这样后续Service方法可以直接从上下文取当前用户ID，不用每个接口都传userId参数。下线或超时场景通过token过期时间控制，比较简单直接。

5.5 上传图片的路径坑：本地能跑，部署就翻车

开发时图片上传到本地目录没感觉，换一台电脑或者重新部署就会出现图片丢失、路径错误的问题。

解决方式上面说过，用外部固定目录存储文件，再通过虚拟路径映射对外暴露。这样上传文件和项目本身是分离的，重新打包部署也不会影响图片数据。从环境变量读取上传路径也是一种做法，只不过毕设场景用固定路径足够。

图片访问要禁止用户直接访问磁盘绝对路径，绝对路径一旦暴露，也容易成为安全隐患。统一走/uploads虚拟路径是最稳的。

6. 答辩准备与项目复盘

6.1 老师最常追问的几个“为什么”

答辩环节考验的不只是代码能不能跑，更考验你对项目整体逻辑的理解程度。我整理了老师最常见的几个追问和合适的回答思路。

这些问题只要在开发过程中想清楚“为什么这么做”，答辩时就能从容应对。最忌讳的是只背答案不理解，因为老师的追问往往一环扣一环。

6.2 做完这个项目之后还能往哪个方向扩展

如果你做完上述功能还有余力，或者想把项目写进简历当作项目经验，可以考虑这几个方向。

第一个是商品搜索升级，把数据库LIKE查询改成Elasticsearch或者对接一个轻量级搜索引擎，展示对中文分词和搜索相关性的理解。第二个是热点数据缓存，给首页商品和热门商品加Redis缓存，讲解缓存穿透、击穿、雪崩的应对思路。第三个是做管理端的数据看板，用ECharts展示近七天的订单趋势、品类销售分布。第四个是增加多商家模块，把单平台升级成平台+商家+用户的三端系统，这只是把表结构扩一扩，但答辩的复杂度立刻就上去了。

扩展要挑一个方向做透，不要四个都做一半。

6.3 一个过来人的实话

做这个项目最大的体会，是“完成”和“完美”之间差的往往不是技术，而是对业务细节的态度。一个能正确计算金额、库存准确、订单状态正确的商城系统，比一个页面漂亮但逻辑漏洞百出的系统有价值得多。

我个人比较推荐的做法是：先完整跑通一条主链路，每一个环节都记录下来，再回头去补边界情况。比如购物车没勾选能不能下单、库存不足时提示是否友好、订单取消后库存是否回滚，这些细节才是真正拉开差距的地方。

这套项目的架构和代码，我现在还会拿来当作讲前后端分离的典型例子，因为它涵盖的知识点足够多，但又不至于复杂到让人望而却步。如果你正在为毕设定题发愁，不妨就把这个“老题目”做出一点新意，把主链路做扎实，把一个亮点做深入，做成90分的版本。