基于SpringBoot+Vue的超市管理系统：库存并发、权限与报表实践

简介：面向毕业设计场景的SpringBoot+Vue超市管理系统源码包，适合计算机专业学生、Java全栈初学者及需要完整项目案例的开发者，用于完成商品库存、销售、会员、促销与供应链等模块的设计与实现，也可作为前后端分离项目的参考模板。压缩包共2000个文件、约23.17MB，包含61个Java后端类、43个Vue组件，以及大量js、css、xml、json、sql和配置文件，分别对应接口逻辑、页面样式、组件视图、依赖描述、数据库初始化与运行参数，目录组织较完整。已有87人学习，说明该案例具备一定参考价值；读者可据此梳理SpringBoot自动配置、Vue组件化开发与前后端联调思路，并借助SQL脚本和项目结构理解超市业务模块划分、员工权限管理、库存实时监控、销售报表统计及系统参数设置等功能的实现方式，适合对照搭建、二次改造或撰写毕业设计文档。

1. 需求与边界：一套超市管理系统到底要接住哪些柜台动作

带过几届毕业设计之后，我发现最容易在答辩现场被问住的不是框架版本号，而是“你这套系统到底替谁省了哪一步”。超市管理系统的麻烦之处就在这：题目听着简单，真正动手时需求会从“商品增删改查”膨胀成收银、库存、会员、供应商、报表五摊事，每摊都能单独做一篇。所以这套基于 SpringBoot + Vue 的超市管理系统，一开始就得把边界划清楚——它服务的是一家中型社区超市，三到五个收银台、两三千个 SKU、每天几百单流水，核心目标只有一句：让“卖出去多少”和“库里还剩多少”这两件事始终对得上。它适合拿来做毕业设计或课程设计的完整交付，也适合想练一遍前后端分离全流程的人照着改。下面按架构、库表、后端、前端、避坑、验收的顺序，把这份方案展开讲。

2. 总体架构与技术选型：前后端分离的四层结构与六大模块职责

架构这一章最容易写成名词解释，我一般会直接跳过“什么是 MVC”，从“一个请求进来之后经过哪些文件”讲起。这套系统走标准前后端分离：浏览器加载 Vue 打包出的静态资源，页面里的请求打到/api/**，SpringBoot 侧用 JWT 校验身份后进入 Controller，Controller 调 Service，Service 调 Mapper，Mapper 落到 MySQL。中间没有任何模板渲染，也没有 Session——这是整套方案后面所有设计的前提，包括权限、跨域、登录状态续期。

2.1 分层结构：Controller / Service / Mapper / Entity 各管什么

Java 侧严格四层，职责不能串。Controller 只做参数接收、校验和统一响应包装；Service 承载业务规则和事务边界；Mapper 只写 SQL，不写 if-else；Entity 与 DTO、VO 分离，实体类不直接返回给前端。

@RestController @RequestMapping("/api/product") public class ProductController { private final ProductService productService; public ProductController(ProductService productService) { this.productService = productService; } // 分页查询：size 做上限保护，防止前端传 size=99999 把连接池打满 @GetMapping("/page") public Result<PageResult<ProductVO>> page(@RequestParam(defaultValue = "1") Integer page, @RequestParam(defaultValue = "10") Integer size, @RequestParam(required = false) String keyword, @RequestParam(required = false) Long categoryId) { size = Math.min(size, 100); return Result.ok(productService.pageQuery(page, size, keyword, categoryId)); } // 新增商品：@Valid 触发 DTO 上的校验注解，失败由全局异常处理器统一兜住 @PostMapping public Result<Long> save(@RequestBody @Valid ProductDTO dto) { return Result.ok(productService.saveProduct(dto)); } }

Result是统一响应包装，固定 code / message / data 三个字段，前端 axios 拦截器只认这三个键。ProductVO和ProductDTO分开的意义在于字段可见性：商品表里有成本价，收银员角色不该看到，VO 里就没有这个字段，而不是靠前端隐藏。参数上，keyword同时匹配商品名和条码，categoryId用来配合左侧分类树联动，size的 100 上限是硬编码在 Controller 里的，属于那种“加上去只要一行、不加以后一定出事”的保护。

提示：不要在 Controller 里写业务判断，哪怕只有一行“库存是否为 0 就返回错误”。这一行以后会长成二十行，而且会出现在三个不同的 Controller 里。

2.2 技术选型：每一层为什么是它

选型不追求新，追求“毕设周期内能写完、答辩时讲得清、出问题查得到”。这套组合的实际考虑如下：

真正需要解释的是 MyBatis-Plus 这一项。很多同学一上来选 JPA，单表查询很爽，但报表模块要写“按日聚合销售额、按品类算毛利、按供应商统计入库量”，这类 SQL 用 JPA 要么写原生查询，要么拼 Criteria，反而更绕。MyBatis-Plus 的定位是：简单表用BaseMapper省事，复杂统计直接写在 XML 里，两套并存不打架。

2.3 模块划分：六大业务模块与单向依赖

模块按业务动作切，不按技术层切。基础数据模块管商品、分类、供应商；库存模块管入库、出库、盘点、库存流水；收银模块管购物车、结算、挂单、退货；会员模块管等级、积分、储值；报表模块管日销、品类、毛利；系统模块管用户、角色、菜单、操作日志。

依赖方向必须单向：收银依赖库存和商品，报表只读依赖收银和库存，系统模块被所有人依赖但不能反向依赖任何业务模块。这条规则听起来抽象，落到代码上就是——ReportService里可以注入OrderMapper，但OrderService里绝不能注入ReportService。一旦出现反向依赖，后面加个“结算后刷新报表缓存”就会变成循环调用。

2.4 前端工程结构：目录组织与路由分层

前端目录按职责分，不按页面堆：

src/ api/ 按后端模块拆分的请求函数，一个模块一个文件 router/ 静态路由（登录、404）+ 动态路由（按角色注入） store/ Pinia：user（登录态）、cart（购物车）、dict（字典缓存） layout/ 侧边栏、顶栏、面包屑、标签页 views/ 页面组件 utils/ request.js（axios 封装）、auth.js（token 读写）

路由这一层有两个设计点值得说清楚：静态路由只放登录页和错误页，业务路由全部由后端返回的菜单树动态注入；每条路由的meta.roles只用于前端菜单过滤，不作为安全边界。

// src/router/index.js export const constantRoutes = [ { path: '/login', component: () => import('@/views/login/index.vue') }, { path: '/', component: Layout, children: [ // 收银台：管理员和收银员都能进，退货按钮在组件内部再按角色判断 { path: 'cashier', name: 'Cashier', component: () => import('@/views/cashier/index.vue'), meta: { title: '收银台', roles: ['ADMIN', 'CASHIER'] } } ] } ]

meta.roles的作用是“看不见”，后端@PreAuthorize的作用才是“拦得住”。这两件事必须分开做，只做前者就是权限越界，后面第 5 章会专门讲这个坑。

3. 数据库设计：商品、库存、订单、会员、供应商、用户六条主线的表结构与字段取舍

库表设计是这套系统里最不该省事的部分。毕设常见做法是“一个商品表塞所有字段”，写到收银模块就会发现库存扣不动、订单金额对不上。这里的划分原则是：凡是会随时间变化、需要留痕的数据，一律单独建表。

3.1 商品与分类：条码唯一，成本价单独收口

product表存商品主体，category表用parent_id做自关联形成分类树（一般两层够用：大类 + 小类）。商品表的关键字段取舍：

金额一律用decimal，不用double。这不是讲究，是必修课——double累加几百条明细之后会出现 0.01 的偏差，对账时找不到原因，很容易变成说不清的问题。

3.2 库存表：为什么不在商品表加一个 stock 字段

很多人的第一版就是product.stock，写到“入库、出库、盘点、退货”四类动作时就崩了：库存变了，但不知道是谁、什么时候、因为哪一单变的。正确做法是两张表——stock存当前余量（商品 ID + 仓库 ID 唯一），stock_log存每一次变动流水（变动类型、变动数量、变动前后值、关联业务单号）。

-- 库存流水表：所有库存变动必须落一条，退货、盘点、报损都不例外 CREATE TABLE stock_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, change_type TINYINT NOT NULL COMMENT '1入库 2销售出库 3退货入库 4盘点调整 5报损', change_qty INT NOT NULL COMMENT '正数增加，负数减少', before_qty INT NOT NULL, after_qty INT NOT NULL, biz_no VARCHAR(32) DEFAULT NULL COMMENT '关联单号，销售出库时存订单号', create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_product_time (product_id, create_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

before_qty和after_qty这两个字段看起来冗余，但它们是排查问题时唯一能提供依据的数据。库存对不上时，沿着流水一条条看，哪一步错的立刻清楚；只有change_qty的话，只能从最新值往前倒推，出了错就是难查。

3.3 订单与明细：金额快照字段一个都不能省

order存订单头（订单号、会员 ID、收银员 ID、应收、实收、优惠、支付方式、状态），order_item存明细（商品 ID、商品名、单价、数量、小计）。这里的关键设计是快照：明细表里的product_name和unit_price是下单那一刻复制过来的，不是关联查询出来的。

原因很直接——商品明天可能改名，下周可能调价，但三个月前的订单必须还能还原成当时的样子。同理，订单头里的total_amount、discount_amount、pay_amount都是计算后落库的，不在查询时现算，否则一旦促销规则改了，历史订单金额会跟着变。

3.4 会员、供应商、用户：三张表不要合并

新手容易把“会员”和“系统用户”合成一张表，理由是都有手机号、都要登录。这两类对象的生命周期完全不同：会员是消费主体，有积分、等级、储值余额，可能一辈子不登录系统；用户是操作主体，有角色、菜单权限、登录日志。合并之后，收银员 A 同时是会员 B 这种情况就没法表达。

供应商表同理，它是采购侧的主数据，和商品是多对多（一个供应商供多种商品），中间用supplier_product关联表，记录供货价和起订量。三张表分开，字段各管各的，后面加“供应商结算”功能时不用改表结构。

4. 后端核心实现：商品维护、库存扣减、收银结算与报表统计

4.1 商品维护接口：分页、条件查询与逻辑删除

商品列表页是使用频率最高的管理页，要同时支持关键字模糊查、分类筛选、状态筛选、分页排序。这一块用 MyBatis-Plus 的LambdaQueryWrapper拼条件即可，重点是逻辑删除的配置——@TableLogic注解加上之后，deleteById自动变成UPDATE ... SET deleted = 1，所有查询自动带deleted = 0。

@Service public class ProductServiceImpl extends ServiceImpl<ProductMapper, Product> implements ProductService { @Override public PageResult<ProductVO> pageQuery(Integer page, Integer size, String keyword, Long categoryId) { LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); // keyword 为空时不拼条件，避免 like '%%' 全表扫描 wrapper.like(StringUtils.hasText(keyword), Product::getName, keyword) .or(StringUtils.hasText(keyword)) .like(StringUtils.hasText(keyword), Product::getBarcode, keyword); wrapper.eq(categoryId != null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getCreateTime); Page<Product> result = this.page(new Page<>(page, size), wrapper); return PageResult.of(result, ProductVO::from); } }

这里有个细节：like(condition, column, value)的第一个参数是布尔条件，为 false 时整段不拼进 SQL。这是 MyBatis-Plus 里最实用也最容易被忽略的写法，用好了能省掉一大堆 if 判断。分类筛选为空时不拼category_id条件，是因为“全部商品”页传的就是 null。

4.2 库存扣减：一条带条件的 UPDATE 解决超卖

这是整套系统里唯一必须认真对待并发的地方。收银台结账扣库存，正确写法是把判断塞进 SQL 的 WHERE 里，靠数据库的行锁保证原子性：

<!-- ProductMapper.xml --> <update id="deductStock"> UPDATE product SET stock = stock - #{qty}, update_time = NOW() WHERE id = #{productId} AND stock >= #{qty} AND deleted = 0 </update>

@Service public class StockService { private final ProductMapper productMapper; private final StockLogMapper stockLogMapper; /** * 扣减库存，返回 false 表示库存不足 * 流水写入和扣减必须在同一事务，否则出错时查不到账 */ @Transactional(rollbackFor = Exception.class) public boolean deduct(Long productId, Integer qty, String bizNo) { int rows = productMapper.deductStock(productId, qty); if (rows == 0) { return false; } stockLogMapper.insert(StockLog.out(productId, qty, bizNo)); return true; } }

WHERE stock >= qty是整个方案里最值钱的一行。如果写成“先select查库存、判断够不够、再update扣减”，两个收银台同时结账时，两边都查到库存 1，都判断够，都执行扣减，最后库存变成 -1。这种问题本地单线程测试永远复现不了，上线第一天就出事，属实是血泪经验。

@Transactional上的rollbackFor = Exception.class也不能省。Spring 默认只对RuntimeException回滚，如果业务里抛了受检异常（比如某些 IO 相关异常），事务不会回滚，库存扣了订单没生成，账就对不上了。

4.3 收银结算：一个事务写五张表的顺序

一次结算涉及：写订单头、写订单明细、扣库存、写库存流水、更新会员积分。这五步必须在一个事务里，而且顺序有讲究——先做最容易失败的，失败早回滚，锁持有时间最短。

@Service public class OrderService { @Transactional(rollbackFor = Exception.class) public String checkout(CheckoutDTO dto, Long cashierId) { // 1. 先扣库存：库存不足直接抛异常，后面的表一张都不用写 for (CheckoutItem item : dto.getItems()) { boolean ok = stockService.deduct(item.getProductId(), item.getQty(), dto.getOrderNo()); if (!ok) { throw new BizException("商品【" + item.getProductName() + "】库存不足"); } } // 2. 写订单头，金额由后端重算，不信任前端传来的合计 Order order = buildOrder(dto, cashierId); orderMapper.insert(order); // 3. 写明细，价格与名称取当前商品快照 for (CheckoutItem item : dto.getItems()) { orderItemMapper.insert(buildItem(order.getId(), item)); } // 4. 会员积分：只有绑定了会员的订单才更新 if (dto.getMemberId() != null) { memberService.addPoints(dto.getMemberId(), order.getPayAmount().intValue()); } return order.getOrderNo(); } }

要点有三个。第一，金额由后端重算，前端传什么价格都不认，否则改一下浏览器内存就能一块钱买走一车货。第二，扣库存放在最前面，因为它是唯一会“预期失败”的步骤，早失败早回滚，不会白写三张表。第三，订单号用“日期 + 收银台号 + 序列”生成，不要用自增主键当订单号——自增主键能反推出一天的订单量，属于不该暴露的信息。

4.4 报表统计：按日聚合的 SQL 与索引配合

报表模块是整个系统里唯一需要手写复杂 SQL 的地方。日销报表按天聚合订单数、销售额、客单价：

-- 注意 order 是 MySQL 保留字，必须加反引号 SELECT DATE(create_time) AS day, COUNT(*) AS order_cnt, SUM(pay_amount) AS amount, ROUND(SUM(pay_amount) / COUNT(*), 2) AS avg_amount FROM `order` WHERE status = 1 AND create_time >= #{startTime} AND create_time < #{endTime} GROUP BY DATE(create_time) ORDER BY day;

这条 SQL 能不能跑得快，全看order表上有没有(status, create_time)联合索引。有索引走范围扫描，几千条数据毫秒级返回；没索引就是全表扫描加临时表分组，数据攒到几万条之后打开报表要等十几秒，演示时非常尴尬。

品类销售占比是另一条思路，从明细表出发关联商品表：

SELECT c.name AS category_name, SUM(i.qty) AS total_qty, SUM(i.subtotal) AS total_amount FROM order_item i JOIN `order` o ON o.id = i.order_id AND o.status = 1 JOIN product p ON p.id = i.product_id JOIN category c ON c.id = p.category_id WHERE o.create_time >= #{startTime} AND o.create_time < #{endTime} GROUP BY c.id, c.name ORDER BY total_amount DESC;

这里用的是明细表里存的product_id反查分类，而不是明细表直接存分类 ID。原因是分类可能调整（商品从“饮料”挪到“酒水”），用当前分类归属来统计更符合管理者的理解；如果想要“下单当时”的分类，就得在明细表加category_id快照字段，两者都合理，取决于业务怎么定义。

5. 踩坑与排查：并发超卖、跨域联调、权限越界、报表卡顿

这一章是我认为比前面四章都更值得逐条看的部分。下面四个问题，几乎每一届做这类系统的同学都会撞上至少两个。

5.1 现象：两个人同时结账，库存变成 -1

现象：本地测试一切正常，找同学帮忙模拟两个收银台同时点结算，最后一件商品卖出了两次，库存显示 -1。刷新页面数据还是错的，数据库里确实存了 -1。

原因：典型的“查询—判断—更新”三步走写法，两步之间存在时间窗。两个请求都读到stock = 1，都判断1 >= 1成立，都执行stock = 1 - 1，最后写回 0？不对，如果两个请求都写 0，库存不会变负。真正变成 -1 的是这种写法：stock = stock - qty但判断在 Java 层做——第一个请求扣成 0，第二个请求的 Java 判断用的是它自己之前读到的旧值 1，照样执行减法，于是变成 -1。

解决：把判断搬进 SQL，用UPDATE ... SET stock = stock - #{qty} WHERE id = ? AND stock >= #{qty}，靠 InnoDB 行锁串行化两个请求，第二个请求的rows返回 0，业务层抛“库存不足”。同时给stock_log加一条记录，方便事后核对。如果业务需要处理同一商品的批量扣减，还要在 Service 层对商品 ID 排序后再依次扣，避免两个事务交叉持有行锁造成死锁。

5.2 现象：后端接口 Postman 能通，前端一调就 401 或跨域报错

现象：登录接口在 Postman 里返回 200 和 token，前端页面点登录却报Access-Control-Allow-Origin，好不容易跨域通了，刷新页面又跳回登录页，陷入循环。

原因：跨域和 401 是两个独立问题，经常被混在一起。跨域是因为开发阶段前端跑在 5173 端口、后端跑在 8080 端口，浏览器同源策略拦截；401 循环是因为 axios 响应拦截器里对“token 失效”和“登录接口本身返回 401”没做区分，登录失败也触发跳转，跳转又发请求，又失败。

解决：跨域优先用 Vite 的server.proxy转发，而不是在后端堆@CrossOrigin——代理方案下浏览器看到的始终是同源，生产环境换成 Nginx 反代也是同一套逻辑，不会出现“开发能跑、部署报错”。

// vite.config.js export default defineConfig({ server: { proxy: { // 所有 /api 开头的请求转发到后端，浏览器视角下始终同源 '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

401 循环的修法是在响应拦截器里排除登录接口：

// src/utils/request.js service.interceptors.response.use( res => res.data, error => { const url = error.config?.url || '' // 登录接口返回 401 是"账号密码错"，不是"登录过期"，不能跳转 if (error.response?.status === 401 && !url.includes('/auth/login')) { userStore.clearToken() router.replace('/login') } return Promise.reject(error) } )

5.3 现象：普通收银员能看到并点到“删除商品”按钮，接口还真删了

现象：前端菜单按角色过滤了，收银员登录看不到“商品管理”菜单，但用浏览器直接输入/product路径能进页面；更严重的是，绕过页面直接调删除接口，后端也返回成功。

原因：只做了前端菜单过滤，没做路由守卫，更没做后端接口鉴权。前端的meta.roles只是渲染依据，任何人打开控制台都能改；后端接口如果只校验“是否登录”而不校验“是否有权限”，等于没设防。

解决：三层一起做。路由守卫在beforeEach里比对目标路由的meta.roles与当前用户角色，不匹配跳 403；后端在方法上加@PreAuthorize("hasRole('ADMIN')")，并在配置类开启@EnableGlobalMethodSecurity；同时把菜单也改成后端下发，前端只负责渲染，这样增删角色权限不用改前端代码。另外逻辑删除的数据要检查@TableLogic是否真的生效——见过不止一次因为字段名写错，删除标记没起作用，被删的商品又出现在列表里。

5.4 现象：销售报表打开要等十几秒，偶尔还超时

现象：演示前一天导入了半年的模拟数据，订单表三万多条，点开“销售统计”页面转圈十几秒才出来，切个日期范围又要重新等。

原因：三个问题叠加。一是order表的create_time没有索引，日期范围查询全表扫；二是报表 Service 里用循环查每个订单的明细，典型 N+1；三是每次请求都实时聚合，没做任何缓存。

解决：先加联合索引(status, create_time)，单这一条就能把查询从十几秒降到几十毫秒；再把循环查询改成一条JOIN聚合 SQL；最后对“近 7 天”“本月”这类固定区间加一层本地缓存，用@Cacheable或简单的ConcurrentHashMap加过期时间都行，报表数据延迟一分钟完全可以接受。排查这类问题的通用手法是打开 MySQL 慢查询日志，把long_query_time调成 1 秒，跑一遍报表，慢在哪条 SQL 上一目了然，比猜快得多。

6. 验收与答辩：一份能照着演示的功能清单和演示脚本

到这一步，代码写完了，最怕的是答辩现场点哪个按钮哪个报错。我一般会提前做一张验收清单，逐项手动走一遍，走不通的当场记下来，不留到现场。

演示脚本我建议按“一条业务主线”走，而不是按模块走：登录收银员 → 扫码加购三件商品 → 绑定会员 → 结账 → 切管理员登录 → 看库存减少 → 看订单列表 → 看报表数字变化 → 对订单退货 → 再看库存回补。这条线走完，等于把商品、库存、收银、会员、报表、权限六个模块全串了一遍，评委看到的是一个闭环系统，而不是六个互不相干的增删改查页面。

答辩提问里高频的三个问题，提前准备好答案：一是“并发怎么处理的”，答带条件的 UPDATE 加行锁，能说出为什么不能先查后改；二是“金额为什么由后端算”，答前端数据不可信；三是“权限怎么做的”，答前端控制可见性、后端控制可执行性，两层都要有。这三个问题答得利落，基本就稳了。

从那以后我每次带这类系统，都强制自己在上交前一天按验收清单从头点一遍，哪怕是看着最不可能出错的“修改商品价格”——真有一次就是改价接口少传了一个字段，列表页价格显示成 null，现场演示直接卡住。提前十分钟走一遍，比事后解释半小时有用得多。希望帮到你。

本文还有配套的精品资源，点击获取