SpringBoot+Vue全栈实战：服装销售平台管理系统设计

不是毕业设计模板也不是网上那些CtrlC就能跑的教学项目。我最近刚把一个服装销售平台管理系统从零搭完项目代号就叫“衣依”技术栈是SpringBoot Vue MyBatis MySQL。从需求梳理到数据库设计再到前后端联调、部署上线完整走了一遍中间踩了不少坑也有一些现在回头看觉得“当时要是早知道就好了”的经验。这篇文章我把整个系统的设计与实现过程拆开讲包括功能模块怎么划分、数据库表为什么这么建、订单状态怎么流转、后端事务和库存扣减怎么配合、前端权限和按钮控制怎么做以及最后联调部署时常见的几个真问题。适合正在做类似管理系统、准备写课程设计或者想自己从零撸一个全栈项目的朋友参考不管是照抄思路还是直接拿来做二次开发应该都能省不少时间。1. 项目定位与核心功能拆解1.1 服装销售平台到底要解决什么问题很多人在做管理系统时容易犯一个错一上来就想着“功能越多越好”。实际上一个服装销售平台的核心业务链条非常清晰——选品、上架、下单、发货、库存变动、订单完结。所有功能都应该围绕这条主线展开而不是漫无目的地堆砌。“衣依”这个系统的定位是面向中小型服装销售企业的后台管理系统核心解决三件事商品怎么管、订单怎么走、库存怎么控。说直白点老板和运营人员需要一个地方能看清楚今天卖了多少、还剩多少货、哪些订单还没发货仓管需要一个地方能快速上下架商品、录入新款财务或客服则需要查看订单明细和用户信息。所以我在设计功能时没有贪多而是把“商品、订单、库存、用户、权限”这五个维度做扎实。其他像营销活动、积分系统这类功能我都放在扩展列表里等核心跑通了再说。1.2 角色权限与业务闭环设计角色权限是管理系统里绕不开的部分但很多人做得特别粗糙比如所有接口都不校验身份或者前端隐藏了按钮就算“有权限”。这种思路放到真实业务里是撑不住的。“衣依”系统里我设计了三种角色管理员、运营人员、普通用户。管理员拥有全部权限包括用户管理、数据统计、系统配置运营人员主要负责商品上下架、订单处理和库存调整不能动用户数据普通用户则是通过前台商城注册的买家在后台只有查看自己订单和修改个人资料的权限。这里有一个点值得单独说前后端都要做权限控制。前端做控制是为了用户体验没权限的菜单和按钮直接不显示后端做控制才是真正的安全屏障每个接口在进入业务逻辑之前都要校验当前用户的角色。只做前端控制别人抓包调接口就能绕过只做后端控制前端页面会显得很笨拙按钮点了半天才弹“无权限”提示体验很差。1.3 功能模块清单与优先级判断我按照“核心必须有、辅助可以延后”的原则把系统功能分成三类你可以直接参考这个清单来规划自己的项目进度优先级模块功能点说明P0商品管理商品增删改查、上下架、分页搜索、分类筛选系统的基础没有商品一切免谈P0订单管理创建订单、订单列表、订单状态流转、订单详情业务主线必须最先跑通P0库存管理库存初始化、下单扣减、入库增加、库存预警和订单强关联设计时就要想清楚P1用户管理用户注册登录、个人信息、角色权限分配登录是入口权限是安全底线P1分类管理一级/二级分类维护辅助商品筛选建议商品模块一起做P2数据统计销售额统计、热销商品排行有报表需求再做不阻塞核心流程P2营销活动优惠券、限时折扣属于锦上添花建议后期迭代这样做的好处是开发过程中你始终清楚“我现在做的事是不是核心链路”。我就见过一个同学花了大量时间做优惠券功能结果商品和订单的主流程还没走通最后联调时一堆问题这种本末倒置的教训希望你别再踩。2. 技术选型为什么是SpringBoot Vue MyBatis2.1 SpringBoot在后端扮演的角色SpringBoot的本质是“约定大于配置”它把Spring家族里繁琐的XML配置大量简化内置Tomcat打个Jar包就能直接跑。对于“衣依”这种业务复杂度中等、但接口数量不少的管理系统来说SpringBoot的性价比极高。我选择SpringBoot还有一个很实际的原因生态成熟遇到问题搜一下基本都有答案。不管是集成MyBatis、Spring Security还是JWT鉴权社区里都有大量现成方案这对一个人开发整个项目来说非常重要。你不可能每个坑都从零去趟能快速找到可靠参考本身就是生产力。版本上我建议用SpringBoot 2.7.x不要一上来就追SpringBoot 3.x。3.x是基于Jakarta命名空间和Java 17的很多老教程和第三方库的兼容性还没跟上对新手和赶项目的朋友不太友好。2.7.x配Java 8稳定而且资源多等基础项目跑通了再升级也不迟。2.2 Vue Element UI搞定管理后台前端这边我用的是Vue 2 Element UI。可能有朋友会问现在不都流行Vue 3 Element Plus吗怎么还用Vue 2原因很简单稳定性和现有资源量。Vue 2 Element UI的组合在后台管理系统领域已经打磨了很多年组件丰富、文档全、踩坑记录多。如果你不是要做特别复杂的前端交互Vue 2完全够用。而且很多参考代码、课程设计、演练项目都是用这个组合写的直接改起来效率特别高。如果这是你自己的项目且时间充裕选Vue 3 Element Plus也没问题但没必要为了“新”而牺牲效率。管理后台的页面形态其实非常固定左侧菜单 顶部导航 内容区表格。Element UI的Container布局加上Menu菜单、Table表格、Dialog弹窗、Form表单这些组件真的可以做到“套模板式”开发。我后面会单独讲商品管理和订单管理两个页面是怎么搭出来的届时你会有更直观的感受。2.3 MyBatis与MySQL的配合逻辑MyBatis在“衣依”系统里承担的职责是数据访问层。它把SQL写在XML映射文件里自由度很高尤其适合业务查询条件复杂、需要定制SQL的场景。举个例子商品列表页的搜索条件可能包含商品名称模糊查询、分类筛选、价格区间、上下架状态。这些条件组合起来SQL里明明是可以动态拼接的。MyBatis的where标签加if标签就是干这个的写起来干净利落。JPA在这类场景下虽然也能做但表达式拼接的写法远没有XML直观特别是在多表关联查询时MyBatis的优势更明显。MySQL的选择就不用多解释了中小型项目的标配。数据量在百万级以下时单实例MySQL加合理索引完全够用。“衣依”只是个服装销售管理平台并发量不大核心是事务可靠和查询高效MySQL刚好都满足。2.4 为什么不建议一上来就上微服务这可能是很多朋友最纠结的点。网上微服务文章铺天盖地看多了难免觉得自己做个系统不上Spring Cloud Alibaba就落伍了。我的建议非常明确如果是单体就能解决的问题不要为了“技术好看”强行上微服务。微服务带来的服务拆分、分布式事务、服务注册发现、配置中心、链路追踪每一个都是额外的复杂度对一个人开发的中小型管理系统来说弊远大于利。“衣依”这个系统用户、商品、订单、库存这几块业务的耦合度其实很高比如下单要同时扣库存、改订单状态、算支付流水拆成多个微服务之后一次下单要跨服务调用好几次还得处理分布式事务纯属给自己挖坑。单体应用加数据库事务十几行代码就能搞定的事何必搞复杂呢。等将来真有业务增长和拆分需求了再按边界重构也不迟。3. 数据库设计与核心表结构3.1 概念模型从商品到订单的主线数据库设计是整个项目里最需要静下心来做的事一旦表结构设计有问题后面写代码会非常痛苦。我在设计“衣依”系统时是先画概念模型再落成表而不是一上来就建库建表。核心业务闭环是这样的用户浏览商品把商品加入订单订单提交时检查并扣减库存管理员对订单进行发货处理订单状态一步步流转到完成。围绕这条链路最少需要五张核心表用户表、商品表、分类表、库存表、订单表。订单和商品是多对多关系所以还需要一张订单明细表把订单下每个商品的数量、单价固定下来。另外还有一张很重要的表容易被忽略——操作日志表。谁在什么时间对哪个商品做了上下架操作、哪个订单被改价了这些都需要记录。线上出了问题日志是排查的第一依据。“衣依”系统里我用AOP切面统一记录关键操作写接口的人不需要自己手动记日志AOP拦截之后统一入库这个设计建议你直接抄。3.2 核心表字段说明我把几张核心表的字段设计列出来直接作为建表参考用户表user字段名类型说明idbigint主键自增usernamevarchar(50)用户名唯一索引passwordvarchar(255)密码BCrypt加密存储nicknamevarchar(50)昵称roletinyint角色0管理员1运营2普通用户phonevarchar(20)手机号statustinyint状态0禁用1启用create_timedatetime创建时间商品表product字段名类型说明idbigint主键namevarchar(100)商品名称category_idbigint分类ID关联分类表pricedecimal(10,2)销售单价original_pricedecimal(10,2)原价用于展示折扣imagevarchar(255)主图URLdescriptiontext商品详情描述statustinyint0下架1上架create_timedatetime创建时间订单表orders字段名类型说明idbigint主键order_novarchar(32)订单编号唯一user_idbigint下单用户IDtotal_amountdecimal(10,2)订单总金额statustinyint0待付款1待发货2已发货3已完成4已取消receiver_namevarchar(50)收货人姓名receiver_phonevarchar(20)收货人电话receiver_addressvarchar(255)收货地址create_timedatetime下单时间这里有两个细节值得说一下。第一个是金额字段一定用decimal(10,2)绝对不要用float或double。浮点数在计算机里是近似存储累计计算会出精度问题电商系统里金额差一分钱都是大事故。第二个是订单编号我用的是时间戳加随机数格式类似20250612153012345678确保高并发下也不容易重复。有人喜欢用数据库自增ID做订单号但这样会把订单量和用户量直接暴露出去而且多表合并时容易冲突不建议这么做。3.3 订单状态机状态流转的设计思路订单状态是业务里最容易出乱子的地方。我在“衣依”系统里明确了一组状态流转规则待付款 → 待发货 → 已发货 → 已完成其中待付款和待发货状态下都可以取消。为什么要定义这么清楚因为在写代码时你需要在每个修改订单状态的操作前校验“当前状态是否允许跳转到目标状态”。比如一个已发货的订单不能直接改成待付款这在业务上是荒谬的但如果你不校验代码里就真的可能发生。具体实现时我会在每个状态变更方法里先查一次当前状态然后和允许流转的目标状态做对比。这个逻辑我封装成了OrderStatusTransition工具类里面定义了一个Mapkey是当前状态value是允许跳转的状态集合。这样所有状态变更都走同一个校验入口不会出现某个接口漏校验的情况。4. 后端落地SpringBoot MyBatis的关键实现4.1 项目分层与包结构后端项目的包结构我按“controller-service-mapper-entity-common”五层来组织这也是目前Java后台项目最主流的分层方式。com.yiyi ├── controller // 接口层只做参数接收和结果封装 ├── service // 业务层写核心业务逻辑 │ └── impl ├── mapper // MyBatis接口层 ├── entity // 数据库实体 ├── dto // 请求参数对象 ├── vo // 返回给前端的数据对象 ├── common // 通用类统一返回结果、异常、常量 └── config // 配置类跨域、拦截器、AOP等controller层不做业务只负责接收参数、调用service、返回结果service层写核心逻辑mapper层只做数据访问。这样分的好处是职责单一测试起来也方便。很多人写完一个项目还是“大泥球”就是因为controller里塞了太多不该有的逻辑后面想改一个功能都不知道从哪里下手。4.2 统一返回结果与异常处理前后端分离项目里接口返回格式必须统一否则前端解析起来会非常痛苦。我在“衣依”系统里定义了一个ResultT类结构就是最常见的三件套code、message、data。成功时code为200失败时code为500业务异常用400系列区分。配合全局异常处理器RestControllerAdvice业务代码里只要抛出我们自定义的BusinessException就会被统一捕获并转成标准结果返回。比如下单时库存不足我就直接throw new BusinessException(库存不足)前端拿到的就是{code: 500, message: 库存不足, data: null}。这样每个接口少写一堆try-catch代码干净很多。4.3 商品模块分页查询与条件检索商品列表页是管理后台的核心页面运营人员需要按照名称、分类、价格区间、状态这些条件筛选商品。对应的后端接口是一个典型的分页条件查询。public PageResultProduct queryProductPage(ProductQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); ListProduct list productMapper.selectByCondition(query); return new PageResult(list); }对应的MyBatis XML里我用where加if动态拼接查询条件核心逻辑是这样的select idselectByCondition resultTypecom.yiyi.entity.Product SELECT * FROM product where if testname ! null and name ! AND name LIKE CONCAT(%, #{name}, %) /if if testcategoryId ! null AND category_id #{categoryId} /if if testminPrice ! null AND price gt; #{minPrice} /if if testmaxPrice ! null AND price lt; #{maxPrice} /if if teststatus ! null AND status #{status} /if /where ORDER BY create_time DESC /select这里有个小经验使用PageHelper分页时要确保它紧跟的SQL就是你要分页的那条查询语句中间千万别夹别的查询或赋值操作否则分页会把错误的SQL包进去查出来的数据数量就不对了。我一开始就在这种地方被坑过一次排查了半小时才发现是PageHelper误拦截了后面的SQL。4.4 订单模块事务与库存扣减订单模块是“衣依”系统里最需要小心的地方因为一次下单操作要同时做三件事写入订单主表、写入订单明细表、扣减商品库存。这三件事要么全部成功要么全部失败绝对不能出现订单建了但库存没扣的情况。实现上我直接用了Spring的Transactional注解在service层的下单方法上声明事务。这里有个关键点事务一定要放在service方法上不能放在controller上否则事务边界会失控。另外要注意事务的“自调用失效”问题如果同一个类里方法A调用方法BB上加的Transactional不会生效因为Spring事务代理的对象是外层对象内部调用走的是this而不是代理。所以事务方法应当通过外部调用触发或者把真正需要事务的逻辑拆分到另一个类中。库存扣减我采用的是“乐观锁”在SQL层面直接加条件判断防止超卖UPDATE product SET stock stock - 1 WHERE id #{productId} AND stock 1返回影响行数为1说明扣减成功返回0说明库存不足或商品不存在。这样即使两个人同时下单同一件商品数据库层面的行锁和条件判断也能保证不会扣成负数。这个写法比“先查再改”的代码要安全得多。5. 前端落地Vue Element UI实现管理界面5.1 登录鉴权与路由守卫前端的技术栈是Vue 2 Element UI Vue Router Vuex Axios。管理后台的登录流程我这边控制在三步用户输入账号密码提交到后端后端校验通过后返回JWT token和用户基本信息前端把token存到localStorage并写入Vuex后续每个请求都在请求头里带着Authorization: Bearer token。路由守卫是整个前端权限控制的核心。我在router/index.js里配置了一个全局前置守卫beforeEach每次路由跳转前先检查有没有token。没有token就强制跳转到登录页有token但是要访问的页面需要管理员权限而当前用户角色又不是管理员就拦截并提示无权限。菜单和按钮的控制我用的是自定义指令v-permission。比如“删除商品”这个按钮只有管理员角色能看到我就写成el-button v-permission0 typedanger clickhandleDelete删除/el-buttonv-permission指令接收一个角色编码指令的inserted钩子里会检查当前用户角色不符合的直接把DOM节点移除。这样做的好处是所有权限判断在一个指令里收敛不会散落在各页面代码中。5.2 商品管理页表格加弹窗加表单校验商品管理页是“衣依”后台最典型的一类页面结构就是搜索区、工具栏、表格区、分页器、弹窗表单。Element UI把这些组件都提供好了我的工作主要是把它们组织起来。搜索区用el-form做内联布局包含商品名称输入框、分类下拉框、状态选择器和“查询”“重置”两个按钮。搜索时把表单数据赋值给查询参数对象然后重新调用列表接口。重置时清空所有搜索条件再查一次默认列表。表格区用el-table展示商品数据我这里设置了商品名称、分类、价格、库存、状态、创建时间、操作列这七列。操作列是“编辑”和“上下架”按钮通过el-button的type属性区分不同操作样式。上下架操作我会先弹一个el-messagebox.confirm让运营人员确认避免误点。新增和编辑共用同一个弹窗弹窗里是el-form字段和校验规则在data里声明。价格字段用type: number并配置自定义校验确保大于0商品名称字段用required和min/max长度校验。表单提交前先调用validate方法通过后再调接口这样能拦截大部分无效提交避免后端每一处都做重复参数校验。5.3 订单管理页状态流转与操作按钮控制订单管理页的核心不是数据展示而是操作按钮根据订单状态动态变化。我给每个状态定义了一组可用操作待发货订单可以“发货”和“取消”待付款订单可以“取消”已发货订单可以“查看物流”已完成和已取消订单没有操作按钮。实现起来就是在表格的操作列里用v-if判断当前行的状态再渲染对应的按钮。例如el-button v-ifscope.row.status 1 sizemini typeprimary clickhandleShip(scope.row)发货/el-button el-button v-ifscope.row.status 1 || scope.row.status 0 sizemini typedanger clickhandleCancel(scope.row)取消/el-button这里有一个很容易犯的错按钮状态只在前端控制后端接口却没有对应校验。如果后端不校验“已发货订单不允许取消”那么有人绕过前端直接调取消接口业务就出问题了。所以我在后端订单状态流转的service方法里做了同样的状态校验前端提示是引导后端校验才是底线。订单详情的展示我用了一个el-drawer抽屉从右侧滑出里面用el-descriptions展示收货人信息、商品明细、金额明细、时间信息。比弹窗更自然也比跳转新页面更轻量。建议你在做详情展示时也优先考虑抽屉体验比弹窗好。6. 部署上线与常见问题排查6.1 本地联调与跨域处理前后端分离开发时最大的痛点就是跨域问题。开发阶段前端跑在localhost:8080Vue脚手架默认端口后端跑在localhost:9090两者不同源浏览器会拦截跨域请求。解决跨域的常见做法有两种。一种是后端加CORS配置Configuration public class CorsConfig { Bean public CorsFilter corsFilter() { CorsConfiguration config new CorsConfiguration(); config.addAllowedOrigin(http://localhost:8080); config.addAllowedMethod(*); config.addAllowedHeader(*); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration(/**, config); return new CorsFilter(source); } }另一种是在前端Vue项目里配置代理把/api前缀的请求转发到后端地址。我在开发时用的是前端代理方案因为生产环境里Nginx反代也很自然代码层面不用改任何请求路径。具体在vue.config.js里配置devServer.proxy把/api代理到http://localhost:9090。生产环境部署我用了比较常规的方式后端打成Jar包用nohup java -jar启动前端执行npm run build生成dist静态文件由Nginx托管。Nginx里做了一个反向代理把/api和/admin开头的请求转发给后端这样前后端同域不存在跨域问题也方便后续加HTTPS证书。6.2 常见问题速查表我把整个开发过程中遇到和身边朋友反馈过的高频问题整理成了一张速查表基本覆盖了前端和后端的常见坑问题描述原因分析解决方案前端请求接口显示404后端接口路径和前端请求路径不一致检查Controller的RequestMapping和前端request的URL是否完全一致注意大小写和斜杠页面能打开但表格没有数据后端返回数据结构不是前端期望的{code, message, data}格式统一后端返回结构前端Axios拦截器直接取res.data.data请求跨域报错开发阶段前后端端口不同使用Vue代理或后端CORS配置建议在生产环境用Nginx同域反代分页数据错乱PageHelper误拦截了分页SQL后面的其他查询确保PageHelper后面紧跟需要分页的SQL避免中间插入其他mapper操作修改密码后无法登录密码加密方式不一致注册时用的加密算法和登录校验时不同统一使用BCryptPasswordEncoder进行密码加密和校验上传图片后刷新就没了图片存到了本地临时目录或前端内存里把上传图片保存到磁盘或对象存储数据库中存储访问URL操作按钮点击没反应权限指令把按钮移除了但用户没感知前端做好权限提示比如无权限时按钮置灰并提示而不是直接消失这里多说一句前端“按钮消失”在用户体验上其实不是最好的方案更好的做法是按钮保留但置灰鼠标放上去提示“当前角色无权限”。这算是一个细节但对真实使用者的体验影响很大。6.3 我踩过的几个坑讲几个我在“衣依”系统里真实踩过的坑每一个都花了不少时间排查写下来希望你能绕开。第一个是订单状态校验的漏洞。初版代码里我只在后端写了状态流转校验但是“取消订单”这个方法里漏了“已发货订单不能取消”的条件。结果测试的时候模拟了一个场景先点发货再通过抓包工具直接调用取消接口状态就变成了已取消但货其实已经发出去了。后来我把所有涉及状态变更的接口统一梳理了一遍全部改为通过状态机工具类校验才堵住了这个漏洞。现在这个工具类是我所有状态流转的统一入口改动一个状态判断只需要改一处。第二个是库存扣减的高并发问题。初版代码是“先查询库存再判断是否足够最后执行扣减”本地测试没问题但我用压力测试工具模拟了50个并发下单同一件商品时库存变成了负数。原因就是查和扣之间不是原子的两个请求可能同时查到了剩余1件然后都执行扣减。改成文中那种UPDATE product SET stock stock - 1 WHERE id #{id} AND stock 1的写法之后并发问题就消失了。第三个是数据库连接配置时区的问题。我第一次部署时用的连接串里没有加serverTimezoneAsia/Shanghai结果时间字段全部比北京时间少了8个小时。排查了一圈才发现是MySQL连接时区配置不对在连接串里加上时区参数后重启服务就正常了。这个问题不仔细排查很难发现因为系统能跑、数据能查、订单能出只有时间对不上而且不是一直对不上是差整8小时。建议所有项目从一开始就在连接串里把时区写明确不要依赖默认值。7. 功能和代码可以怎么扩展“衣依”系统算是跑通了一个完整的管理系统闭环从数据库设计到后端接口再到前端页面和部署上线。但这个项目其实还有很大的扩展空间我按业务价值排了优先级供你参考。排在前面的是数据可视化。目前系统里只有订单和库存的列表只回答了“现在是什么情况”没有回答“最近趋势怎么样、哪些商品卖得好”。接一个ECharts或者AntV把订单金额按天统计出来把商品销售排行用柱状图展示整个系统的价值会立刻上一个台阶。我在表结构设计时已经预留了订单创建时间字段统计查询只需要一条GROUP BY语句就能出数据。其次是移动端适配。管理后台目前在PC浏览器上体验最好但很多老板习惯用手机看数据。建议用响应式布局改一改表单和表格或者在后台单独做一个移动端适配页面至少让关键数据在手机上有最简单的展示。再往后是消息通知。下单成功、订单发货、库存低于阈值这些事件可以对接短信或微信模板消息推送让运营人员不用一直盯着后台。扩展这类功能时我建议用Spring Boot的事件发布和监听机制在业务代码里publishEvent抛事件监听器里异步处理发送业务主流程不会被阻塞。代码层面我建议你把权限功能升级一下从“固定三种角色”改为“角色和菜单权限分别建表”的动态权限模型。也就是每次登录后从数据库查出当前角色能访问的菜单和按钮权限动态生成路由和权限指令。这个改动适合作为后台系统的长期演进方向但不建议一上来就做先把固定角色的逻辑跑稳了再说。回到开头那句话做管理系统最怕的不是技术不会而是需求不清就动手、表结构没想明白就写代码、前后端权限只做一边。我在“衣依”项目里踩过的那些坑绝大部分都来源于这些基础问题。如果这篇文章能帮你少走一次弯路那我觉得这几个小时写得还挺值。