SpringBoot+Vue猫咪商城管理系统：全栈项目设计与实战拆解

讲一个最近我在整理项目时反复上手的一个典型的Java全栈实战项目——基于SpringBootVue的猫咪商城管理系统。带全套文档、答辩PPT和源码的那种。说实话这类项目在毕业设计、课程设计里非常常见宠物电商、二手交易、校园商城换一层皮核心骨架几乎一样。但大多数人做出来的版本只停留在“能跑通”的层面代码结构一团乱事务注解乱加权限接口裸奔前端页面全是复制粘贴。这篇我就把这个项目从设计思路、技术拆解到实际实现完整过一遍重点讲文档里不会写、但答辩和面试时很容易被追问的那些东西。这个系统能做什么一句话概括一个前后端分离的猫咪用品商城包含用户端浏览商品、加入购物车、下单支付模拟、订单管理以及管理端商品管理、分类管理、订单处理、用户管理和数据统计。适合谁参考准备做毕设的在校生、想补一个完整全栈项目的求职者或者想快速搭一套电商demo做二次开发的开发者。无论你是想拿它交差还是想真正搞懂一套商用级业务系统的落地过程这篇都有参考价值。先说一下我拿到这类项目后的拆解习惯不急着看代码先看数据库表和接口文档再看前端路由和后端控制器的对应关系最后才去抠细节。原因很简单商城系统的业务链路是固定的——用户登录、逛商品、加购、下单、支付、发货、收货所有功能都是围绕这条链路展开的。只要把这条链路的数据流和状态流转搞清楚整个项目的代码就是水到渠成的事。1. 这个商城系统到底做了什么从项目定位看整体设计思路1.1 业务场景与核心需求解析猫咪商城系统的业务场景本质上是一个典型的B2C电商模型。前台面向普通消费者后台面向运营管理员和商家。之所以选“猫咪”这个主题核心原因是宠物用品类目的商品属性比较直观——有品类猫粮、猫砂、玩具、日用品、有品牌、有图片、有价格库存天然适合做商品管理和订单管理。核心需求可以拆成两个端来看。用户端要实现的能力注册登录、浏览商品列表和详情、按分类筛选、搜索商品、管理收货地址、加入购物车、提交订单、模拟支付、查看订单状态待付款/待发货/待收货/已完成、申请退款或确认收货。这些功能看着多但归纳起来就是“商品购物车订单”三条主线的CRUD加上状态流转。管理端要实现的能力管理员登录、商品上架下架、商品信息编辑、库存修改、分类管理、处理用户订单发货、关闭退款、查看用户列表、查看销售统计报表。管理端的核心是“对数据和状态做受控操作”每一笔修改都要有权限校验和操作记录这一点在答辩时特别容易被问到。这个系统对初学者的友好之处在于它的业务边界非常清晰没有复杂的支付网关对接没有分布式事务没有消息队列所有模块都是单体架构下的标准实现。但它并不简陋该有的RBAC权限控制、JWT身份认证、乐观锁处理库存、事务控制都有涉及刚好卡在“课程设计之上、企业级项目之下”的位置拿来练手和学习都非常合适。1.2 为什么选前后端分离SpringBootVue的组合逻辑做这类项目第一件事是选型。SpringBootVue的组合在当下已经是事实上的标准答案原因并不复杂。后端用SpringBoot看中的是它的生态整合能力。内置Tomcat不需要额外配置容器SpringMVC负责接口层MyBatis或MyBatis-Plus负责数据访问SpringSecurity或拦截器方案负责权限这些组件全部可以靠starter依赖一键引入配置简化到极致。对一个单体商城系统来说SpringBoot的约定大于配置能省掉大量重复劳动让你把精力集中在业务逻辑上。前端用Vue核心理由是组件化开发和生态成熟。Vue渐进式的特点让项目可以从简单的页面渲染逐步扩展到完整的单页应用。配合Vue Router做路由跳转、Vuex或Pinia做状态管理、Axios做HTTP请求、Element UI做管理后台的组件库整个前端的开发效率和维护性都远高于传统JSPJQuery的模式。前后端分离还有一个实际好处接口层面的职责划分清晰。后端只产出JSON数据前端只负责渲染和交互两边可以并行开发。在项目时间紧张的时候比如毕设季这个优势能救命。1.3 适合谁参考、能学到什么根据我的经验参考这个项目的受众大概分三类学习重点完全不同。第一类是毕设学生核心诉求是快速完成一个完整系统并且能通过验收。这类人应该重点研究数据库设计和接口设计把业务链路的闭环讲清楚答辩时这部分的权重最高。第二类是求职者想把项目写进简历做技术亮点。这类人不能停留在跑通阶段要深入理解权限控制的实现、库存并发扣减方案、事务隔离级别的应用场景面试官深挖的往往是这些点。第三类是准备做二次开发的开发者想在这个骨架上加功能或者换皮。这类人最关心的是代码结构的清晰度和可扩展性比如商品类型能不能扩展、订单状态是不是配置化、接口是否遵循Restful规范。不管哪一类我都建议你拿到项目后先花一小时读SQL文件和application配置文件再用Swagger或接口文档把所有接口过一遍。这样做的好处是快速建立全貌后面看代码不会迷路。2. 后端核心拆解SpringBoot如何撑起订单、库存和权限2.1 项目分层与包结构设计后端代码的包结构是这个项目里最容易被低估的部分。很多人交上来的代码把所有类堆在controller和service两个包下看着也能跑但一旦要改需求就痛苦不堪。一个规范的分层结构应该是这样的com.example.petmall ├── common // 通用模块统一返回结果、全局异常、工具类 │ ├── result // Result、ResultCode │ ├── exception // 业务异常、全局异常处理器 │ └── utils // JwtUtil、StringUtil等 ├── config // 配置类CorsConfig、WebMvcConfig、InterceptorConfig ├── controller // 接口层按业务模块分包 │ ├── admin // 管理端接口 │ └── user // 用户端接口C端 ├── service // 业务层接口实现类 │ ├── impl // ServiceImpl ├── mapper // 数据访问层 ├── entity // 数据库实体类 ├── dto // 数据传输对象接收前端参数 └── vo // 视图对象返回前端数据这套结构背后的逻辑其实是对应“职责分离”的原则。Controller只做参数接收和结果封装不写业务逻辑Service层承载业务规则事物注解放在这一层Mapper只做数据操作不做跨表复杂查询复杂查询用XML文件写SQLEntity对应数据库表结构VO按需裁剪返回字段。我见过很多项目直接用Entity返回给前端这在简单的demo里问题不大但一旦字段多了就会暴露两个坑一是可能把密码、手机号这类敏感字段泄露出去二是前端拿到的字段和页面需要的字段对不上逼着你写一堆多余代码去拼装。正确做法是定义VO哪怕字段大部分相同也要做一层隔离。2.2 JWT身份认证与权限控制的完整实现这是答辩和面试的高频考点值得单独拆开讲。商城系统天然分为管理员和普通用户两类角色接口必须做权限控制。比如普通用户不能调用商品上架接口管理员不能随便改别人的个人信息。常见方案有三种SessionCookie、TokenRedis、JWT拦截器。这个项目用的是JWT拦截器方案。JWT的工作流程是这样的用户登录成功后后端用用户ID、用户名、角色等信息生成一个签名字符串返回给前端前端每次请求在请求头里带上这个字符串后端通过拦截器统一解析验证并把用户信息放进请求上下文方便后续业务代码获取当前用户。具体实现分三步。第一步登录接口生成Token。关键代码大致如下// 用户登录成功后生成JWT String token JwtUtil.createToken(user.getId(), user.getUsername(), user.getRole());JWT的结构是三段式Header.Payload.Signature。Header声明加密算法Payload放业务数据Signature做防篡改校验。创建Token时要设置过期时间商城类项目一般设置为2小时或24小时太短影响体验太长有安全风险。第二步写一个拦截器拦截所有需要认证的请求public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 从Header取token String token request.getHeader(Authorization); if (token null || token.isEmpty()) { throw new BusinessException(ResultCode.UNAUTHORIZED); } // 解析并校验token过期或不合法直接抛异常 Claims claims JwtUtil.parseToken(token); request.setAttribute(userId, claims.get(userId)); request.setAttribute(userRole, claims.get(role)); return true; } }第三步在WebMvcConfig里注册拦截器并配置放行路径registry.addInterceptor(new JwtInterceptor()) .addPathPatterns(/api/**) .excludePathPatterns(/api/user/login, /api/user/register, /api/goods/list);这里有个容易踩的坑一定要把图片上传处理、文件下载这类接口放行否则前端加载图片会全部失败。我见过一个项目把所有静态资源请求都拦了结果首页图片全挂排查了半天才发现是拦截器把/images/**拦掉了。权限控制这块简单项目可以直接在拦截器里判断角色复杂一点可以引入Spring Security JWT的方案。但对于这个商城系统拦截器判断角色已经足够而且更容易给面试官讲清楚“从请求到响应经历哪些环节”。2.3 商品、购物车、订单三大核心业务逻辑商品模块相对简单核心是列表查询和详情查询。列表要支持分页、分类筛选、关键词搜索、价格排序这块用MyBatis-Plus的LambdaQueryWrapper配合Page对象就能搞定。// 商品列表查询支持分页分类关键词 PageGoods page new Page(pageNum, pageSize); LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(categoryId), Goods::getCategoryId, categoryId) .like(StringUtils.isNotBlank(keyword), Goods::getName, keyword) .orderByDesc(Goods::getCreateTime); goodsService.page(page, wrapper);购物车模块要把握的关键是购物车是临时性数据存Redis还是存MySQL都行。用MySQL实现简单直观建一张cart表关联userId和goodsId加入购物车前先查是否已存在相同商品存在则数量加一否则插入新纪录。这里需要做唯一索引或者先查后判否则会出现重复记录。订单模块是整个系统最复杂的部分。一个完整的下单流程涉及四个表订单主表、订单明细表、商品表扣库存、购物车表清空。这四个操作必须放在同一个事务里任何一步失败都要全部回滚。核心逻辑大致如下Transactional(rollbackFor Exception.class) public Order createOrder(OrderCreateDTO dto) { // 1. 校验收货地址、计算总金额 // 2. 创建订单主记录状态为待付款 // 3. 创建订单明细从购物车读取商品 // 4. 扣减商品库存带库存校验 // 5. 清空对应购物车记录 // 6. 返回订单给前端跳转支付 }订单状态流转是答辩必问的点。这个项目的订单状态一般有待付款、待发货、待收货、已完成、已取消、退款中/已退款。状态流转必须由后端控制前端只能发起动作不能直接改状态。比如“取消订单”只能在待付款状态执行已发货之后要取消必须走售后流程——这个规则写在Service层里判断当前状态是否允许目标状态流转。3. 前端双端实现Vue管理后台与C端商城的协作方式3.1 前端项目结构与工程化配置前端代码一般拆成两个独立项目一个是面向消费者的商城端一个是面向管理员的后台管理端。拆分的好处是权限边界清晰构建和部署也互不影响。用户端项目结构petmall-user ├── public ├── src │ ├── api // 按模块封装的接口请求 │ ├── assets // 静态资源 │ ├── components // 复用组件 │ ├── router // 路由配置 │ ├── store // Vuex/Pinia状态管理 │ ├── utils // 请求封装、工具函数 │ └── views // 页面组件 │ ├── home │ ├── goods │ ├── cart │ ├── order │ └── user管理端结构类似只是views下面换成dashboard数据看板、goodsManage、orderManage、userManage、categoryManage这类后台页面。Element UI在管理端里几乎是标配表格、表单、弹窗、分页、消息提示这些后台高频组件全都现成开发效率非常高。两个项目共用一个后端接口服务通过axios实例统一配置baseURL和认证头。这里有个很实用的细节axios的拦截器里做两件高频操作——请求前自动附加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) { // 未登录或token过期时跳转登录页 if (res.code 401) { router.push(/login) } Message.error(res.message) return Promise.reject(new Error(res.message)) } return res })这个拦截器是整个前端的“基础设施”所有页面的请求都会经过它。好处是业务代码里不需要重复写错误弹窗和登录状态判断省事而且统一。3.2 用户端核心页面与交互链路用户端的核心页面交互链路是首页 → 商品列表 → 商品详情 → 购物车 → 结算页 → 支付结果 → 订单列表 → 订单详情。首页要展示轮播图、分类入口、热门商品推荐。数据来源一般有三个接口轮播图接口可以做成配置化的Banner管理、分类列表接口、商品推荐接口。如果后台没做Banner管理功能也可以把轮播图写成前端静态数据但答辩时“为什么不做成动态”这个问题可能不好解释所以最好还是做上。商品详情页的关键交互是选规格和数量。这里需要前端和后端配合规格数据存在商品表的某个JSON字段里或单独的表里前端渲染规格选择器用户选定后实时计算价格和库存。如果规格比较复杂颜色、尺寸、版本等维度组合推荐用规格表规格值表的设计否则可以简化为商品表里的skuJson字段。购物车页面重点是选中项的前端状态管理。用户勾选哪些商品去结算这个状态必须记录在Vuex/Pinia里因为跳转到结算页之后还需要知道“本次结算的商品是哪几个”。实现方式有两种一种是从购物车列表带参跳转把选中的购物车ID用Query参数传给结算页另一种是把选中商品临时存到全局状态里。两种都行我更推荐第二种因为数据量小且在刷新页面时会清空逻辑更干净。3.3 管理端数据看板与技术要点管理端最亮眼的页面往往是数据看板。用ECharts画销售趋势折线图、分类占比饼图、商品销量排行柱状图视觉效果很好答辩时几乎必讲。数据看板的后端接口需要写聚合查询SQL。比如近30天销售趋势核心是统计已支付订单按日期分组的销售金额SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS day, SUM(pay_amount) AS total FROM order WHERE status 已支付 AND create_time DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY DATE_FORMAT(create_time, %Y-%m-%d)这类查询在MyBatis里建议用XML文件写因为SQL语句表名关键字冲突order是MySQL保留字必须加反引号和日期格式化这些细节在注解SQL里容易出错。管理端还有一个高频操作是商品图片上传。上传功能涉及后端文件存储和前端表单组件这里重点提醒一个坑后端接收图片的接口要配置上传大小限制SpringBoot默认单文件最大1MB商品图片随随便便就超过。在application.yml里调大限制spring: servlet: multipart: max-file-size: 10MB max-request-size: 20MB另外上传后的图片要存到服务器磁盘的固定目录比如/home/upload/并在WebMvcConfig里把这个目录映射为静态资源访问路径。千万不要把图片Base64编码直接存数据库会拖慢查询而且数据库体积膨胀得离谱。4. 数据库设计与核心逻辑从表结构到并发扣库存4.1 核心表结构设计与字段规范这个商城系统的数据库设计是另一个答辩高频区。你不需要设计得像企业级那么复杂但核心表必须齐全、字段命名必须规范、表间关系必须合理。核心表大致如下表名用途关键字段user用户表id, username, password, nickname, avatar, phone, role, create_timeaddress收货地址表id, user_id, receiver_name, receiver_phone, province, city, detail, is_defaultcategory商品分类表id, name, parent_id, sort_ordergoods商品表id, category_id, name, subtitle, main_image, price, stock, sales, status, detailcart购物车表id, user_id, goods_id, quantity, checkedorder订单表id, order_no, user_id, total_amount, pay_amount, status, address_snapshot, create_timeorder_item订单明细表id, order_id, goods_id, goods_name, goods_image, price, quantitybanner轮播图表id, image_url, link_url, sort_order, status几个设计要点值得单独说。订单表为什么要存address_snapshot地址快照因为用户在多个订单里可能修改了地址历史订单必须保留下单那一刻的地址信息。如果只存address_id去关联地址表地址一变历史订单就全乱了。这个细节看起来小但在答辩时讲出来会明显加分。订单号不要用自增ID直接展示给用户。自增ID会暴露订单量而且不利于多表合并。项目里用时间戳随机数的方案生成order_no格式类似202411091530456789这个可以单独写一个工具类。商品表的status字段用来做上下架。下架的商品在用户端列表里不显示但已经加入购物车的商品在购物车里可以提示“已下架”。这里不需要物理删除商品逻辑删除和状态控制就够了。4.2 库存扣减的并发问题与乐观锁方案这个点必须在文章里单独标出来因为它既是项目里真正的技术难点也是面试官爱问的地方。场景是多个用户同时下单购买同一个商品库存只有5件但可能有10个人同时提交订单。如果代码写成普通的“查库存→判断足够→扣减”高并发下就会出现超卖库存变成负数。基本盘逻辑是错的必须加并发控制。常见的方案有三种数据库悲观锁、乐观锁、Redis分布式锁。商城系统单机部署的话用乐观锁是最合适的。乐观锁的核心是在商品表加一个version字段更新库存时带上版本号比对UPDATE goods SET stock stock - #{quantity}, version version 1 WHERE id #{goodsId} AND version #{oldVersion} AND stock #{quantity}这条SQL会返回影响行数。如果影响行数为0说明版本号不是最新或者库存不足下单失败需要重新读取库存再尝试。用MyBatis-Plus实现时在实体类加Version注解然后配置乐观锁插件即可但自己手写SQL其实更直观也更容易讲清楚。悲观锁方案SELECT ... FOR UPDATE在单机场景下也能用但锁的粒度大、并发能力差而且要求事务必须在整个锁范围内使用不当容易造成死锁。分布式锁对这个项目来说属于杀鸡用牛刀除非你打算写简历说“使用Redisson实现分布式锁”否则不建议引入。4.3 事务控制哪些操作必须放在同一个事务里下单链路是最典型的事务场景创建订单主表、创建订单明细、扣库存、清空购物车四步操作必须全部成功。任何一个失败数据库都会停留在不一致的状态——比如订单建了但库存没扣后面就无法发货。SpringBoot里事务控制很简单Transactional注解搞定。但有三个细节必须注意。第一事务注解一定要加在Service层的实现类方法上不能加在Controller上也不能加在Mapper上。放在Controller会导致事务范围过大且层次混乱放在Mapper则根本没有事务边界每一条SQL自动提交。第二Transactional默认只回滚RuntimeException和Error如果代码里抛的是自定义的CheckedException或者手动catch了异常没有重新抛出事务会照常提交。所以我一般习惯指定rollbackFor Exception.class明确告诉Spring所有异常都回滚。第三事务方法内不能自己调用自己。Spring的事务是基于AOP代理实现的如果A方法调用了本类里的B方法B有事务注解事务不会生效。原因是代理对象没有拦截这次内部调用。我见过一个下单方法把扣库存子方法写在同一个类里结果库存不扣减但订单创建成功就是这个原因。5. 从本地到上线部署流程与典型问题排查实录5.1 本地运行全套流程从Maven打包到前端构建拿到项目先别急着跑按这个顺序来基本不会出问题。第一步初始化数据库。用Navicat或命令行导入项目里附带的SQL文件确认所有表都建好最好插入一些测试数据否则前端页面一片空白看不出效果。第二步配置后端。修改application.yml里的数据库连接信息改成你自己本地MySQL的用户名、密码和库名。另外检查Redis配置如果项目用到了Redis做缓存或token存储的话没有Redis就先注释掉相关依赖或改成本地默认配置。第三步启动后端。直接跑Application主类看到SpringBoot启动成功的日志后用Swagger或Postman测一个登录接口确保接口通了再继续。第四步启动前端。前端项目要在命令行执行npm install安装依赖然后npm run serve启动开发服务器。如果npm install报错大概率是node版本和项目要求的版本不匹配优先检查node版本。项目要求的版本看package.json里engines字段或者直接问作者。第五步联调。浏览器访问前端地址注册一个用户登录逛一下商品和下单流程确认前后端接口通、数据能正常显示。管理端用管理员账号登录测一下商品上架和订单发货。整个流程走下来大约半小时到一小时前提是环境没问题。如果卡住大概率是端口占用、MySQL版本兼容、Node版本三类问题下面会专门说。5.2 部署到服务器前后端分离的Nginx配置部署上线是很多人没做过但非常值得做的一步做完以后整个项目的完整度提升一大截。部署思路是后端打包成jar包跑在服务器上前端构建成静态文件交给Nginx托管Nginx再把接口请求反向代理到后端的端口。后端打包mvn clean package -DskipTests打包成功后target目录下会生成一个jar包用java -jar xxx.jar就能启动。前端构建npm run build构建产物在dist目录把dist文件夹里的内容上传到服务器的某个目录比如/var/www/petmall/。Nginx配置的核心片段server { listen 80; server_name your-domain.com; # 前端静态文件 root /var/www/petmall; index index.html; # 所有/api请求反向代理到后端 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 图片访问路径 location /images/ { alias /home/upload/; } }需要注意的坑proxy_pass的URL结尾有没有斜杠会影响路径拼接。写成http://127.0.0.1:8080没有斜杠请求会保持原路径转发给后端写成带斜杠的http://127.0.0.1:8080/会把/api前缀去掉再转发。后端的Controller如果定义的是/api/goods/listNginx转发的目标路径就必须是/api/goods/list两种配置都能实现但语义不同务必事先想清楚。前端路由还要处理一个问题Vue Router使用history模式时刷新页面会出现404。需要在Nginx里加一个try_files回退location / { try_files $uri $uri/ /index.html; }否则每次刷新子页面都会白屏我第一次部署项目时在这个坑上卡了很久。5.3 高频问题排查配置参考问题现象主要排查方向解决办法登录成功后请求其他接口返回401未登录或Token过期或拦截器放行路径配置错误检查拦截器放行规则检查Token过期时间检查axios请求头字段名是否与后端读取的一致前端跨域报错本地联调时前后端端口不同在WebMvcConfig里配置Cors跨域允许或使用Vue的proxy代理商品图片加载失败图片上传后未配置静态资源映射或Nginx路径不对后端配置静态资源映射Nginx配置alias指向上传目录数据库时区报错MySQL和SpringBoot时区不一致连接串加serverTimezoneAsia/Shanghai下单后库存没变事务没生效或SQL更新条件有问题检查Transactional是否加在public方法上检查乐观锁SQL的版本号和库存条件端口被占用上次运行的后端进程未关闭Windows查端口PID后killLinux用kill -9这里再补一个容易忽略的点后端启动报身份认证或缓存相关的错误先检查Redis是否启动。部分商城项目集成Spring Session或token存储需要Redis没启Redis服务直接会连不上。6. 这个项目还可以怎么改扩展思路与实际体会把这些基础流程走通之后有几个扩展方向我觉得很值得做性价比高且能明显提升项目的差异化程度。第一个方向是支付模块的完善。目前项目通常用模拟支付即点击支付按钮后直接把订单状态改为已支付可以升级接入真实的第三方支付沙箱环境。沙箱环境的接入流程和真实环境几乎一致但不需要真实商户号答辩时讲出来会让人眼前一亮。第二个方向是加一个简单的消息提醒机制。比如用户下单成功后给管理员发送一条站内通知或者订单发货后给用户发短信。直接用定时轮询或者简单的WebSocket推送就能实现不需要引入消息队列。第三个方向是把商品首页的推荐逻辑从“固定查询”改成“按销量或热度排序”再进一步可以按用户浏览记录做简单的协同过滤推荐。这个扩展涉及一点算法但不算深做出来写在简历上很加分。我个人在实际操作中的体会是这类带文档和PPT的完整项目最大的价值不是你交上去那一刻的验收结果而是你把每一行代码、每一个表字段、每一个接口都过一遍之后对“一个完整的业务系统是怎么从零到一落地”这件事情的理解。我会强烈建议你拿到源码后先自己重新建一个数据库从零开始写一遍后端的商品查询和下单流程不参考源码写完再对照。这个过程虽然慢但比看十遍别人的代码都有效。最后分享一个答辩和面试屡试不爽的小技巧准备一张手绘或思维导图的系统架构图把“用户→前端页面→接口层→Service层→Mapper层→数据库”这条路径画出来然后用一句话讲清楚数据是怎么流动的。这张图一出来基本没有人会认为这个项目你是纯抄的——你真正懂了讲出来的气场是完全不一样的。