看到“网上超市管理系统”这个标题，多数人的第一反应是：又是一个商城项目。但如果把SpringBoot、Vue、MyBatis、MySQL这四个词放在一起看，它其实是在讲一件事——如何用一套主流Java技术栈，把一个涉及商品、购物车、订单、库存、后台履约的完整业务闭环真正跑通。我见过不少类似的源码项目，页面不少、代码很多，可真走到下单发货那一步，库存对不上、订单状态乱跳、后台改完前端没反应，各种问题全冒出来。
这个项目的价值在于它没有停留在“增删改查演示”的层面，而是把用户端和后台管理端按真实超市系统的逻辑拆开了：用户负责逛、加购、下单、付款，管理员负责商品上下架、库存维护、订单发货、数据统计。对正在做毕业设计、课程设计，或者想拿一个完整项目去面试的人来说，它的参考价值不是“有个项目能交差”，而是让你看清一个真实商城系统在业务层、数据层、接口层分别应该怎么组织。
1. 先拆清业务盘子：网上超市的核心链路与功能边界
1.1 真正的核心链路：商品、购物车、订单、库存与履约
网上超市和普通企业官网最大的区别，是它必须围绕“交易”运转。用户看到商品、加入购物车、提交订单、完成支付、等待收货，这一条链路里每一个环节都依赖前一个环节的数据，任何一个节点断了，整个系统就是花架子。
我在帮某同学梳理类似项目时发现，他最开始的代码里商品、购物车、订单页面全都有，但用户下单之后库存没扣减，订单状态停在“待支付”，后台点发货也没有任何校验。原因很简单：所有操作都是独立的CRUD，没有把业务状态串起来。
真正可用的网上超市系统，至少要保证这条链路闭环：
- 用户注册登录后，能浏览商品、按分类筛选、搜索、加入购物车。
- 提交订单时，系统要校验库存、计算金额、生成订单号和订单明细。
- 支付环节哪怕是模拟支付，也要改变订单状态，并触发库存扣减或预占。
- 后台管理员按订单状态处理发货，发货后用户端能看到物流状态。
- 用户确认收货后订单完成，整套状态流转形成闭环。
这里最容易被低估的是“状态”的设计。订单不是一张静态表，它从待支付到已支付，再到已发货、已完成、已取消、已退款，每一步都需要有明确规则。状态设计不好，后面所有功能都会跟着乱。
1.2 功能边界：用户端和后台管理端各管什么
这类系统通常拆成两个端口：用户端（C端）和后台管理端（B端）。很多新手项目把两个端的页面混在一起，用户能打开商品管理，管理员能看到购物车，这就是角色边界没划清。
合理的功能分配应该是这样的：
| 端 | 角色 | 核心功能 |
|---|---|---|
| 用户端 | 普通用户 | 注册登录、商品浏览检索、购物车管理、提交订单、模拟支付、查看订单进度、个人资料维护 |
| 后台管理端 | 管理员 | 商品上下架与编辑、分类管理、库存调整、订单查询与发货、用户管理、销售数据统计 |
两个端口可以共用同一套后端接口，但必须通过权限做隔离。普通用户请求后台接口应该直接被拦截，管理员也不该在用户端执行下单操作。这个边界会直接影响登录鉴权方案的设计，后面第四章我会展开讲。
1.3 “企业级”在这个项目里到底指什么
标题里“企业级”三个字，听起来很唬人，其实放到这套技术栈里，它表达的不是微服务、分布式、高并发那套东西，而是几个更实际的要求：
- 前后端分离，职责清晰，接口有统一返回值格式。
- 权限控制到位，用户和管理员的登录态严格分开。
- 关键业务操作有事务保护，比如下单、扣库存、生成明细必须同生共死。
- 数据库设计符合第三范式的基本要求，核心字段有约束。
- 项目能脱离开发者的本机环境干净打包部署。
换句话说，企业级的意思是“可以拿去演示运营的完整度”，而不是“堆了多少微服务组件”。这一点在答辩或面试时其实很值钱：能讲清楚订单状态机和事务边界，比说自己用过十个开源框架更有说服力。
2. 技术选型复盘：这一套组合赢在哪
2.1 后端：SpringBoot解决配置焦虑，MyBatis保留SQL掌控感
SpringBoot在这类系统里几乎是默认选项，原因不是它功能多，而是它把配置成本压到了最低。以前写SSM（Spring、SpringMVC、MyBatis）项目，光XML配置就能让人折腾一天；换成SpringBoot之后，内嵌Tomcat、自动装配、约定优于配置，一套下来项目骨架几分钟就能立起来。
但SpringBoot只是基础，数据访问层的选择才是这个项目的关键点。用MyBatis而不是JPA、Hibernate，不少人是出于“SQL可控”的考虑。商城系统里有很多查询是动态的，比如商品列表要根据分类、价格区间、关键字组合过滤，后台销售统计要按天聚合，甚至要多表联查订单和商品明细。用MyBatis写SQL，每一条查询都清清楚楚，出了问题直接拿出来跑一遍就能定位，不像ORM框架一旦映射配置出错，排查起来隔了一层。
MyBatis这种半自动化的定位，恰好适合这种业务规则明确的系统。它不替你做决策，但把你从JDBC的重复代码里解放出来。配合XML里写动态SQL，复杂查询的灵活性非常高。
2.2 前端：Vue的组件化正好匹配商城页面与管理后台
前端选Vue，我觉得是这一类项目里最自然的选择。商城前台有商品卡片、购物车列表、订单详情这种高复用组件，后台有表格、弹窗、表单这类管理界面，Vue的组件化思路让这些页面可以拆成独立模块维护。和传统jQuery拼页面比起来，状态管理清楚得多，数据更新之后视图自动同步，不用手动操作DOM。
当然，选Vue也有一层现实原因：生态成熟。和Element UI这类组件库配合，后台管理界面几乎是“拼积木”式开发。一个商品列表页，表格组件加上分页组件加上弹窗表单，半天就能搭完，剩下的精力可以留给业务逻辑。对做毕设或者项目练手来说，这个效率很重要。
2.3 MySQL：量级合适，事务支持够用，演示直观
数据量级上，网上超市这种项目撑死也就几千种商品、几万条订单，MySQL处理这点数据绰绰有余。真正让它成为标配的，是它既有关系型数据库的完整性约束，又有InnoDB引擎提供的事务支持。
下单这种业务最怕的就是“操作一半失败”。比如用户下了一个订单，商品明细写进去了，库存也扣了，但订单主表插入失败，那整个操作就是脏数据。MySQL的InnoDB配合Spring的@Transactional声明式事务，可以保证这几个操作要么全成功，要么全回滚。这个点在项目中基本是必讲的亮点。
另外，MySQL的部署难度低，工具链成熟，可视化客户端随便选。相比PostgreSQL可能还要额外解释一下，MySQL在Java开发圈里几乎不需要多费口舌。
2.4 后端一次请求的完整路径
不管前端页面上点什么按钮，最终都会变成一个HTTP请求，落到后端某个接口上。我建议新手在脑子里建立这条链路：
浏览器发起请求，Vue前端根据路由渲染页面并调用Axios发起接口请求，请求到达后端的Controller层，Controller只负责接收参数和返回结果，具体业务判断交给Service层，Service调用Mapper接口，Mapper通过MyBatis把SQL交给MySQL执行，结果再逐层返回。
Controller、Service、Mapper三层分离是这个架构的核心。Controller里不写SQL，Service里不放SQL语句，Mapper只专注数据库操作。这样分工的好处是，出问题的时候能快速定位：接口参数不对找Controller，业务逻辑不对找Service，SQL语句不对找Mapper。
3. 数据库设计的关键取舍：从用户表到订单明细
3.1 核心表清单：一张表看清业务实体
数据库设计是这种系统能不能跑稳的地基。网上超市的核心实体其实不复杂，我习惯先列清单再讨论细节：
| 表名 | 用途 | 关键字段 |
|---|---|---|
| t_user | 用户表 | id、username、password、nickname、phone、avatar、create_time |
| t_category | 商品分类表 | id、name、parent_id、sort |
| t_product | 商品表 | id、category_id、name、subtitle、main_image、price、stock、status |
| t_cart_item | 购物车表 | id、user_id、product_id、quantity、checked、create_time |
| t_order | 订单主表 | id、order_no、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、create_time |
| t_order_item | 订单明细表 | id、order_id、product_id、product_name、product_image、current_price、quantity |
| t_stock_log | 库存变动日志 | id、product_id、change_count、type、order_no、create_time |
下面这张表是骨架，实际开发还会加地址表、管理员表、轮播图表之类的，但核心交易链路就是这些。
3.2 订单主表与明细表为什么必须拆
很多人会问，订单里直接存一个商品列表字段不行吗？不行。原因是订单和商品之间是多对多关系：一个订单包含多个商品，一个商品对应多个订单。如果强行塞进一个字段，查询、统计、对账都会很难受。
拆成订单主表和订单明细表之后，一个订单的信息分成两层：主表存订单的全局信息，比如订单号、总金额、收货人、订单状态；明细表存这个订单里的每一行商品，包括商品名、购买数量、成交单价。查询订单列表时只查主表，查询某个订单的详细信息时再关联明细表，逻辑非常清楚。
为什么明细表里要冗余保存商品名称、图片、价格？因为商品信息是会变的。用户买的时候是29.9元，半年后商品涨价到39.9元，订单里的成交价不能跟着变。把下单那一刻的商品快照存进明细表，才能保证历史订单永远可追溯。
3.3 库存扣减时机：下单扣还是支付扣
这是商城系统里一个经典设计问题，网上超市这种项目里也值得认真选。
方案一是提交订单时立刻扣库存。优点是库存数据实时准确，预售不会超卖；缺点是用户可能下单不付款，库存被无效占用，导致真正想买的人买不到。
方案二是支付成功后扣库存。优点是不会占用库存；缺点是在待支付期间，同一件商品可能被多个用户同时下单，等支付的时候才发现库存不足，用户对体验会很差。
毕设和多数业务演示场景里，我更推荐方案一，也就是创建订单时扣减库存，同时给订单加一个超时自动取消的定时任务。这样逻辑上最好解释：订单创建即占用库存，支付失败或超时取消则回补库存。实现上不需要太复杂的分布式锁，只要在扣库存的SQL里加上库存足够的条件判断就够了。
3.4 容易被忽略的字段细节
数据库设计里，最影响系统健壮性的往往不是表多不多，而是字段设计细不细。
金额字段一定要用Decimal而不是float或double。二进制浮点数在计算金额时会产生精度误差，比如0.1加0.2可能得到0.30000000000000004，这在订单金额上是不允许的。Decimal(10,2)能保证金额精确到分。
用户表和商品表建议加status字段做软删除。用户注销不是真的删掉数据，而是把状态改成禁用；商品下架也是改状态，而不是物理删除，否则历史订单里的商品信息会变成无源之水。
所有表都要有create_time，涉及更新的表放update_time。排序、做统计、排查数据问题的时候，时间字段几乎是第一线索。
订单表的主键不要直接用自增id对外暴露，建议生成一个独立的order_no，比如时间戳加随机数。一方面订单号需要唯一且看起来规范，另一方面也避免别人通过id号猜测你的订单量级。
4. 业务落地：购物车、订单与后台履约的代码实现
4.1 登录鉴权与权限隔离怎么落地
这类前后端分离项目，我建议直接用JWT做登录态，而不是传统的Session。原因很简单：Session依赖服务端存储，前后端分离之后，前端可能部署在另一台机器上，用Session还要考虑会话同步问题。JWT是无状态的，用户登录成功后后端生成一个Token返回给前端，前端后续请求都在Header里带上这个Token，后端通过拦截器解析Token就能识别用户身份。
Controller层之上，可以加一个拦截器统一处理。核心逻辑是：请求进来先放行登录、注册这类接口，其他请求都需要校验Token。校验通过之后，从Token里解析出用户id和角色，放进ThreadLocal或者请求上下文，后面的Service层随时可以用。
后台管理员的权限要跟普通用户严格分开。一个项目里的做法是接口上标注角色要求，拦截器里做二次判断。管理员请求用户接口不做限制，但用户Token请求后台管理接口必须拒绝。
4.2 购物车转订单：从校验到事务
购物车转订单是业务逻辑最密集的一段，也是事务保护的核心区域。简单描述一下完整步骤：
用户勾选购物车中若干商品，点击结算，前端把选中的商品id列表传给后端。后端拿到请求后，先查出这些商品的最新信息，逐项校验商品是否还在上架状态、库存是否充足。然后用事务把这些操作包起来：生成订单主表记录，批量生成订单明细，扣减商品库存，最后清空购物车中对应的商品项。
代码层面的示意大概是这样：
@Transactional public Order createOrderFromCart(Long userId, List<Long> cartItemIds) { // 1. 查询购物车选中项，关联商品表 // 2. 逐项校验商品状态与库存 // 3. 计算订单总金额 // 4. 插入订单主表，生成订单号 // 5. 插入订单明细表，保存商品快照 // 6. 扣减商品库存（使用条件更新的SQL） // 7. 删除购物车中的已下单项 }其中第6步扣减库存的SQL要特别小心，不能用“先查再改”的方式，那在并发场景下会出问题。正确写法是用一条条件更新语句，把库存足够作为更新条件。这一点第五章会单独展开。
事务的存在意义是：如果第5步或第6步任何一步失败，前面几步全部回滚。用户不会看到“订单生成了但库存没扣”这种诡异状态。
4.3 订单状态机：状态枚举与流转规则
订单状态不建议用魔法值散落在代码里，我习惯建一个枚举类统一管理。常见的状态定义如下：
| 状态码 | 含义 | 可以流转到 |
|---|---|---|
| 0 | 待支付 | 1、4 |
| 1 | 已支付（待发货） | 2、5 |
| 2 | 已发货 | 3 |
| 3 | 已完成 | 无 |
| 4 | 已取消 | 无 |
| 5 | 已退款 | 无 |
状态流转的方向必须由后端控制，不能前端随便改。比如只有支付接口能把待支付改成已支付，只有后台发货接口能把已支付改成已发货，用户端不能自己调用接口把订单改成已完成。
一个简单的状态枚举示意：
public enum OrderStatus { PENDING_PAYMENT(0, "待支付"), PAID(1, "已支付"), SHIPPED(2, "已发货"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"), REFUNDED(5, "已退款"); private final int code; private final String desc; // 构造方法、getter }写业务代码时，所有涉及状态变更的地方都用枚举，不要用数字写死在if里。这样做的直接好处是：项目做完了，你还能一眼看出这个订单走到哪一步了。
4.4 后台端的商品管理与发货操作
后台管理端的核心工作流其实不复杂，但很能体现系统完整度。商品管理包括新增商品、编辑信息、上传图片、设置上下架状态、调整库存。这些操作都落到t_product表上，唯一要注意的是商品图片处理，一般选择上传到本地目录或者对象存储，数据库里只保存图片访问路径。
订单管理是后台最重要的模块。管理员打开订单列表，按状态筛选出“已支付”的订单，确认收款无误后点击发货，填写物流单号，订单状态变成“已发货”。用户在用户端刷新就能看到状态变化。
这一套操作在技术上不难，但它验证的是整个系统的数据联动能力。后台改一条数据，用户端就查得到，这才是管理系统的意义。
5. 联调部署最容易翻车的几个位置
5.1 跨域CORS：前后端分离的第一道坎
如果你本地启动Vue项目用的是8080端口，SpringBoot用的是9090端口，浏览器就会认为这两个站点的“源”不同，后端就得开启跨域支持。这个问题几乎每个做前后端分离项目的人都遇到过。
最省心的方式是在后端写一个全局CORS配置类，允许前端地址跨域访问，同时允许携带凭证。要注意的是通配符*虽然能解燃眉之急，但在需要携带Token的场景下可能会失效，最好明确指定允许的请求头。
5.2 MyBatis分页插件：多表关联时字段冲突
后台商品列表、订单列表都需要分页。项目里如果用PageHelper这类插件，单表查询基本无脑配置就行，但一旦涉及多表联查，就很容易踩坑。
常见问题有两类。一类是关联查询时两张表有同名字段，比如商品表和订单明细表都有product_name，分页插件生成count查询时可能因为字段歧义直接报错。解决办法是在SQL里给字段加别名，明确指定t_product.name AS product_name。另一类是分页插件使用不当导致SQL被包了一层子查询，性能下降。排查思路是先打印出MyBatis执行的完整SQL，把它复制到数据库客户端里单独跑一遍，很容易就能看出问题在哪。
5.3 并发扣库存：超卖是怎么发生的
如果你写的是“先查库存，判断大于0再减”，那么在高并发场景下一定会超卖。两个用户同时查到库存还有1件，都判断可以买，然后都执行扣减，结果一个商品卖了两单。
解法是让扣减操作具备原子性，用一条SQL完成检查和更新：
UPDATE t_product SET stock = stock - 1 WHERE id = #{productId} AND stock > 0;这条SQL执行后，如果受影响行数为0，说明库存不足，下单失败；如果受影响行数为1，说明扣减成功。把判断库存的逻辑交给数据库，而不是Java代码，才能从根上避免并发问题。对毕设级别的项目来说，这个方案简单有效，也很好在答辩时讲清楚。
5.4 Token过期与前端拦截器
JWT有一个特点：Token一旦生成，在有效期内无法主动作废。用户Token过期之后，前端不能只是弹出一个报错，而是应该统一处理。
前端Axios可以做一个响应拦截器，后端返回401状态码时，自动清理本地Token并跳转登录页。这样用户正在结算时Token过期，系统不会抛一个看不懂的报错，而是提示重新登录，登录之后还能回到之前的页面。
axios.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } return Promise.reject(error) } )顺带提醒一点：JWT的密钥要放到后端配置文件里，不要硬编码在代码中；密钥长度不要太短，否则很容易被暴力破解。
5.5 打包部署前的本地验证清单
项目做完不等于能交付，部署之前要把下面这些场景完整走一遍。我每次做同类系统都会按这个清单过，省去很多交付后的问题：
- 新用户注册，老用户登录，错误密码有提示。
- 商品按分类、关键字、价格区间查询都正常。
- 购物车加购、改数量、删除、勾选状态刷新后还在。
- 下单时库存充足和库存不足两种情况都验证一次。
- 模拟支付成功，订单状态从待支付变成已支付。
- 后台发货后，用户端能看到订单状态更新。
- 超时未支付订单会自动取消，库存回补。
- 连续多次快速下单同一件商品，库存不会变成负数。
如果这些场景全部通过，系统就具备交付条件了。后端用mvn clean package打成可执行jar包，前端用npm run build打成静态资源，配一个Nginx做反向代理，整套系统就能顺利跑起来。
我个人的体会是，这类网上超市项目，最大的坎往往不是某个技术点不会，而是业务链路没走通时，出了问题不知道去哪里查。数据库设计、事务边界、状态流转，这三样东西梳理清楚了，剩下的大多是体力活。最后分享一个最实用的小建议：先把一个订单从创建到发货再到用户确认收货的完整链路跑通，再去补那些花哨的页面和统计图表。项目是否扎实，评估的人往往不看你写了多少页面，只看一个核心流程能不能顺畅走下来。
