讲一个最近我在整理项目时反复上手的一个典型的Java全栈实战项目——基于SpringBoot+Vue的猫咪商城管理系统。带全套文档、答辩PPT和源码的那种。说实话，这类项目在毕业设计、课程设计里非常常见，宠物电商、二手交易、校园商城，换一层皮核心骨架几乎一样。但大多数人做出来的版本只停留在“能跑通”的层面，代码结构一团乱，事务注解乱加，权限接口裸奔，前端页面全是复制粘贴。这篇我就把这个项目从设计思路、技术拆解到实际实现完整过一遍，重点讲文档里不会写、但答辩和面试时很容易被追问的那些东西。

这个系统能做什么？一句话概括：一个前后端分离的猫咪用品商城，包含用户端浏览商品、加入购物车、下单支付（模拟）、订单管理，以及管理端商品管理、分类管理、订单处理、用户管理和数据统计。适合谁参考？准备做毕设的在校生、想补一个完整全栈项目的求职者，或者想快速搭一套电商demo做二次开发的开发者。无论你是想拿它交差，还是想真正搞懂一套商用级业务系统的落地过程，这篇都有参考价值。

先说一下我拿到这类项目后的拆解习惯：不急着看代码，先看数据库表和接口文档，再看前端路由和后端控制器的对应关系，最后才去抠细节。原因很简单，商城系统的业务链路是固定的——用户登录、逛商品、加购、下单、支付、发货、收货，所有功能都是围绕这条链路展开的。只要把这条链路的数据流和状态流转搞清楚，整个项目的代码就是水到渠成的事。

1. 这个商城系统到底做了什么：从项目定位看整体设计思路

1.1 业务场景与核心需求解析

猫咪商城系统的业务场景本质上是一个典型的B2C电商模型。前台面向普通消费者，后台面向运营管理员和商家。之所以选“猫咪”这个主题，核心原因是宠物用品类目的商品属性比较直观——有品类（猫粮、猫砂、玩具、日用品）、有品牌、有图片、有价格库存，天然适合做商品管理和订单管理。

核心需求可以拆成两个端来看。

用户端要实现的能力：注册登录、浏览商品列表和详情、按分类筛选、搜索商品、管理收货地址、加入购物车、提交订单、模拟支付、查看订单状态（待付款/待发货/待收货/已完成）、申请退款或确认收货。这些功能看着多，但归纳起来就是“商品+购物车+订单”三条主线的CRUD加上状态流转。

管理端要实现的能力：管理员登录、商品上架下架、商品信息编辑、库存修改、分类管理、处理用户订单（发货、关闭退款）、查看用户列表、查看销售统计报表。管理端的核心是“对数据和状态做受控操作”，每一笔修改都要有权限校验和操作记录，这一点在答辩时特别容易被问到。

这个系统对初学者的友好之处在于，它的业务边界非常清晰，没有复杂的支付网关对接，没有分布式事务，没有消息队列，所有模块都是单体架构下的标准实现。但它并不简陋，该有的RBAC权限控制、JWT身份认证、乐观锁处理库存、事务控制都有涉及，刚好卡在“课程设计之上、企业级项目之下”的位置，拿来练手和学习都非常合适。

1.2 为什么选前后端分离：SpringBoot+Vue的组合逻辑

做这类项目，第一件事是选型。SpringBoot+Vue的组合在当下已经是事实上的标准答案，原因并不复杂。

后端用SpringBoot，看中的是它的生态整合能力。内置Tomcat，不需要额外配置容器；SpringMVC负责接口层，MyBatis（或MyBatis-Plus）负责数据访问，SpringSecurity或拦截器方案负责权限，这些组件全部可以靠starter依赖一键引入，配置简化到极致。对一个单体商城系统来说，SpringBoot的约定大于配置能省掉大量重复劳动，让你把精力集中在业务逻辑上。

前端用Vue，核心理由是组件化开发和生态成熟。Vue渐进式的特点让项目可以从简单的页面渲染逐步扩展到完整的单页应用。配合Vue Router做路由跳转、Vuex或Pinia做状态管理、Axios做HTTP请求、Element UI做管理后台的组件库，整个前端的开发效率和维护性都远高于传统JSP+JQuery的模式。

前后端分离还有一个实际好处：接口层面的职责划分清晰。后端只产出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文件写SQL）；Entity对应数据库表结构，VO按需裁剪返回字段。

我见过很多项目直接用Entity返回给前端，这在简单的demo里问题不大，但一旦字段多了就会暴露两个坑：一是可能把密码、手机号这类敏感字段泄露出去；二是前端拿到的字段和页面需要的字段对不上，逼着你写一堆多余代码去拼装。正确做法是定义VO，哪怕字段大部分相同，也要做一层隔离。

2.2 JWT身份认证与权限控制的完整实现

这是答辩和面试的高频考点，值得单独拆开讲。

商城系统天然分为管理员和普通用户两类角色，接口必须做权限控制。比如普通用户不能调用商品上架接口，管理员不能随便改别人的个人信息。常见方案有三种：Session+Cookie、Token+Redis、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对象就能搞定。

// 商品列表查询：支持分页+分类+关键词 Page<Goods> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Goods> 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 核心表结构设计与字段规范

这个商城系统的数据库设计是另一个答辩高频区。你不需要设计得像企业级那么复杂，但核心表必须齐全、字段命名必须规范、表间关系必须合理。

核心表大致如下：

几个设计要点值得单独说。

订单表为什么要存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/list，Nginx转发的目标路径就必须是/api/goods/list，两种配置都能实现但语义不同，务必事先想清楚。

前端路由还要处理一个问题：Vue Router使用history模式时，刷新页面会出现404。需要在Nginx里加一个try_files回退：

location / { try_files $uri $uri/ /index.html; }

否则每次刷新子页面都会白屏，我第一次部署项目时在这个坑上卡了很久。

5.3 高频问题排查配置参考

这里再补一个容易忽略的点：后端启动报身份认证或缓存相关的错误，先检查Redis是否启动。部分商城项目集成Spring Session或token存储需要Redis，没启Redis服务直接会连不上。

6. 这个项目还可以怎么改：扩展思路与实际体会

把这些基础流程走通之后，有几个扩展方向我觉得很值得做，性价比高且能明显提升项目的差异化程度。

第一个方向是支付模块的完善。目前项目通常用模拟支付，即点击支付按钮后直接把订单状态改为已支付，可以升级接入真实的第三方支付沙箱环境。沙箱环境的接入流程和真实环境几乎一致，但不需要真实商户号，答辩时讲出来会让人眼前一亮。

第二个方向是加一个简单的消息提醒机制。比如用户下单成功后给管理员发送一条站内通知，或者订单发货后给用户发短信。直接用定时轮询或者简单的WebSocket推送就能实现，不需要引入消息队列。

第三个方向是把商品首页的推荐逻辑从“固定查询”改成“按销量或热度排序”，再进一步可以按用户浏览记录做简单的协同过滤推荐。这个扩展涉及一点算法但不算深，做出来写在简历上很加分。

我个人在实际操作中的体会是，这类带文档和PPT的完整项目，最大的价值不是你交上去那一刻的验收结果，而是你把每一行代码、每一个表字段、每一个接口都过一遍之后，对“一个完整的业务系统是怎么从零到一落地”这件事情的理解。我会强烈建议你拿到源码后，先自己重新建一个数据库，从零开始写一遍后端的商品查询和下单流程，不参考源码，写完再对照。这个过程虽然慢，但比看十遍别人的代码都有效。

最后分享一个答辩和面试屡试不爽的小技巧：准备一张手绘或思维导图的系统架构图，把“用户→前端页面→接口层→Service层→Mapper层→数据库”这条路径画出来，然后用一句话讲清楚数据是怎么流动的。这张图一出来，基本没有人会认为这个项目你是纯抄的——你真正懂了，讲出来的气场是完全不一样的。