不是毕业设计模板，也不是网上那些Ctrl+C就能跑的教学项目。我最近刚把一个服装销售平台管理系统从零搭完，项目代号就叫“衣依”，技术栈是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工具类，里面定义了一个Map，key是当前状态，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 统一返回结果与异常处理前后端分离项目里，接口返回格式必须统一，否则前端解析起来会非常痛苦。我在“衣依”系统里定义了一个Result<T>类，结构就是最常见的三件套：code、message、data。成功时code为200，失败时code为500，业务异常用400系列区分。配合全局异常处理器@RestControllerAdvice，业务代码里只要抛出我们自定义的BusinessException，就会被统一捕获并转成标准结果返回。比如下单时库存不足，我就直接throw new BusinessException("库存不足")，前端拿到的就是{"code": 500, "message": "库存不足", "data": null}。这样每个接口少写一堆try-catch，代码干净很多。4.3 商品模块：分页查询与条件检索商品列表页是管理后台的核心页面，运营人员需要按照名称、分类、价格区间、状态这些条件筛选商品。对应的后端接口是一个典型的分页条件查询。public PageResult<Product> queryProductPage(ProductQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); List<Product> list = productMapper.selectByCondition(query); return new PageResult<>(list); }对应的MyBatis XML里，我用<where>加<if>动态拼接查询条件，核心逻辑是这样的：<select id="selectByCondition" resultType="com.yiyi.entity.Product"> SELECT * FROM product <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="minPrice != null"> AND price >= #{minPrice} </if> <if test="maxPrice != null"> AND price <= #{maxPrice} </if> <if test="status != 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调用方法B，B上加的@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-permission="0" type="danger" @click="handleDelete">删除</el-button>v-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-if="scope.row.status === 1" size="mini" type="primary" @click="handleShip(scope.row)">发货</el-button> <el-button v-if="scope.row.status === 1 || scope.row.status === 0" size="mini" type="danger" @click="handleCancel(scope.row)">取消</el-button>这里有一个很容易犯的错：按钮状态只在前端控制，后端接口却没有对应校验。如果后端不校验“已发货订单不允许取消”，那么有人绕过前端直接调取消接口，业务就出问题了。所以我在后端订单状态流转的service方法里做了同样的状态校验，前端提示是引导，后端校验才是底线。订单详情的展示我用了一个el-drawer抽屉，从右侧滑出，里面用el-descriptions展示收货人信息、商品明细、金额明细、时间信息。比弹窗更自然，也比跳转新页面更轻量。建议你在做详情展示时也优先考虑抽屉，体验比弹窗好。6. 部署上线与常见问题排查6.1 本地联调与跨域处理前后端分离开发时，最大的痛点就是跨域问题。开发阶段前端跑在localhost:8080（Vue脚手架默认端口），后端跑在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的写法之后，并发问题就消失了。第三个是数据库连接配置时区的问题。我第一次部署时用的连接串里没有加serverTimezone=Asia/Shanghai，结果时间字段全部比北京时间少了8个小时。排查了一圈才发现是MySQL连接时区配置不对，在连接串里加上时区参数后重启服务就正常了。这个问题不仔细排查很难发现，因为系统能跑、数据能查、订单能出，只有时间对不上，而且不是一直对不上，是差整8小时。建议所有项目从一开始就在连接串里把时区写明确，不要依赖默认值。7. 功能和代码可以怎么扩展“衣依”系统算是跑通了一个完整的管理系统闭环：从数据库设计到后端接口，再到前端页面和部署上线。但这个项目其实还有很大的扩展空间，我按业务价值排了优先级，供你参考。排在前面的是数据可视化。目前系统里只有订单和库存的列表，只回答了“现在是什么情况”，没有回答“最近趋势怎么样、哪些商品卖得好”。接一个ECharts或者AntV，把订单金额按天统计出来，把商品销售排行用柱状图展示，整个系统的价值会立刻上一个台阶。我在表结构设计时已经预留了订单创建时间字段，统计查询只需要一条GROUP BY语句就能出数据。其次是移动端适配。管理后台目前在PC浏览器上体验最好，但很多老板习惯用手机看数据。建议用响应式布局改一改表单和表格，或者在后台单独做一个移动端适配页面，至少让关键数据在手机上有最简单的展示。再往后是消息通知。下单成功、订单发货、库存低于阈值这些事件可以对接短信或微信模板消息推送，让运营人员不用一直盯着后台。扩展这类功能时，我建议用Spring Boot的事件发布和监听机制，在业务代码里publishEvent抛事件，监听器里异步处理发送，业务主流程不会被阻塞。代码层面，我建议你把权限功能升级一下，从“固定三种角色”改为“角色和菜单权限分别建表”的动态权限模型。也就是每次登录后，从数据库查出当前角色能访问的菜单和按钮权限，动态生成路由和权限指令。这个改动适合作为后台系统的长期演进方向，但不建议一上来就做，先把固定角色的逻辑跑稳了再说。回到开头那句话，做管理系统最怕的不是技术不会，而是需求不清就动手、表结构没想明白就写代码、前后端权限只做一边。我在“衣依”项目里踩过的那些坑，绝大部分都来源于这些基础问题。如果这篇文章能帮你少走一次弯路，那我觉得这几个小时写得还挺值。
不是毕业设计模板，也不是网上那些Ctrl+C就能跑的教学项目。我最近刚把一个服装销售平台管理系统从零搭完，项目代号就叫“衣依”，技术栈是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工具类，里面定义了一个Map，key是当前状态，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 统一返回结果与异常处理前后端分离项目里，接口返回格式必须统一，否则前端解析起来会非常痛苦。我在“衣依”系统里定义了一个Result<T>类，结构就是最常见的三件套：code、message、data。成功时code为200，失败时code为500，业务异常用400系列区分。配合全局异常处理器@RestControllerAdvice，业务代码里只要抛出我们自定义的BusinessException，就会被统一捕获并转成标准结果返回。比如下单时库存不足，我就直接throw new BusinessException("库存不足")，前端拿到的就是{"code": 500, "message": "库存不足", "data": null}。这样每个接口少写一堆try-catch，代码干净很多。4.3 商品模块：分页查询与条件检索商品列表页是管理后台的核心页面，运营人员需要按照名称、分类、价格区间、状态这些条件筛选商品。对应的后端接口是一个典型的分页条件查询。public PageResult<Product> queryProductPage(ProductQuery query) { PageHelper.startPage(query.getPageNum(), query.getPageSize()); List<Product> list = productMapper.selectByCondition(query); return new PageResult<>(list); }对应的MyBatis XML里，我用<where>加<if>动态拼接查询条件，核心逻辑是这样的：<select id="selectByCondition" resultType="com.yiyi.entity.Product"> SELECT * FROM product <where> <if test="name != null and name != ''"> AND name LIKE CONCAT('%', #{name}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="minPrice != null"> AND price >= #{minPrice} </if> <if test="maxPrice != null"> AND price <= #{maxPrice} </if> <if test="status != 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调用方法B，B上加的@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-permission="0" type="danger" @click="handleDelete">删除</el-button>v-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-if="scope.row.status === 1" size="mini" type="primary" @click="handleShip(scope.row)">发货</el-button> <el-button v-if="scope.row.status === 1 || scope.row.status === 0" size="mini" type="danger" @click="handleCancel(scope.row)">取消</el-button>这里有一个很容易犯的错：按钮状态只在前端控制，后端接口却没有对应校验。如果后端不校验“已发货订单不允许取消”，那么有人绕过前端直接调取消接口，业务就出问题了。所以我在后端订单状态流转的service方法里做了同样的状态校验，前端提示是引导，后端校验才是底线。订单详情的展示我用了一个el-drawer抽屉，从右侧滑出，里面用el-descriptions展示收货人信息、商品明细、金额明细、时间信息。比弹窗更自然，也比跳转新页面更轻量。建议你在做详情展示时也优先考虑抽屉，体验比弹窗好。6. 部署上线与常见问题排查6.1 本地联调与跨域处理前后端分离开发时，最大的痛点就是跨域问题。开发阶段前端跑在localhost:8080（Vue脚手架默认端口），后端跑在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的写法之后，并发问题就消失了。第三个是数据库连接配置时区的问题。我第一次部署时用的连接串里没有加serverTimezone=Asia/Shanghai，结果时间字段全部比北京时间少了8个小时。排查了一圈才发现是MySQL连接时区配置不对，在连接串里加上时区参数后重启服务就正常了。这个问题不仔细排查很难发现，因为系统能跑、数据能查、订单能出，只有时间对不上，而且不是一直对不上，是差整8小时。建议所有项目从一开始就在连接串里把时区写明确，不要依赖默认值。7. 功能和代码可以怎么扩展“衣依”系统算是跑通了一个完整的管理系统闭环：从数据库设计到后端接口，再到前端页面和部署上线。但这个项目其实还有很大的扩展空间，我按业务价值排了优先级，供你参考。排在前面的是数据可视化。目前系统里只有订单和库存的列表，只回答了“现在是什么情况”，没有回答“最近趋势怎么样、哪些商品卖得好”。接一个ECharts或者AntV，把订单金额按天统计出来，把商品销售排行用柱状图展示，整个系统的价值会立刻上一个台阶。我在表结构设计时已经预留了订单创建时间字段，统计查询只需要一条GROUP BY语句就能出数据。其次是移动端适配。管理后台目前在PC浏览器上体验最好，但很多老板习惯用手机看数据。建议用响应式布局改一改表单和表格，或者在后台单独做一个移动端适配页面，至少让关键数据在手机上有最简单的展示。再往后是消息通知。下单成功、订单发货、库存低于阈值这些事件可以对接短信或微信模板消息推送，让运营人员不用一直盯着后台。扩展这类功能时，我建议用Spring Boot的事件发布和监听机制，在业务代码里publishEvent抛事件，监听器里异步处理发送，业务主流程不会被阻塞。代码层面，我建议你把权限功能升级一下，从“固定三种角色”改为“角色和菜单权限分别建表”的动态权限模型。也就是每次登录后，从数据库查出当前角色能访问的菜单和按钮权限，动态生成路由和权限指令。这个改动适合作为后台系统的长期演进方向，但不建议一上来就做，先把固定角色的逻辑跑稳了再说。回到开头那句话，做管理系统最怕的不是技术不会，而是需求不清就动手、表结构没想明白就写代码、前后端权限只做一边。我在“衣依”项目里踩过的那些坑，绝大部分都来源于这些基础问题。如果这篇文章能帮你少走一次弯路，那我觉得这几个小时写得还挺值。