去年接了一个服装批发客户的单子需求很直接要做一套商城系统前端能展示商品、加购物车、下单后台要管商品、订单、库存和会员还得留出以后接优惠券、拼团这些营销功能的余地。我最终选了SpringBoot Vue3这套组合来落地整套系统从前端页面到后端接口全部自己搭前后花了差不多三周时间完成核心流程。这套“springbootvue3服装商城销售管理系统”做完之后无论是拿来接私活还是作为毕业设计都很值得复盘一遍。这个项目的价值不在于“商城”本身有多复杂而在于它把电商业务里最典型的几个环节——商品中心、购物车、订单流转、库存扣减、权限控制——完整地串起来了。前端用 Vue3 的组合式 API 配合 Pinia 管理状态后端用 SpringBoot 做 RESTful 接口安全认证走 JWT RBAC数据层用 MyBatis-Plus 操作 MySQL。整套方案不吊高难度但每个模块都是实实在在能跑的很适合想系统掌握前后端分离开发流程的人拿来练手。1. 项目整体定位与方案拆解1.1 商城系统的核心需求到底有哪些做系统之前先别急着写代码把需求拆清楚比什么技术选型都重要。服装商城这类销售管理系统表面上是“卖衣服”实际上拆开来看需求可以分成三条主线面向顾客的购物流程、面向运营的商品管理、面向财务和管理层的订单与数据统计。顾客端的完整链路是注册登录 → 浏览商品列表/详情 → 搜索和筛选按品类、价格、颜色、尺码 → 加入购物车 → 提交订单 → 模拟支付 → 查看订单状态。运营端的链路是维护商品分类 → 上架/下架商品 → 管理商品规格SKU价格和库存 → 处理订单发货、备注 → 查看会员列表。管理层关心的则是销售数据这部分我用了一个简单的统计接口来支撑比如按日/按月汇总销售额、热门商品排行等。这个项目里我把用户端和管理端合并成了一个前端工程通过路由权限来区分角色。管理员登录后能看到后台菜单普通用户只能看到商城页面。这么做的好处是部署简单不用维护两套前端应用也方便统一处理登录态。1.2 为什么是 SpringBoot Vue3而不是别的组合技术选型这件事我一直秉持“够用、顺手、好招人”的原则。SpringBoot 不用多说Java 后端在电商这块的生态太成熟了MyBatis-Plus 做单表 CRUD 几乎零成本Spring Security 或者简单的拦截器都能搞定鉴权数据库用 MySQL 也完全扛得住商城这个量级。前端选 Vue3 而不是 Vue2核心原因是组合式 API 在逻辑复用上太舒服了。商城这种业务购物车逻辑、登录态逻辑、商品筛选逻辑都是跨页面复用的用 composable自定义组合函数可以把这些逻辑抽出来比 Vue2 时代写 mixin 要清晰得多。配套的 Element Plus 组件库在后台管理界面上完全是量身定做表格、表单、弹窗、分页全都现成。还有一个很实际的原因Vue3 的生态现在已经很成熟了。Vite 的启动速度比 Webpack 快一个量级开发体验好很多。Pinia 相比 Vuex 的样板代码少了一大截修改状态不需要写一堆 mutation直接改 store 里的 state 就行这对商城这种状态交互频繁的场景特别友好。1.3 前后端分离的项目结构这样规划整个工程我拆成了两个目录互不干扰clothing-server/ # SpringBoot 后端工程 ├── src/main/java/com/cshop │ ├── controller/ # 接口层 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # MyBatis-Plus 数据访问层 │ ├── entity/ # 实体类 │ ├── dto/ # 前端传参对象 │ ├── vo/ # 返回给前端的数据对象 │ ├── config/ # 配置类跨域、拦截器、MyBatis-Plus │ ├── utils/ # JWT工具、统一返回结果封装 │ └── CShopApplication.java └── src/main/resources/ ├── application.yml └── mapper/ # 复杂SQL的XML文件 clothing-web/ # Vue3 前端工程 ├── src/ │ ├── api/ # 接口请求封装 │ ├── assets/ # 静态资源 │ ├── components/ # 通用组件商品卡片、分页等 │ ├── composables/ # 组合式函数购物车、登录态 │ ├── router/ # 路由配置含权限守卫 │ ├── stores/ # Pinia 状态管理 │ ├── views/ # 页面商城首页、商品详情、后台管理 │ └── utils/ # axios实例、工具函数 └── vite.config.js后端按“Controller → Service → Mapper”三层去写Controller 只管参数接收和结果返回业务逻辑全在 Service 层。这样后期如果要把某个接口拆成微服务或者引入消息队列做订单异步处理改动成本都控制得住。前端按“页面 → 组件 → API”分层所有请求都走src/api里封装的函数不放裸 axios 调用在页面里。2. 数据库设计与核心表建模2.1 商品表SPU 和 SKU 必须分开建商品建模是商城系统的地基这块设计错了后面全是坑。服装类商品有个典型特点一件卫衣SPU会有多个颜色、多个尺码每个颜色尺码组合对应一个价格和一份库存这就是 SKUStock Keeping Unit。如果把颜色尺码直接横着写在商品表里加一个颜色就要改表结构想想就头大。我建了两张表CREATE TABLE spu ( id bigint PRIMARY KEY AUTO_INCREMENT, name varchar(255) NOT NULL COMMENT 商品名称, category_id bigint COMMENT 所属类目ID, main_image varchar(255) COMMENT 主图URL, detail text COMMENT 商品详情富文本, status tinyint DEFAULT 1 COMMENT 1上架 0下架, create_time datetime DEFAULT CURRENT_TIMESTAMP, update_time datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ); CREATE TABLE sku ( id bigint PRIMARY KEY AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所属SPU, color varchar(50) COMMENT 颜色, size varchar(20) COMMENT 尺码, price decimal(10,2) NOT NULL COMMENT 售价, stock int NOT NULL DEFAULT 0 COMMENT 库存, image varchar(255) COMMENT SKU图片, status tinyint DEFAULT 1 );查询商品详情的时候先查 SPU 基本信息再根据 SPU ID 查 SKU 列表。前端展示的时候用color和size两个维度做联动选择。价格区间比如“199-299”可以直接用 SQLMIN(price)和MAX(price)聚合出来不用额外冗余字段。2.2 订单与库存表库存扣减的两种模式订单这块我用了电商最标准的“订单主表 订单明细表”结构另外单拆了一张购物车表。订单主表存收货人信息、订单总金额、订单状态明细表存每个 SKU 的购买数量、成交单价、商品快照。商品快照这个字段很重要因为商品价格、名称可能会变但历史订单里的信息必须保持下单那一刻的样子。CREATE TABLE orders ( id bigint PRIMARY KEY AUTO_INCREMENT, order_no varchar(64) NOT NULL UNIQUE COMMENT 订单号, user_id bigint NOT NULL, total_amount decimal(10,2) NOT NULL, status tinyint NOT NULL DEFAULT 0 COMMENT 0待付款 1已付款 2已发货 3已完成 4已取消, receiver_name varchar(50), receiver_phone varchar(20), receiver_address varchar(255), create_time datetime DEFAULT CURRENT_TIMESTAMP, pay_time datetime ); CREATE TABLE order_item ( id bigint PRIMARY KEY AUTO_INCREMENT, order_id bigint NOT NULL, spu_id bigint, sku_id bigint, sku_snapshot varchar(500) COMMENT SKU信息快照(JSON), goods_name varchar(255), price decimal(10,2), quantity int );库存扣减我选了下单时直接扣减的方案而不是支付时才扣。为什么因为支付是模拟的用户很可能“下单后不付款”如果库存不先锁住就会出现超卖10 件库存有 20 个人下单成功后面真正付款的人反而没货了。当然只扣不减也不行所以订单表里加了个超时状态超过 30 分钟未支付就把库存加回去这样既防止了超卖也避免了僵尸订单占用库存。2.3 用户与权限RBAC 模型在公司项目里最稳妥用户体系我没用复杂的方案就是标准的 RBAC用户-角色-菜单三张表加两张关联表。一个用户可以有多个角色一个角色可以访问多个菜单按钮。商城场景里只需要两种角色一个是ROLE_USER一个是ROLE_ADMIN但表结构我依然按通用 RBAC 来做方便后续加运营、客服这类角色。菜单表里直接存前端路由的path和组件路径登录后根据用户角色动态生成可访问的路由表前端配合路由守卫做菜单渲染和页面拦截。这样后期要加权限只需要在数据库里给角色挂菜单不用改代码。3. 后端核心模块实现要点3.1 JWT 登录认证与权限拦截拦截器比框架更省心登录接口的逻辑很直白接收用户名密码 → 查数据库比对密码MD5 加盐 → 生成 JWT 返回给前端。前端把 token 存在 localStorage 里之后每次请求在 axios 拦截器里加到请求头Authorization。后端我写了个AuthInterceptor实现HandlerInterceptor接口Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 放行登录、注册等接口 String uri request.getRequestURI(); if (uri.contains(/api/auth/login) || uri.contains(/api/auth/register)) { return true; } String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录); } // 解析token把用户ID放进去 Long userId JwtUtils.parseToken(token.replace(Bearer , )); request.setAttribute(userId, userId); return true; }有同学会问为什么不直接用 Spring Security说实话如果只是做用户认证和角色判断Spring Security 的配置成本远高于一个拦截器。Spring Security 适合权限规则很复杂的场景比如按钮级细粒度权限、OAuth2 第三方登录这个服装商城的管理端就两类角色拦截器里判断一下角色类型完全够了代码还更直观。如果以后要接入 Spring Security这两套逻辑也可以平滑替换。3.2 商品管理与文件上传OSS 和本地存储怎么选后台商品管理主要是商品的增删改查。图片上传我重点说一下因为这是最容易出 bug 的地方。文件上传选择有两条路一种是传到阿里云 OSS 这类对象存储适合部署在云服务器上的正式项目带宽和存储都有保障另一种是传到项目本地目录适合本地跑着玩或者部署在廉价服务器上的场景。我项目里做了一个折中图片保存到服务器磁盘的指定路径数据库只存访问 URL。配置文件里用upload.path指定存储路径再用一个WebMvcConfig把路径映射成静态资源访问registry.addResourceHandler(/images/**) .addResourceLocations(file: uploadPath /);这样图片就能通过http://localhost:8080/images/xxx.jpg直接访问了。部署到服务器的时候改一下配置路径即可不用动代码。上传接口最后会返回一个完整的图片 URL前端el-upload组件拿到 URL 后直接塞进表单字段里预览回显都很方便。3.3 下单流程与库存扣减事务和锁缺一不可下单是整个系统里最需要小心的环节。我的实现逻辑是这样的校验购物车里的 SKU 是否上架价格是否变化校验库存是否充足计算订单总金额创建订单主表和明细扣减 SKU 库存清空对应购物车记录这几步必须在一个事务里完成任何一步失败都要全部回滚否则会出现“订单建了但库存没扣”的脏数据。用Transactional注解包住整个方法另外在扣库存的 SQL 上加了条件判断UPDATE sku SET stock stock - #{quantity} WHERE id #{skuId} AND stock #{quantity}如果update影响行数为 0说明库存不足直接抛异常回滚这样在高并发下也不会超卖。这个写法比先查后改多了一层保障——查询和更新之间可能插入别的请求但带条件的 UPDATE 语句本身是原子性的。对于这个量级的项目来说它开箱即用且足够安全。3.4 统一返回结果与全局异常优雅接口的第一步接口风格统一是我一直强调的。我封装了一个ResultT类所有接口都返回统一的 JSON 结构{ code: 200, message: success, data: { } }同时用RestControllerAdvice做全局异常处理。业务异常返回对应的错误码和提示比如库存不足返回 5001未登录返回 401参数校验失败返回 400。这样前端只需要在 axios 响应拦截器里统一判断 code弹错误提示就行不需要每个接口单独写 try-catch。4. 前端 Vue3 落地实践4.1 Vite 初始化项目与目录规划前端工程我是用 Vite 初始化创建的命令也很简单npm create vitelatest clothing-web -- --template vue然后安装关键依赖npm install vue-router4 pinia axios element-plusVite 相比 Webpack 的启动速度确实快几秒就能起服务热更新也是毫秒级。有个要注意的地方是 Vite 的端口默认是 5173而后端接口跑在 8080所以必须在vite.config.js里配开发代理把/api前缀的请求转发到后端地址顺便解决跨域问题export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } })生产打包之后Nginx 里也配同样的代理规则前后端部署在不同端口时就不会有跨域烦恼。4.2 axios 封装与登录态刷新机制前端请求封装我习惯统一放在utils/request.js里。创建一个 axios 实例设置 baseURL 为/api然后加请求拦截器和响应拦截器const request axios.create({ baseURL: /api, timeout: 10000 }) // 请求拦截器自动带token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理业务错误和登录过期 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) } return res.data }, error { if (error.response error.response.status 401) { localStorage.removeItem(token) localStorage.removeItem(userInfo) router.push(/login) ElMessage.warning(登录已过期请重新登录) } return Promise.reject(error) } )401 统一跳转登录页的逻辑放在拦截器里能省掉每个页面判断 token 是否失效的重复代码。登录成功后把token和userInfo都存在 localStorage刷新浏览器也不会丢登录态。4.3 购物车与订单状态管理Pinia 比 localStorage 靠谱购物车状态我存在了 Pinia 里。为什么不直接用 localStorage两个原因一是购物车的状态需要多页面共享页面组件里用useCartStore()就能拿到跨组件通信成本为零二是购物车数量和选中状态需要响应式更新localStorage 没有响应式能力操作完还得手动刷新视图。购物车 store 的核心就是维护一个列表提供添加、删除、修改数量、勾选的方法。每次变更之后调后端接口同步同时也把最新状态同步一份到 localStorage 做持久化页面刷新后从 localStorage 恢复。这样既不丢失数据也保留了响应式的交互体验。export const useCartStore defineStore(cart, { state: () ({ items: JSON.parse(localStorage.getItem(cart_items) || []) }), actions: { addToCart(item) { const index this.items.findIndex(i i.skuId item.skuId) if (index -1) { this.items[index].quantity item.quantity } else { this.items.push(item) } this.save() }, removeItem(skuId) { this.items this.items.filter(i i.skuId ! skuId) this.save() }, save() { localStorage.setItem(cart_items, JSON.stringify(this.items)) } } })4.4 Element Plus 后台管理界面搭建后台管理页面其实就是典型的“左侧菜单 右侧内容区”布局。我用 Element Plus 的el-container、el-aside、el-menu搭框架商品管理用el-table展示数据配分页、搜索、弹窗编辑三个基础能力。订单管理在此基础上增加了筛选标签按状态过滤和操作按钮发货、查看详情。商品编辑表单里用到了el-upload上传图片:action指向后端的图片上传接口on-success回调里把返回的图片 URL 赋值给表单字段。这里有个细节el-upload上传组件走的是原生 XMLHttpRequest没法带上 axios 拦截器里的 Authorization 请求头所以要在组件上显式传headers属性el-upload :actionuploadUrl :headers{ Authorization: Bearer localStorage.getItem(token) } :on-successhandleUploadSuccess el-button上传图片/el-button /el-upload4.5 前端路由守卫没有登录就看不了后台动态路由权限这块我用的是最简单的方案在路由配置里给后台页面加meta: { requiresAuth: true, roles: [ROLE_ADMIN] }然后在全局前置守卫里判断router.beforeEach((to, from, next) { const token localStorage.getItem(token) const userInfo JSON.parse(localStorage.getItem(userInfo) || {}) if (to.meta.requiresAuth) { if (!token) { next(/login) } else if (to.meta.roles !to.meta.roles.includes(userInfo.role)) { next(/) } else { next() } } else { next() } })菜单渲染是在登录后根据userInfo.role来判断管理员显示全部菜单普通用户隐藏后台菜单入口。这套方案虽然不像动态路由那样能在后端配置菜单但应付两个角色的商城系统完全足够写起来也直观。5. 关键业务场景的实现细节5.1 多规格商品选择联动颜色和尺码怎么匹配 SKU服装商城最典型的交互场景就是选颜色选尺码。前端拿到商品详情后把当前 SPU 的所有 SKU 列表存在本地然后根据用户选择的颜色、尺码组合去匹配 SKU。匹配到了就显示价格和库存匹配不到就提示“该规格暂时缺货”。在 Vue3 里这个逻辑很适合放在computed里实现const selectedSku computed(() { return props.skus.find(s s.color selectedColor.value s.size selectedSize.value ) })下单时提交的是selectedSku.value.id而不是 SPU ID这个很关键。接口那边通过 SKU ID 才能查到准确的库存和价格否则就会出现“前端选了红色M码后端只收到了一个商品ID”这种尴尬情况。5.2 订单状态流转从待付款到已完成的全链路订单状态我定义了 5 个值流转关系是状态数值操作者说明待付款0用户下单后默认状态超时30分钟自动取消已付款1系统用户点击“模拟支付”后触发已发货2管理员后台订单列表点击“发货”已完成3用户/系统用户点击确认收货或发货后15天自动完成已取消4用户/系统用户主动取消或超时未支付后端在订单状态变更的接口里做了状态机校验比如不能从“待付款”直接跳到“已完成”只允许按顺序流转。这个校验放在 Service 层统一判断前端虽然做了按钮控制但必须防一手绕过前端的非法请求。5.3 销售数据统计接口管理端的点睛之笔除了常规 CRUD我给管理端加了一个数据统计面板首页展示订单总数、销售总额、用户总数、上架商品数四个指标。查询语句用 MySQL 的聚合函数写很简单// 今日销售总额 SELECT IFNULL(SUM(total_amount), 0) FROM orders WHERE status IN (1, 2, 3) AND pay_time CURDATE()再用一个近七天每日销售额的折线图接口返回日期和金额两个数组前端用 ECharts 渲染一下整个管理端的观感立刻就不一样了。这种统计功能技术上没有难度但对于商户来说这往往比那些花哨的表格更有价值也给项目加分不少。5.4 定时任务处理超时订单别让库存烂在池子里刚才提到订单超时未支付要释放库存这个功能我用 SpringBoot 自带的Scheduled定时任务来实现每 5 分钟扫描一次超过 30 分钟未支付的订单批量把状态改为已取消同时回补库存Scheduled(cron 0 */5 * * * ?) public void cancelTimeoutOrders() { ListOrder orders orderMapper.selectList(new LambdaQueryWrapperOrder() .eq(Order::getStatus, 0) .lt(Order::getCreateTime, LocalDateTime.now().minusMinutes(30))); for (Order order : orders) { // 回补库存、更新订单状态 orderCancelService.cancel(order.getId()); } }定时任务放在项目里简单直接缺点是做不到实时性极端情况下库存可能被锁定 34 分钟才释放。如果要求准确到秒级释放库存就得引入消息队列做延迟消息比如 RocketMQ 的延迟消息或者 Redis 的过期监听但那个复杂度就上去了。这个商城项目用定时任务已经够了我自己的体会是先满足业务需求再考虑技术炫技。6. 部署上线与常见问题排查6.1 本地联调与打包部署全流程开发完成后要跑通整套环境我先在本地起两个服务前端的 Vite 开发服务器5173和后端的 SpringBoot8080通过代理访问。联调没问题后进入生产模式后端打包mvn clean package -DskipTests java -jar clothing-server-1.0.0.jar前端打包npm run build打包产物在dist/目录下把dist里的文件复制到服务器 Nginx 的 html 目录然后配置 Nginxserver { listen 80; server_name your-domain.com; root /usr/share/nginx/html; index index.html; # 前端history路由 location / { try_files $uri $uri/ /index.html; } # 接口代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files $uri $uri/ /index.html;这行是 history 路由的关键不加的话刷新非首页路由会 404。这个坑我第一次部署踩过排查了半天最后发现就是少了这一句。6.2 常见问题速查表问题 1跨域请求被拦截表现浏览器 Console 提示 CORS error。原因通常是前端请求地址和后端地址不一致。解决方案优先用 Vite/Nginx 代理后端加CrossOrigin只是临时手段生产环境还是得靠代理解决。问题 2前端登录后刷新页面变回未登录原因Vuex/Pinia 里的数据是内存态的刷新就没了。解决token 和 userInfo 存在 localStorage页面启动时先从 localStorage 恢复 store 状态。问题 3表单提交时间字段显示一串数字原因MySQL 的 datetime 类型没有做时区转换Java 接收时解析成了时间戳。解决在 application.yml 里配置spring.jackson.date-format: yyyy-MM-dd HH:mm:ss和spring.jackson.time-zone: GMT8。问题 4商品图片上传成功但访问 404原因配置的upload.path不正确或者路径没映射到静态资源。解决确认磁盘绝对路径存在检查WebMvcConfig里的addResourceLocations必须file:前缀。问题 5部署到服务器后接口可以访问但图片加载失败原因Nginx 配置冲突location /把静态资源请求也接管了但找不到对应文件就返回 index.html。解决单独加一条图片路径的 locationlocation /images/ { alias /opt/clothing-upload/; }6.3 两个值得记住的实战经验第一个订单号别用自增 ID。订单表虽然id是自增主键但那只能用于内部关联展示给用户的订单号必须单独生成。网上很多教程直接用主键当订单号用户看到自己的订单一号二号三号很容易猜出平台有多少订单这在电商里是不专业的。我用的是“时间戳 随机数”的格式比如20241103152012345616 位数字简洁还挺好用。第二个所有数据库交互的金额字段必须用 decimal不能用 float 或 double。这是做电商系统的第一天就该养成的习惯。float 的二进制浮点误差在累计销售总额、计算优惠折扣时会放大到肉眼可见的错误用decimal(10,2)才能保证财务金额精确计算。类似地前端传价格时用“分”为单位整数传递到显示层再转成“元”这是很多大厂电商项目的统一规范既避免浮点误差也方便对接支付接口。7. 写在最后的个人体会这套服装商城销售管理系统做下来最大的收获不是掌握了某个具体技术点而是把电商业务里互相咬合的模块完整地理解了。比如订单和库存的关系、JWT 认证在前后端分离项目中的完整链路、后端事务和前端状态的配合这些知识单独学任何一门课都很难有这种“全局观”。对于想拿这个项目练手或者做毕设的同学我建议拿到代码后不要只跑通就结束而是尝试自己增加几个模块比如优惠券功能下单时抵扣金额、商品评论功能用户下单后评价晒图、收货地址管理多地址切换。这些扩展点每个都能单独写一套逻辑做完之后你对这套系统的理解会再上一个台阶。项目里最初的代码风格还有很多不规范的地方比如部分接口参数没有做校验、定时任务没有加分布式锁两台服务器部署时会重复执行、图片上传没有限制文件类型等等。我当时是在满足功能的前提下逐步优化、迭代加固的。对于个人项目或者毕设来说先把主链路跑通是第一优先级然后在这个基础上持续打磨项目的质量是一版一版“练”出来的。