简介这份资源是面向计算机专业毕业设计场景的超市管理系统完整项目源码采用SpringBoot后端与Vue.js前端的前后端分离架构适合正在准备毕设或需要学习企业级Web开发的学生参考。压缩包共约2000个文件涵盖1614个js、233个css、61个java、43个vue及xml、json、html、sql等类型分别对应前端脚本与样式、后端业务逻辑、页面组件、配置与数据库初始化脚本整体约23.17MB。系统围绕用户权限、商品库存、销售事务、报表统计与系统设置等模块展开可帮助读者理解前后端分离项目的目录组织、接口调用与数据库建表思路并作为二次开发或答辩演示的基础工程。目前已有87人学习下载适合需要完整项目骨架与模块划分参考的毕设学习者。1. 从一份“能跑但不敢交”的超市管理系统说起每年毕业设计季总有人拿着一个能登录、能加商品、能下单的超市管理系统来问功能都跑通了为什么导师还是说“不像一个完整的系统”问题往往不在代码量而在方案没立住——需求边界模糊、模块职责混乱、验收标准缺失。这套基于 SpringBoot Vue 的超市管理系统要解决的就是“从能跑到能交付”这一段路。它适合正在做毕业设计、课程设计的学生也适合需要快速搭出一套进销存原型的从业者。下面按需求、设计、实现、避坑、验收的顺序把这份方案拆开讲清楚你可以直接照着改。2. 需求与选型超市管理系统到底要管哪几件事2.1 先把角色和业务边界划清楚超市管理系统的需求看起来杂其实核心就三条线商品进得来、库存对得上、账目算得清。围绕这三条线角色通常分三类管理员负责商品、分类、供应商和用户管理收银员负责开单、结算和退货仓库角色负责入库、出库和库存盘点。很多毕设翻车的地方是一上来就画十几个用例结果每个都做一半。我一般会建议先锁定最小可用范围商品管理、分类管理、供应商管理、库存出入库、销售开单、销售明细查询、用户与权限。这七块覆盖了超市日常运转的主干答辩时也讲得清楚。边界划清楚之后非功能需求也要写进方案里。比如并发量不需要按双十一去设计但要能支撑几十个收银端同时开单不串号数据一致性上库存扣减和销售单必须在一个事务里完成不能出现“单开了库存没减”的情况。这些约束会直接影响后面的表设计和接口设计提前写进需求文档比后期补丁式修改省事得多。2.2 技术选型为什么是 SpringBoot Vue 这套组合选 SpringBoot 做后端核心理由是它把配置和依赖管理压到了很低毕设周期内不用在环境上耗太多时间。配合 MyBatis-Plus 做数据访问单表 CRUD 基本不用手写 SQL复杂查询再写 XML节奏比较稳。权限控制用 Spring Security 加 JWT前后端分离场景下比 Session 更顺手token 里带角色信息前端路由守卫直接按角色放行。数据库选 MySQL超市业务的数据关系清晰事务支持成熟库存扣减这类操作靠数据库事务兜底最直接。前端选 Vue 3 加 Element Plus表格、表单、弹窗这些管理后台高频组件开箱即用省掉大量样式调试时间。构建工具用 Vite热更新快改页面不用等。前后端通过 Axios 通信统一封装请求拦截器处理 token 和错误提示。这套组合不是唯一解但在毕设场景下资料多、坑少、出活快是性价比很高的选择。层次技术选它的理由后端框架SpringBoot自动配置快速起服务数据访问MyBatis-Plus单表 CRUD 零 SQL分页插件现成权限Spring Security JWT无状态适配前后端分离数据库MySQL事务成熟库存扣减有保障前端框架Vue 3组合式 API逻辑复用方便UI 组件Element Plus管理后台组件齐全构建Vite启动快热更新及时提示版本号不必追新毕设环境稳定优先。后端 JDK 选 8 或 17 都可以前端 Node 选 LTS 版本避免因版本过新导致依赖冲突。3. 总体架构设计分层结构与模块职责划分3.1 后端分层Controller、Service、Mapper 各管什么后端按经典三层结构组织但每一层的职责要卡死否则代码很快会变成一锅粥。Controller 只做参数接收、校验和结果封装不写业务逻辑Service 承载业务规则比如“出库时库存不足要拦截”“销售单保存后要扣库存”Mapper 只负责数据访问复杂查询写 XML。实体类单独放 entity 包和前端交互的入参出参用 DTO 和 VO 隔离避免把数据库字段直接暴露给前端。包结构建议按业务模块划分而不是按技术层平铺。比如com.supermarket.module.goods下面放商品相关的 Controller、Service、Mappermodule.stock放库存module.sale放销售。这样改一个业务只动一个目录答辩时讲模块划分也清晰。公共部分放common包包括统一返回体、全局异常处理、JWT 工具类和常量定义。// 统一返回体所有接口都返回这个结构 public class ResultT { private Integer code; // 200 成功500 失败401 未登录 private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(操作成功); r.setData(data); return r; } public static T ResultT fail(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } }这段代码的关键在于统一了前后端的契约。前端拦截器只需要判断code是否为 200非 200 统一弹错误提示不用每个接口单独写判断。data泛型让分页数据和单条数据都能复用同一个结构减少重复类。实际项目里还可以加一个PageResult专门承载分页信息把total和records分开返回。3.2 前端结构路由、状态与请求层的分工前端按页面维度组织views下分goods、stock、sale、system四个目录每个目录里放列表页和表单弹窗组件。路由用vue-router在meta里标注所需角色全局前置守卫读取本地存储的 token 和角色信息不匹配就跳回登录页。状态管理不必上 Pinia 管所有数据只把当前登录用户信息和侧边栏折叠状态放进去页面数据各自在组件内维护避免过度设计。请求层统一封装 Axios 实例请求拦截器自动带上Authorization头响应拦截器统一处理 401 跳登录、500 弹提示。这样每个页面调接口时只关心业务参数不用重复写 token 逻辑。下面是一个典型的请求封装片段// request.js 统一封装 import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer ${token} return config }) request.interceptors.response.use( res { if (res.data.code ! 200) { ElMessage.error(res.data.message) return Promise.reject(res.data) } return res.data.data }, err { if (err.response err.response.status 401) { localStorage.clear() router.push(/login) } return Promise.reject(err) } ) export default request拦截器里把 token 注入和错误处理收口页面代码就干净很多。注意baseURL配成/api开发环境在 Vite 配置里做代理转发到后端端口生产环境由 Nginx 反向代理这样前后端联调不用改代码。401 处理里清空本地存储再跳登录避免拿着过期 token 反复请求。3.3 数据库设计七张核心表撑起业务闭环表设计是这套系统的地基设计不好后面全是补丁。核心表包括用户表、角色表、商品表、商品分类表、供应商表、库存流水表、销售单表和销售明细表。商品表里存分类 ID 和供应商 ID 做关联库存数量单独放库存表还是放商品表取决于是否要按批次管理。毕设场景下通常不做到批次级库存数量直接放商品表库存流水表只记录每次出入库的变动用于追溯。销售单和销售明细是一对多关系销售单存总金额、收银员、下单时间明细存商品、数量、单价。库存扣减发生在销售单保存时按明细逐条扣减商品库存整个过程包在一个事务里。库存流水表记录变动类型入库、出库、销售扣减、退货回补、变动数量和变动后库存方便对账和排查。-- 商品表核心字段 CREATE TABLE goods ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 分类ID, supplier_id BIGINT COMMENT 供应商ID, price DECIMAL(10,2) NOT NULL COMMENT 售价, stock INT NOT NULL DEFAULT 0 COMMENT 当前库存, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 库存流水表 CREATE TABLE stock_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_id BIGINT NOT NULL, change_type TINYINT NOT NULL COMMENT 1入库 2出库 3销售 4退货, change_num INT NOT NULL COMMENT 正数增加负数减少, after_stock INT NOT NULL COMMENT 变动后库存, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );stock字段直接放商品表查询列表时不用联表性能更好。stock_record的after_stock冗余了变动后库存排查问题时不用从头累加直接看最后一条记录就能知道当前值对不对。change_num用正负号区分增减比单独存类型再判断更直观。实际建表时记得给goods_name、category_id加索引商品多了之后列表查询会明显变快。4. 核心模块实现商品、库存与销售三条主线4.1 商品管理分页查询与分类联动商品管理是使用频率最高的模块列表页要支持按名称模糊查、按分类筛选、分页展示。后端用 MyBatis-Plus 的分页插件Controller 接收page、size、keyword、categoryId四个参数Service 里拼查询条件。分类下拉框的数据从分类接口单独拉页面加载时并行请求避免串行等待。新增和编辑共用一个表单弹窗用id是否存在区分模式减少重复代码。// 商品分页查询 public PageGoodsVO pageQuery(Integer page, Integer size, String keyword, Long categoryId) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.like(Goods::getGoodsName, keyword); } if (categoryId ! null) { wrapper.eq(Goods::getCategoryId, categoryId); } wrapper.orderByDesc(Goods::getCreateTime); PageGoods result goodsMapper.selectPage(new Page(page, size), wrapper); // 转 VO 时补充分类名称前端直接展示 return result.convert(this::toVO); }LambdaQueryWrapper的好处是字段名用方法引用改字段名时编译期就能发现不会出现 SQL 里写错列名的情况。convert方法里把分类 ID 换成分类名称前端表格直接渲染不用再发一次请求。分页参数建议在 Controller 层做默认值兜底page为空给 1size为空给 10防止前端漏传导致全表查询。4.2 库存出入库事务与并发扣减的处理库存模块最容易出问题的是并发扣减。两个收银端同时卖最后一件商品如果先查库存再更新很可能都查到有货结果扣成负数。稳妥的做法是用带条件的更新语句把判断和扣减合成一步UPDATE goods SET stock stock - #{num} WHERE id #{goodsId} AND stock #{num}这条语句执行后返回受影响行数如果为 0 说明库存不足Service 里直接抛业务异常回滚事务。这样不依赖先查后改数据库层面保证了不会超卖。入库同理只是条件换成stock 0不需要直接加。每次变动都往stock_record插一条流水记录变动类型和变动后库存方便后续对账。Transactional(rollbackFor Exception.class) public void saleOut(Long goodsId, int num, Long saleId) { int affected goodsMapper.reduceStock(goodsId, num); if (affected 0) { throw new BusinessException(商品库存不足无法出库); } Goods goods goodsMapper.selectById(goodsId); stockRecordMapper.insert(buildRecord(goodsId, 3, -num, goods.getStock())); }Transactional注解保证扣库存和写流水在同一个事务里任何一步失败都回滚。rollbackFor Exception.class显式指定异常类型避免受检异常不回滚的坑。reduceStock对应的就是上面那条带条件的 UPDATE返回 int 判断是否成功。这里没有用乐观锁版本号因为条件更新本身已经起到了类似作用实现更简单。4.3 销售开单一次事务串起单据与明细销售开单是业务闭环的最后一环前端选商品、填数量后端生成销售单和明细同时扣库存。接口设计上前端一次性提交商品明细数组后端在 Service 里循环处理整个方法加事务注解。销售单号用时间戳加随机数生成保证唯一且可读。总金额由后端根据商品当前售价重新计算不信任前端传的金额防止篡改。Transactional(rollbackFor Exception.class) public Long createSale(SaleDTO dto) { Sale sale new Sale(); sale.setSaleNo(generateSaleNo()); sale.setCashierId(SecurityUtils.getCurrentUserId()); sale.setTotalAmount(BigDecimal.ZERO); saleMapper.insert(sale); BigDecimal total BigDecimal.ZERO; for (SaleItemDTO item : dto.getItems()) { Goods goods goodsMapper.selectById(item.getGoodsId()); int affected goodsMapper.reduceStock(item.getGoodsId(), item.getNum()); if (affected 0) { throw new BusinessException(goods.getGoodsName() 库存不足); } SaleItem si new SaleItem(); si.setSaleId(sale.getId()); si.setGoodsId(item.getGoodsId()); si.setNum(item.getNum()); si.setPrice(goods.getPrice()); saleItemMapper.insert(si); total total.add(goods.getPrice().multiply(BigDecimal.valueOf(item.getNum()))); } sale.setTotalAmount(total); saleMapper.updateById(sale); return sale.getId(); }金额用BigDecimal而不是double避免浮点精度问题导致对账差几分钱。循环里逐条扣库存任何一条失败整个事务回滚不会出现“部分商品扣了部分没扣”的脏数据。销售单先插入拿到主键再插明细最后回填总金额顺序不能乱。实际项目里还可以加一个退货接口逻辑是反向操作明细数量回补库存销售单标记退货状态。5. 避坑与排查这套系统最容易翻车的五个点5.1 跨域配置写了但依然报 CORS 错误现象是前端请求后端接口浏览器控制台报跨域但后端明明加了CrossOrigin。原因通常是 Spring Security 的过滤器链在跨域配置之前执行请求还没到 Controller 就被拦了。解决方式是在 Security 配置里显式开启跨域并让CorsConfigurationSource生效而不是只在 Controller 上加注解。开发环境另一种更省事的做法是用 Vite 代理把/api转发到后端端口浏览器看来是同源请求直接绕开跨域问题。5.2 库存扣成负数却查不出原因现象是盘点时发现某个商品库存为负但流水记录对不上。原因多半是扣减逻辑用了“先查再改”并发下两个请求都查到有货各自扣减。解决方式是改成带条件的 UPDATE用受影响行数判断是否成功同时给库存字段加UNSIGNED约束作为最后一道防线。排查时直接看stock_record最后一条的after_stock和商品表当前stock是否一致不一致就说明有绕过流水的直接改库操作。5.3 前端刷新页面后登录状态丢失现象是登录后正常使用一按 F5 就跳回登录页。原因是 token 只存在 Vuex 或 Pinia 的内存里刷新即丢。解决方式是把 token 存localStorage应用初始化时从本地读取并恢复到状态管理里。同时要注意退出登录时清干净避免残留 token 导致切换账号后还是旧身份。路由守卫里判断的是本地存储的 token不是内存状态这样刷新才不会误判。5.4 分页查询总数不对或数据重复现象是列表页显示的总条数和实际不符或者翻页时出现重复数据。原因通常是分页插件没配好或者排序字段不唯一导致翻页错乱。解决方式是确认 MyBatis-Plus 分页插件已注册排序时加上主键作为第二排序字段保证顺序稳定。另外联表查询时如果一对多关联count语句要单独写不能直接套用主查询否则总数会被放大。5.5 答辩演示时接口突然 401现象是本地跑得好好的答辩现场登录后调接口全部 401。原因可能是 token 过期时间设得太短或者演示机时间和服务器时间偏差过大导致 JWT 校验失败。解决方式是把 token 有效期设成足够覆盖演示时长比如 8 小时并在前端拦截器里对 401 做友好提示而不是直接白屏。演示前用另一台机器完整走一遍流程比现场调试从容得多。6. 验收与答辩怎么证明这套系统真的能用验收这套系统我一般按三条线走。第一条是功能线对照需求清单逐项过商品增删改查、分类筛选、供应商关联、入库出库、销售开单、明细查询、角色权限每项至少走一遍正常流程和一次异常流程比如库存不足时开单是否被拦截、未登录访问接口是否返回 401。第二条是数据线开几单销售后去查库存流水和商品库存是否对得上退货后库存是否回补金额合计是否和明细一致。第三条是异常线故意传空参数、传不存在的商品 ID、重复提交同一张单看系统是报友好错误还是抛堆栈。答辩时导师最爱问的三个问题提前准备好答案为什么选这套技术栈答的时候落到具体场景比如“库存扣减需要事务MySQL 最直接”库存并发怎么处理把带条件 UPDATE 那条语句讲清楚比背概念有说服力权限怎么做的说清 JWT 里带角色、前端路由守卫加后端接口注解双重校验。演示顺序建议从登录开始按角色切换展示不同菜单再走一遍开单到库存变动的完整链路最后打开数据库表展示流水记录形成闭环。验收项通过标准检查方式登录与权限不同角色菜单不同越权接口返回 401切换账号逐项点商品管理增删改查正常分类筛选准确造 20 条数据翻页库存扣减并发开单不超卖流水与库存一致两窗口同时提交销售开单金额合计正确明细完整对单据与明细表异常处理参数错误有提示不抛堆栈故意传空值血泪经验是答辩前一定用干净数据库跑一遍完整流程别拿开发时攒了一堆测试数据的库去演示翻页翻出脏数据很尴尬。从那以后我每次交付前都强制走一遍“清库、造数、全流程、对账”四步宁可多花半小时也不在台上手忙脚乱。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是面向计算机专业毕业设计场景的超市管理系统完整项目源码采用SpringBoot后端与Vue.js前端的前后端分离架构适合正在准备毕设或需要学习企业级Web开发的学生参考。压缩包共约2000个文件涵盖1614个js、233个css、61个java、43个vue及xml、json、html、sql等类型分别对应前端脚本与样式、后端业务逻辑、页面组件、配置与数据库初始化脚本整体约23.17MB。系统围绕用户权限、商品库存、销售事务、报表统计与系统设置等模块展开可帮助读者理解前后端分离项目的目录组织、接口调用与数据库建表思路并作为二次开发或答辩演示的基础工程。目前已有87人学习下载适合需要完整项目骨架与模块划分参考的毕设学习者。1. 从一份“能跑但不敢交”的超市管理系统说起每年毕业设计季总有人拿着一个能登录、能加商品、能下单的超市管理系统来问功能都跑通了为什么导师还是说“不像一个完整的系统”问题往往不在代码量而在方案没立住——需求边界模糊、模块职责混乱、验收标准缺失。这套基于 SpringBoot Vue 的超市管理系统要解决的就是“从能跑到能交付”这一段路。它适合正在做毕业设计、课程设计的学生也适合需要快速搭出一套进销存原型的从业者。下面按需求、设计、实现、避坑、验收的顺序把这份方案拆开讲清楚你可以直接照着改。2. 需求与选型超市管理系统到底要管哪几件事2.1 先把角色和业务边界划清楚超市管理系统的需求看起来杂其实核心就三条线商品进得来、库存对得上、账目算得清。围绕这三条线角色通常分三类管理员负责商品、分类、供应商和用户管理收银员负责开单、结算和退货仓库角色负责入库、出库和库存盘点。很多毕设翻车的地方是一上来就画十几个用例结果每个都做一半。我一般会建议先锁定最小可用范围商品管理、分类管理、供应商管理、库存出入库、销售开单、销售明细查询、用户与权限。这七块覆盖了超市日常运转的主干答辩时也讲得清楚。边界划清楚之后非功能需求也要写进方案里。比如并发量不需要按双十一去设计但要能支撑几十个收银端同时开单不串号数据一致性上库存扣减和销售单必须在一个事务里完成不能出现“单开了库存没减”的情况。这些约束会直接影响后面的表设计和接口设计提前写进需求文档比后期补丁式修改省事得多。2.2 技术选型为什么是 SpringBoot Vue 这套组合选 SpringBoot 做后端核心理由是它把配置和依赖管理压到了很低毕设周期内不用在环境上耗太多时间。配合 MyBatis-Plus 做数据访问单表 CRUD 基本不用手写 SQL复杂查询再写 XML节奏比较稳。权限控制用 Spring Security 加 JWT前后端分离场景下比 Session 更顺手token 里带角色信息前端路由守卫直接按角色放行。数据库选 MySQL超市业务的数据关系清晰事务支持成熟库存扣减这类操作靠数据库事务兜底最直接。前端选 Vue 3 加 Element Plus表格、表单、弹窗这些管理后台高频组件开箱即用省掉大量样式调试时间。构建工具用 Vite热更新快改页面不用等。前后端通过 Axios 通信统一封装请求拦截器处理 token 和错误提示。这套组合不是唯一解但在毕设场景下资料多、坑少、出活快是性价比很高的选择。层次技术选它的理由后端框架SpringBoot自动配置快速起服务数据访问MyBatis-Plus单表 CRUD 零 SQL分页插件现成权限Spring Security JWT无状态适配前后端分离数据库MySQL事务成熟库存扣减有保障前端框架Vue 3组合式 API逻辑复用方便UI 组件Element Plus管理后台组件齐全构建Vite启动快热更新及时提示版本号不必追新毕设环境稳定优先。后端 JDK 选 8 或 17 都可以前端 Node 选 LTS 版本避免因版本过新导致依赖冲突。3. 总体架构设计分层结构与模块职责划分3.1 后端分层Controller、Service、Mapper 各管什么后端按经典三层结构组织但每一层的职责要卡死否则代码很快会变成一锅粥。Controller 只做参数接收、校验和结果封装不写业务逻辑Service 承载业务规则比如“出库时库存不足要拦截”“销售单保存后要扣库存”Mapper 只负责数据访问复杂查询写 XML。实体类单独放 entity 包和前端交互的入参出参用 DTO 和 VO 隔离避免把数据库字段直接暴露给前端。包结构建议按业务模块划分而不是按技术层平铺。比如com.supermarket.module.goods下面放商品相关的 Controller、Service、Mappermodule.stock放库存module.sale放销售。这样改一个业务只动一个目录答辩时讲模块划分也清晰。公共部分放common包包括统一返回体、全局异常处理、JWT 工具类和常量定义。// 统一返回体所有接口都返回这个结构 public class ResultT { private Integer code; // 200 成功500 失败401 未登录 private String message; private T data; public static T ResultT success(T data) { ResultT r new Result(); r.setCode(200); r.setMessage(操作成功); r.setData(data); return r; } public static T ResultT fail(String message) { ResultT r new Result(); r.setCode(500); r.setMessage(message); return r; } }这段代码的关键在于统一了前后端的契约。前端拦截器只需要判断code是否为 200非 200 统一弹错误提示不用每个接口单独写判断。data泛型让分页数据和单条数据都能复用同一个结构减少重复类。实际项目里还可以加一个PageResult专门承载分页信息把total和records分开返回。3.2 前端结构路由、状态与请求层的分工前端按页面维度组织views下分goods、stock、sale、system四个目录每个目录里放列表页和表单弹窗组件。路由用vue-router在meta里标注所需角色全局前置守卫读取本地存储的 token 和角色信息不匹配就跳回登录页。状态管理不必上 Pinia 管所有数据只把当前登录用户信息和侧边栏折叠状态放进去页面数据各自在组件内维护避免过度设计。请求层统一封装 Axios 实例请求拦截器自动带上Authorization头响应拦截器统一处理 401 跳登录、500 弹提示。这样每个页面调接口时只关心业务参数不用重复写 token 逻辑。下面是一个典型的请求封装片段// request.js 统一封装 import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) config.headers.Authorization Bearer ${token} return config }) request.interceptors.response.use( res { if (res.data.code ! 200) { ElMessage.error(res.data.message) return Promise.reject(res.data) } return res.data.data }, err { if (err.response err.response.status 401) { localStorage.clear() router.push(/login) } return Promise.reject(err) } ) export default request拦截器里把 token 注入和错误处理收口页面代码就干净很多。注意baseURL配成/api开发环境在 Vite 配置里做代理转发到后端端口生产环境由 Nginx 反向代理这样前后端联调不用改代码。401 处理里清空本地存储再跳登录避免拿着过期 token 反复请求。3.3 数据库设计七张核心表撑起业务闭环表设计是这套系统的地基设计不好后面全是补丁。核心表包括用户表、角色表、商品表、商品分类表、供应商表、库存流水表、销售单表和销售明细表。商品表里存分类 ID 和供应商 ID 做关联库存数量单独放库存表还是放商品表取决于是否要按批次管理。毕设场景下通常不做到批次级库存数量直接放商品表库存流水表只记录每次出入库的变动用于追溯。销售单和销售明细是一对多关系销售单存总金额、收银员、下单时间明细存商品、数量、单价。库存扣减发生在销售单保存时按明细逐条扣减商品库存整个过程包在一个事务里。库存流水表记录变动类型入库、出库、销售扣减、退货回补、变动数量和变动后库存方便对账和排查。-- 商品表核心字段 CREATE TABLE goods ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_name VARCHAR(100) NOT NULL COMMENT 商品名称, category_id BIGINT NOT NULL COMMENT 分类ID, supplier_id BIGINT COMMENT 供应商ID, price DECIMAL(10,2) NOT NULL COMMENT 售价, stock INT NOT NULL DEFAULT 0 COMMENT 当前库存, status TINYINT DEFAULT 1 COMMENT 1上架 0下架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 库存流水表 CREATE TABLE stock_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, goods_id BIGINT NOT NULL, change_type TINYINT NOT NULL COMMENT 1入库 2出库 3销售 4退货, change_num INT NOT NULL COMMENT 正数增加负数减少, after_stock INT NOT NULL COMMENT 变动后库存, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );stock字段直接放商品表查询列表时不用联表性能更好。stock_record的after_stock冗余了变动后库存排查问题时不用从头累加直接看最后一条记录就能知道当前值对不对。change_num用正负号区分增减比单独存类型再判断更直观。实际建表时记得给goods_name、category_id加索引商品多了之后列表查询会明显变快。4. 核心模块实现商品、库存与销售三条主线4.1 商品管理分页查询与分类联动商品管理是使用频率最高的模块列表页要支持按名称模糊查、按分类筛选、分页展示。后端用 MyBatis-Plus 的分页插件Controller 接收page、size、keyword、categoryId四个参数Service 里拼查询条件。分类下拉框的数据从分类接口单独拉页面加载时并行请求避免串行等待。新增和编辑共用一个表单弹窗用id是否存在区分模式减少重复代码。// 商品分页查询 public PageGoodsVO pageQuery(Integer page, Integer size, String keyword, Long categoryId) { LambdaQueryWrapperGoods wrapper new LambdaQueryWrapper(); if (StringUtils.hasText(keyword)) { wrapper.like(Goods::getGoodsName, keyword); } if (categoryId ! null) { wrapper.eq(Goods::getCategoryId, categoryId); } wrapper.orderByDesc(Goods::getCreateTime); PageGoods result goodsMapper.selectPage(new Page(page, size), wrapper); // 转 VO 时补充分类名称前端直接展示 return result.convert(this::toVO); }LambdaQueryWrapper的好处是字段名用方法引用改字段名时编译期就能发现不会出现 SQL 里写错列名的情况。convert方法里把分类 ID 换成分类名称前端表格直接渲染不用再发一次请求。分页参数建议在 Controller 层做默认值兜底page为空给 1size为空给 10防止前端漏传导致全表查询。4.2 库存出入库事务与并发扣减的处理库存模块最容易出问题的是并发扣减。两个收银端同时卖最后一件商品如果先查库存再更新很可能都查到有货结果扣成负数。稳妥的做法是用带条件的更新语句把判断和扣减合成一步UPDATE goods SET stock stock - #{num} WHERE id #{goodsId} AND stock #{num}这条语句执行后返回受影响行数如果为 0 说明库存不足Service 里直接抛业务异常回滚事务。这样不依赖先查后改数据库层面保证了不会超卖。入库同理只是条件换成stock 0不需要直接加。每次变动都往stock_record插一条流水记录变动类型和变动后库存方便后续对账。Transactional(rollbackFor Exception.class) public void saleOut(Long goodsId, int num, Long saleId) { int affected goodsMapper.reduceStock(goodsId, num); if (affected 0) { throw new BusinessException(商品库存不足无法出库); } Goods goods goodsMapper.selectById(goodsId); stockRecordMapper.insert(buildRecord(goodsId, 3, -num, goods.getStock())); }Transactional注解保证扣库存和写流水在同一个事务里任何一步失败都回滚。rollbackFor Exception.class显式指定异常类型避免受检异常不回滚的坑。reduceStock对应的就是上面那条带条件的 UPDATE返回 int 判断是否成功。这里没有用乐观锁版本号因为条件更新本身已经起到了类似作用实现更简单。4.3 销售开单一次事务串起单据与明细销售开单是业务闭环的最后一环前端选商品、填数量后端生成销售单和明细同时扣库存。接口设计上前端一次性提交商品明细数组后端在 Service 里循环处理整个方法加事务注解。销售单号用时间戳加随机数生成保证唯一且可读。总金额由后端根据商品当前售价重新计算不信任前端传的金额防止篡改。Transactional(rollbackFor Exception.class) public Long createSale(SaleDTO dto) { Sale sale new Sale(); sale.setSaleNo(generateSaleNo()); sale.setCashierId(SecurityUtils.getCurrentUserId()); sale.setTotalAmount(BigDecimal.ZERO); saleMapper.insert(sale); BigDecimal total BigDecimal.ZERO; for (SaleItemDTO item : dto.getItems()) { Goods goods goodsMapper.selectById(item.getGoodsId()); int affected goodsMapper.reduceStock(item.getGoodsId(), item.getNum()); if (affected 0) { throw new BusinessException(goods.getGoodsName() 库存不足); } SaleItem si new SaleItem(); si.setSaleId(sale.getId()); si.setGoodsId(item.getGoodsId()); si.setNum(item.getNum()); si.setPrice(goods.getPrice()); saleItemMapper.insert(si); total total.add(goods.getPrice().multiply(BigDecimal.valueOf(item.getNum()))); } sale.setTotalAmount(total); saleMapper.updateById(sale); return sale.getId(); }金额用BigDecimal而不是double避免浮点精度问题导致对账差几分钱。循环里逐条扣库存任何一条失败整个事务回滚不会出现“部分商品扣了部分没扣”的脏数据。销售单先插入拿到主键再插明细最后回填总金额顺序不能乱。实际项目里还可以加一个退货接口逻辑是反向操作明细数量回补库存销售单标记退货状态。5. 避坑与排查这套系统最容易翻车的五个点5.1 跨域配置写了但依然报 CORS 错误现象是前端请求后端接口浏览器控制台报跨域但后端明明加了CrossOrigin。原因通常是 Spring Security 的过滤器链在跨域配置之前执行请求还没到 Controller 就被拦了。解决方式是在 Security 配置里显式开启跨域并让CorsConfigurationSource生效而不是只在 Controller 上加注解。开发环境另一种更省事的做法是用 Vite 代理把/api转发到后端端口浏览器看来是同源请求直接绕开跨域问题。5.2 库存扣成负数却查不出原因现象是盘点时发现某个商品库存为负但流水记录对不上。原因多半是扣减逻辑用了“先查再改”并发下两个请求都查到有货各自扣减。解决方式是改成带条件的 UPDATE用受影响行数判断是否成功同时给库存字段加UNSIGNED约束作为最后一道防线。排查时直接看stock_record最后一条的after_stock和商品表当前stock是否一致不一致就说明有绕过流水的直接改库操作。5.3 前端刷新页面后登录状态丢失现象是登录后正常使用一按 F5 就跳回登录页。原因是 token 只存在 Vuex 或 Pinia 的内存里刷新即丢。解决方式是把 token 存localStorage应用初始化时从本地读取并恢复到状态管理里。同时要注意退出登录时清干净避免残留 token 导致切换账号后还是旧身份。路由守卫里判断的是本地存储的 token不是内存状态这样刷新才不会误判。5.4 分页查询总数不对或数据重复现象是列表页显示的总条数和实际不符或者翻页时出现重复数据。原因通常是分页插件没配好或者排序字段不唯一导致翻页错乱。解决方式是确认 MyBatis-Plus 分页插件已注册排序时加上主键作为第二排序字段保证顺序稳定。另外联表查询时如果一对多关联count语句要单独写不能直接套用主查询否则总数会被放大。5.5 答辩演示时接口突然 401现象是本地跑得好好的答辩现场登录后调接口全部 401。原因可能是 token 过期时间设得太短或者演示机时间和服务器时间偏差过大导致 JWT 校验失败。解决方式是把 token 有效期设成足够覆盖演示时长比如 8 小时并在前端拦截器里对 401 做友好提示而不是直接白屏。演示前用另一台机器完整走一遍流程比现场调试从容得多。6. 验收与答辩怎么证明这套系统真的能用验收这套系统我一般按三条线走。第一条是功能线对照需求清单逐项过商品增删改查、分类筛选、供应商关联、入库出库、销售开单、明细查询、角色权限每项至少走一遍正常流程和一次异常流程比如库存不足时开单是否被拦截、未登录访问接口是否返回 401。第二条是数据线开几单销售后去查库存流水和商品库存是否对得上退货后库存是否回补金额合计是否和明细一致。第三条是异常线故意传空参数、传不存在的商品 ID、重复提交同一张单看系统是报友好错误还是抛堆栈。答辩时导师最爱问的三个问题提前准备好答案为什么选这套技术栈答的时候落到具体场景比如“库存扣减需要事务MySQL 最直接”库存并发怎么处理把带条件 UPDATE 那条语句讲清楚比背概念有说服力权限怎么做的说清 JWT 里带角色、前端路由守卫加后端接口注解双重校验。演示顺序建议从登录开始按角色切换展示不同菜单再走一遍开单到库存变动的完整链路最后打开数据库表展示流水记录形成闭环。验收项通过标准检查方式登录与权限不同角色菜单不同越权接口返回 401切换账号逐项点商品管理增删改查正常分类筛选准确造 20 条数据翻页库存扣减并发开单不超卖流水与库存一致两窗口同时提交销售开单金额合计正确明细完整对单据与明细表异常处理参数错误有提示不抛堆栈故意传空值血泪经验是答辩前一定用干净数据库跑一遍完整流程别拿开发时攒了一堆测试数据的库去演示翻页翻出脏数据很尴尬。从那以后我每次交付前都强制走一遍“清库、造数、全流程、对账”四步宁可多花半小时也不在台上手忙脚乱。希望帮到你。本文还有配套的精品资源点击获取
