SpringBoot+Vue前后端分离服装销售平台系统全栈设计与实现

做Java后端开发这几年，SpringBoot + Vue 的前后端分离组合，几乎成了接手Web系统最常见的标配。今天要拆解的“衣依”服装销售平台管理系统，就是用 SpringBoot 做后端、Vue 写前端、MySQL 存数据、MyBatis 管持久层的完整项目，涵盖了商品浏览、购物车、订单流转、库存扣减、后台数据统计这些电商业务里最典型的功能模块。如果你是准备毕业设计、想在校招简历里放一个能打的全栈项目，或者刚入门前后端分离但缺一份完整源码参考，这篇拆解值得你花十分钟看完。

我会按自己实际做这个项目时的思路来复盘：先讲业务怎么梳理、功能边界怎么切，再讲技术选型背后的取舍，然后是数据库表怎么设计、核心功能怎么落地，最后把部署和排查问题的方法也一并交代清楚。整个过程不追求炫技，只求把每一步的来龙去脉讲明白，让你拿到源码之后能真正改得动、跑得起来。

1. 项目定位与需求拆解

1.1 业务边界先想清楚，再决定写哪些功能

做这类管理系统的第一件事不是写代码，而是把“这个平台到底给谁用、解决什么问题”画清楚。“衣依”是一个服装销售平台，它的业务本质是：一个服装品牌或中小型商家，想把线下门店的商品搬到线上，让用户在线逛、在线下单，同时还需要一个后台来管理商品、处理订单、看销售数据。

想清楚这一点，功能边界就很自然了。我把它分成两条线：

• 用户端（前台）：注册登录、商品分类浏览、商品搜索、商品详情、加入购物车、提交订单、查看订单、个人资料修改。
• 管理端（后台）：管理员登录、分类管理、商品管理（增删改查+上下架）、订单管理（发货、查看详情）、会员管理（禁用/启用用户）、数据看板（销售额、订单数、热销商品）。

很多同学会把用户端做得特别复杂，比如加上优惠券、拼团、秒杀。我的建议是：如果目标是毕业设计或简历项目，先把基础闭环做扎实。上面列出的功能已经能把“用户从登录到下单、管理员从接单到发货”整条链路跑通，这就够了。优惠券和秒杀是加分项，有精力再加，不要一开始就铺太大，否则容易烂尾。

1.2 核心业务场景与角色权限划分

一个系统如果连权限都理不清，后面写接口必然一团乱麻。这个项目里我做的是经典双角色模型：普通用户和管理员。

这里有一个很关键的设计：并不是所有接口都能被所有人访问。比如“生成订单”“修改购物车”必须登录才能调，“商品上架”“订单发货”必须管理员才能调。

我当时用的是最轻量的一条路：前端根据登录状态控制按钮显示，后端用拦截器校验请求头里的 token。前端隐藏按钮只是用户体验的优化，真正的安全防线在后端。这个意识很重要，因为很多毕设答辩老师会专门问“你这个权限控制是怎么做的”，你要是只答“前端判断了用户类型”，基本就露馅了。

1.3 这个项目适合用来学什么

“衣依”这个项目最大的学习价值，不在于某个单一技术多高深，而在于它把 Java 全栈开发里最常用的一整套路子完整串联了起来：

• 用 SpringBoot 搭建 RESTful API，理解 Controller-Service-Mapper 分层；
• 用 MyBatis 写灵活 SQL，理解结果映射、动态 SQL、主键回填；
• 用 MySQL 做数据建模，理解表关联、索引、事务；
• 用 Vue 组件化开发页面，理解组件通信、路由守卫、Axios 封装；
• 用 JWT + 拦截器实现登录鉴权，理解无状态认证的完整流程。

如果你能把一个项目从头到脚自己复现一遍，再把里面几个核心点（比如订单事务、权限拦截、库存扣减）讲清楚，面试官对你的评价通常不会低。

2. 技术选型背后的思路

2.1 为什么选 SpringBoot + MyBatis + MySQL，而不是别的

这个组合看起来“普通”，但它恰恰是当前中小型管理系统最务实的搭配。我尝试过用 JPA 做数据持久层，开发速度确实快，可一旦遇到需要多表联查、统计报表的场景，JPA 生成的 SQL 就很别扭。MyBatis 呢，把 SQL 交给开发者自己掌控，写个复杂查询、调优性能都很有底气。

SpringBoot 的存在，则把传统 SSM 里那些繁琐的配置全部干掉。以前搭一个 SpringMVC + MyBatis 项目，要配 web.xml、dispatcher-servlet.xml、数据源、事务管理器，稍不注意就起不来。换成 SpringBoot 之后，一个启动类加一个 application.yml，一个能跑起来的项目就到位了，这对写业务代码来说省下的时间非常可观。

MySQL 就更不必说，作为关系型数据库的经典选择，它的吞吐能力和稳定性对一个小型服装销售平台来说绰绰有余，而且社区资料极多，遇到问题一查就有答案。整套选型组合在一起，就一句话：稳定、通用、好招人。企业里跑着的项目大量是这个组合，你简历里写它，起码不会让人觉得你做的项目脱离实际。

另外，前后端分离的选择也很重要。传统 JSP 那种服务端渲染的方式，后端既写接口又套页面，开发和维护都很痛苦。用 Vue 把前端彻底独立出来之后，前端专注页面交互，后端专注业务接口，结构清晰，团队协作也方便。就算只有你一个人开发，分离开的代码结构也远比揉在一起好维护。

2.2 前端工程与后端工程怎么配合

一体化的前后端分离开发，在本地通常让 SpringBoot 跑在 8080 端口，Vue 开发服务器跑在 8081 端口，前端开发环境下把接口地址代理到后端。这样两边可以独立开发调试，互不干扰。

我在项目里给前端定了几个关键目录：

• src/api：统一放所有接口请求，一个模块一个文件；
• src/router：前端路由，同时配置全局守卫；
• src/store：用 Vuex 管理全局状态，比如用户登录信息、购物车数量；
• src/views：页面组件，按 admin 和 user 分开目录。

这样一来，整个前端的职责非常单一。要做登录页，就去 views 里加页面、在 api 里加对应接口、在 store 里存 token；要控制页面访问，就去 router 的守卫里判断角色。每个文件都是“各管一摊”，后续改起来很舒服。

2.3 项目目录层级如何划分最顺手

后端我是严格按分层模式来的，package 结构如下：

com.yiyi ├── controller # 接收请求、参数校验、返回结果 ├── service # 业务逻辑、事务控制 ├── mapper # MyBatis 的 Mapper 接口 ├── entity # 数据库实体映射 ├── dto # 前端交互的数据传输对象 ├── config # 跨域、拦截器、WebMvc 配置 ├── common # 统一返回结果、异常处理、常量 └── utils # JWT、日期处理等工具类

这套结构是 Java Web 项目最经典的写法，好处是“每一层只关心自己的事”。Controller 只做参数接入，Service 只写业务规则，Mapper 只负责数据库交互，一旦出了问题，顺着调用链很快就能定位。

前端目录我上面说了，再补充一点关于封装的思路——Axios 不要每个页面单独引入，而是统一封装一个 request.js 文件，配置基础 URL、请求拦截器（自动带上 token）、响应拦截器（统一处理 401、500 等状态码）。这样所有页面发请求都是同一个入口，遇到问题只需改一处，这是让项目代码变得“能看”的关键一步。

3. 数据库设计与核心表结构

3.1 业务表拆解：从“买衣服”这个动作反推

数据库设计我一般不从表开始，而是从“业务流程”反推。用户进入“衣依”后要做的事情是：注册登录 → 逛分类 → 看商品 → 加购物车 → 提交订单 → 等发货。每个动作背后至少对应一张表：

• 用户表user：记录账号、密码、昵称、手机号、头像、角色；
• 分类表category：记录服装分类，比如男装、女装、童装；
• 商品表product：记录商品名称、价格、库存、主图、详情、所属分类；
• 购物车表cart：记录某个用户加入的某商品、数量、勾选状态；
• 订单表order：记录订单号、下单用户、总金额、状态、收货信息；
• 订单明细表order_item：记录订单内每个商品的快照信息；
• 轮播图表banner：记录首页广告图，方便运营替换。

这里我要强调一个细节：订单明细必须存商品快照，而不是只存商品 ID。为什么？因为商品价格和名称是可以变的，如果用户下单后商家调高了价格，订单明细里如果关联原商品表，那用户看到的订单金额就和下单时不一致了。把“商品名、单价、图片、数量”原样复制进订单明细里，才能保证历史订单的不可变性。这个细节在面试时提出来，是很加分的。

3.2 关键字段设计与状态机

一张表设计得如何，直接决定了后续代码好不好写。我说几个关键约定：

• 主键统一用自增INT，简单稳定；
• 金额字段全部用DECIMAL(10,2)，不用浮点类型，避免精度丢失；
• 时间字段用DATETIME，统一由后端生成；
• 逻辑删除字段is_deleted用TINYINT，删除操作改为更新操作，保留数据可回溯。
• 订单状态用TINYINT存数字，配合常量或枚举类管理。

订单状态是整个项目里最需要想清楚的点。我设计了这么一套状态机：

状态不写死成字符串而用数字，是为了后续扩展方便。比如后续要加“退款中”“退款完成”，只要补两个数字编号就行。

3.3 分页查询和索引设计

商品列表和订单列表都必须分页。有的同学会直接在 Mapper 里用LIMIT start, pageSize手写分页，那样每张表都要写一遍重复逻辑。我建议引入PageHelper这个分页插件，一行代码就能完成分页，实用性很强。

索引方面，核心表不需要加太多索引，但有几个字段基本是必需的：

• user.id、product.id、category.id这类主键系统自带索引；
• product.category_id加普通索引，分类筛选商品时能明显提速；
• order.user_id加普通索引，用户查看自己的订单列表是高频操作；
• cart.user_id加普通索引，购物车读取频繁。

这里要小心一个“索引失效”的坑：如果商品搜索需求用LIKE '%keyword%'，这种写法索引是不生效的，数据量小的时候无所谓，但心里要有数。真到数据量大的时候，就得换 Elasticsearch 或 MySQL 全文索引了，那是后话。

4. 核心功能的实操实现

4.1 登录鉴权：JWT + 拦截器的完整落地

登录鉴权我选了 JWT 方案，而不是传统的 Session。原因是前后端分离的结构里，后端接口不关心“客户端是谁”，只需要验证“请求里的 token 是否有效、属于谁”。JWT 天然适合这种无状态场景。

生成 token 的逻辑很简单：

public String generateToken(Long userId) { return Jwts.builder() .claim("userId", userId) .setExpiration(new Date(System.currentTimeMillis() + 7 * 24 * 60 * 60 * 1000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

用户登录成功后就返回这个 token，前端把它存到localStorage，并在后续每个请求的 header 里带上Authorization: Bearer token。

后端拦截器是权限控制的关键，我写了一个JwtInterceptor实现HandlerInterceptor接口：

@Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册、商品浏览等公开接口 if (isPublicApi(request.getRequestURI())) { return true; } String token = request.getHeader("Authorization"); if (!StringUtils.hasText(token)) { throw new BusinessException(401, "未登录"); } // 解析 token，校验有效性 Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); request.setAttribute("userId", claims.get("userId")); return true; }

这里有一个我踩过的坑：拦截器里如果拦截了全部接口，那么登录接口本身也会被拦截，造成死循环。解决方案就是在上面的代码里维护一个公开接口白名单，比如/api/user/login、/api/user/register、/api/product/**都不需要 token 才能访问。这样游客可以浏览商品，但下单、购物车这些操作就必须登录。管理员的鉴权也类似，在拦截器里解析出 token 之后，再查一下用户的角色字段，非管理员直接拒绝。

4.2 商品模块：Vue 列表页到 MyBatis 动态 SQL

商品列表页是前台最核心的页面。前端用 Vue 发请求拿数据，后端用 MyBatis 动态拼接条件查询。

一个典型的列表接口，后端 Controller 长这样：

@GetMapping("/api/product/list") public Result getProductList(@RequestParam(defaultValue = "1") Integer pageNum, @RequestParam(defaultValue = "12") Integer pageSize, @RequestParam(required = false) Integer categoryId, @RequestParam(required = false) String keyword) { PageHelper.startPage(pageNum, pageSize); List<ProductVO> list = productService.getProductList(categoryId, keyword); return Result.success(new PageInfo<>(list)); }

注意这里我返回的是ProductVO，而不是直接返回实体类。原因很简单：展示列表时一般只需要 id、名称、主图、价格、销量这几个字段，直接返回整个实体既浪费流量，还可能把不该暴露的字段（比如库存、状态）泄露出去。

前面我提到 MyBatis 的动态 SQL 很灵活，这一段是关键。分类筛选和关键词搜索可以写在同一个 Mapper XML 里：

<select id="getProductList" resultType="com.yiyi.entity.Product"> SELECT * FROM product <where> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND (name LIKE CONCAT('%', #{keyword}, '%') OR description LIKE CONCAT('%', #{keyword}, '%')) </if> AND is_deleted = 0 </where> ORDER BY create_time DESC </select>

<where>标签会自动处理多余的 AND，这个细节很实用，你手写 SQL 的时候很容易因为第一个条件为空导致 SQL 语法错误，MyBatis 的动态 SQL 恰好把这个问题解决了。前端用 Category 组件切换分类时，只需要重新传categoryId请求一次接口就行，这是最直观的“前后端数据交互”体验。

4.3 购物车与订单提交：事务与防超卖

购物车最核心的动作是加购和结算。加购的逻辑很直接：先查当前用户的购物车是否已有该商品，有就数量加 1，没有就插入一条新记录。这里要注意一个细节：修改数量时不能简单地前端传什么就存什么，而应该在后端做一次数量上限校验，比如单个商品不能超过 99 件，防止用户恶意刷单。

用户点了“去结算”之后，后端要做一串连续的操作：

1. 校验购物车里选中的商品是否还有库存；
2. 根据商品实时价格计算总金额；
3. 生成订单主表和订单明细表；
4. 扣减商品库存；
5. 移除购物车中对应的记录。

这一串操作只要任何一步失败，前面做的都不能生效。所以必须加事务注解，我用的是 Spring 的声明式事务：

@Transactional(rollbackFor = Exception.class) public Long submitOrder(OrderSubmitDTO dto) { // 1. 查购物车选中明细 // 2. 遍历校验库存、计算金额 // 3. 插入 order 表 // 4. 批量插入 order_item 表 // 5. 批量扣减库存 update product set stock = stock - ? where id = ? // 6. 删除对应购物车记录 // 返回订单号 }

关于库存扣减，我先说一个最简单的版本，也是这个项目能跑通的版本：先查出商品库存，判断够不够，够则执行UPDATE product SET stock = stock - #{count} WHERE id = #{productId}。但直接这么写在高并发下会产生“超卖”问题。如果你想在项目里体现出思考深度，可以把 SQL 改成乐观锁方案：

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

用受影响行数来判断是否扣减成功，如果返回 0 说明库存不足，就不再继续出单。这是现阶段最容易被面试官认可的做法，实现成本也低。另一个可行方案是给商品表加一个version字段做乐观锁，但判断逻辑会更绕，建议先把握住上面那条 SQL 的精髓。

4.4 管理端数据看板：几条统计 SQL 撑起的首页

后台首页的数据看板是我个人很喜欢的模块，因为它数据和业务交叉，最能体现你对 SQL 的掌握程度。

销售额统计可以按“最近 7 天的每日支付金额”来展示，SQL 长这样：

SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM `order` WHERE status IN (1, 2, 3) AND create_time >= DATE_SUB(CURDATE(), INTERVAL 6 DAY) GROUP BY DATE(create_time) ORDER BY day

这里要说明的是为什么要筛状态：订单只有支付之后才真正算销售额，“待支付”“已取消”的订单都不能计入统计。如果你统计口径搞错了，后台的数字会非常难看，答辩时被问到会很尴尬。

热销商品排行则是按销量聚合：

SELECT p.name, SUM(oi.quantity) AS sales_count FROM order_item oi LEFT JOIN product p ON oi.product_id = p.id GROUP BY oi.product_id ORDER BY sales_count DESC LIMIT 10

前端用 Vue + ECharts 画折线图和柱状图，配上 Element UI 的后台布局，整个数据看板的效果非常出彩。这个模块投入产出比很高，强烈建议你一定要做。

5. 部署上线与高频问题排查

5.1 本地从零跑起来的完整步骤

不管你是拿源码学习还是做毕设演示，先让项目在本地跑起来是第一步。我列一下自己的标准操作流程：

第一步，准备环境。JDK 1.8+、Maven 3.6+、MySQL 5.7+、Node.js 14+，版本不要乱选，我验证过这套组合稳定。MySQL 安装后要创建一个数据库，比如yiyi_db，把项目里的sql脚本导入进去。

第二步，改后端配置。重点看application.yml里的数据源信息：

spring: datasource: url: jdbc:mysql://localhost:3306/yiyi_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456

这里有个容易踩的坑：serverTimezone必须配置，否则高版本 MySQL 驱动连接时会出现 8 小时时差的问题。另外，useSSL=false建议也加上，本地开发环境没必要走 SSL，减少不必要的问题。

第三步，启动后端。用 IDEA 打开后端工程，等 Maven 依赖下载完，直接运行启动类。看到控制台打印出 Tomcat started on port 8080 就说明成功了。

第四步，启动前端。命令行进入前端目录：

npm install npm run serve

这里我再提醒一次，Vue 的npm install经常因为网络问题卡住。如果你在国内，最好把镜像源切到淘宝镜像：npm config set registry https://registry.npmmirror.com，实测下载速度快很多。

第五步，浏览器访问前端地址，用系统里已有的管理员账号登录后台，用普通用户账号走一遍“浏览商品 → 加购 → 下单”的流程，验证整条链路是否正常。

5.2 高频报错与排查技巧实录

做这个项目时，我把踩过的坑整理成了几个类型，每个都值得单独说：

跨域问题。前后端分离开发时最常见的报错是浏览器提示 CORS error。解决的办法有很多，比如在 Controller 上加@CrossOrigin注解，或者配置一个全局跨域配置类。我自己的做法是写一个WebMvcConfigurer的配置类，统一设置允许跨域的路径、头部和方法。这种全局方案的好处是，以后新增接口不用再一个个加注解。

SpringBoot 版本与 MyBatis Starter 不兼容。很多同学一上来就把 SpringBoot 拉到最新版，结果引入mybatis-spring-boot-starter后启动报错，其实就是版本匹配问题。我的建议是别追新，选一个经过大量项目验证的稳定组合，比如 SpringBoot 2.7.x + MyBatis Spring Boot Starter 2.2.x，这套闭着眼睛都能跑起来。等到后面你对版本管理有经验了，再考虑升级到 SpringBoot 3.x 也不迟。

Vue 打包后布局异常 / 刷新 404。这是前端部署最常见的两个问题。布局异常通常是静态资源路径写成了绝对路径，把vue.config.js里的publicPath改成相对路径'./'就行；刷新 404 则是前端用了 history 路由模式，但服务器没有把未知路径重定向到 index.html。本地开发时，配置devServer的historyApiFallback: true，部署到服务器则要在 Nginx 里配置try_files。

MyBatis 参数传递问题。有次我写 Mapper 接口方法，只传了一个参数进去，直接用了#{id}，结果 MyBatis 报“参数不匹配”。原因是多参数方法必须加@Param注解：

List<Order> selectOrders(@Param("userId") Long userId, @Param("status") Integer status);

这个规则很简单，但没有经验的人第一次很容易卡住。你在写所有的 Mapper 方法时，只要方法里有超过一个参数，就老老实实加@Param，不要偷懒。

5.3 排查问题的心法与思路

最后我还想聊一个比具体操作更重要的东西：遇到 Bug 时怎么定位。很多新手喜欢到处打断点调试，看一堆变量，搞了半天没头绪。我的习惯永远是从日志和请求链路入手。

前端打开浏览器开发者工具，先看 Network 面板里请求的状态码。如果接口 500，直接复制后端控制台里的报错堆栈去搜；如果请求都没发出去，那就是前端路由或 Axios 封装的问题；如果请求发出去了但没返回数据，就看后端接口入参和 MyBatis 打印的 SQL，对照数据库里的数据排查。

说到 SQL，MyBatis 的 SQL 日志配置一定要开：

mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

开了之后，所有查询语句都会打印到控制台。排查数据问题的时候，直接复制打印出来的 SQL 到数据库工具里手动执行，一眼就能看出是条件写错、关联写错、还是数据本身有问题。这个办法几乎能解决 80% 的表关联和数据记录问题。

另一个我觉得很实用的经验是：改代码要“小步快跑”。一次只改一个点，然后立刻跑到对应接口验证，不要一口气改十个文件再编译运行。否则出了问题，你连是哪一步引起的都找不到。

6. 几个值得再打磨的细节方向

到这里，这个项目的主体功能和运维经验基本都讲完了。如果你想把项目的完成度再往上提一档，我建议从下面几个方向入手，投入不大但收益明显。

订单支付模块目前大多是“模拟支付”，也就是点击支付按钮后直接把订单状态改成已支付。如果想体现更强的业务能力，可以在订单流程里加一个支付回调的模拟接口，核心在于理解“支付结果由服务端主动回调修改订单状态，而不是前端如果支付成功就自己改状态”。这个思路放到真实项目中非常重要，值得自己去设计一下。

权限控制现在只区分了普通用户和管理员两个角色，如果想做得更深，可以考虑引入更完整的权限框架，把“角色”和“权限点”解耦。比如管理员能访问哪些接口，不是写死在代码里，而是用数据库配置，做一个简单的 RBAC 模型。这个升级对理解权限设计会有一个质的提升。

商品搜索目前是 SQL 的模糊匹配，在数据量小的场景下完全够用。如果你想让搜索更智能，可以做关键字分词、搜索热度统计等，但这些更多是业务上的锦上添花，不影响系统的核心闭环。

很多同学跑来问我：“这个项目做完了，简历上该怎么写？”我的建议是不要只写“基于 SpringBoot 和 Vue 开发了服装销售平台”，太单薄。你要写清楚自己具体做了什么，遇到什么问题，怎么解决的。比如：

• 使用 JWT + 拦截器实现无状态登录鉴权，区分普通用户和管理员权限；
• 通过乐观锁方案解决订单提交时的库存超卖问题；
• 设计订单状态机，保证订单从待支付到完成的流转一致性；
• 搭建后台数据看板，通过 SQL 聚合统计销售数据并可视化展示。

这几条才是能打动面试官的内容，因为它们体现了你的思考深度和解决问题的能力。

我自己在实际带项目的时候，最深的体会是：做全栈项目，最大的障碍往往不是某个技术点不会，而是不知道整个系统应该长成什么样。代码写一半发现表设计不合理，改表就要连带改接口、改前端；接口返回的数据结构不统一，前端每个页面都要单独处理；权限漏了校验，又回头补登录判断。这些坑我都踩过。所以如果你现在正卡在某个环节，不要着急怀疑自己，解决一个问题的过程，就是对这个知识体系的一次补全。把“衣依”这个项目从头到尾跑一遍，再自己动手改一改、加一个功能，你对 Java 全栈开发的理解，会比单纯看十篇教程都深刻得多。