做超市管理系统这类项目我前后也接手过不少必须说这一套“Java Vue MySQL”的组合在中小型管理软件里实在太常见了。如果你手里也拿到了一套超市管理系统源码带着数据库脚本和开发文档那你其实已经站在了一个很好的起点上关键是怎么把它读透、跑起来、改得动。这套系统的核心其实就是围绕商品、库存、收银、会员、员工权限这几条线转业务听起来很简单实际落地全是细节。适合正在学 Spring Boot Vue 做毕业设计或商业项目的同学参考也适合刚转岗做全栈开发、想快速理解一套真实业务系统的朋友。1. 项目定位与整体设计思路1.1 这套系统解决的核心问题超市管理表面上看卖货就行但真正跑起来要面对一堆破事商品几十上百种进价售价天天变库存数字和实际对不上收银的时候扫码枪一扫就得出小票会员要积分、要打折员工有不同的岗位权限谁也不能乱改价格。这套基于 Java Vue 的前后端分离系统正好把这些问题拆成了几个标准模块来处理。数据层面靠 MySQL 做持久化每一笔进货、销售、库存变动都落到表里出问题了能逆向追溯。业务层面靠 Spring Boot 提供接口前端 Vue 负责操作界面收银员管收银台、管理员管后台各干各的。说白了它就是把一个实体超市的日常运营变成了一个可以随时查、随时管、随时统计的信息系统。1.2 为什么是 Java Vue 这套组合估计你也发现了现在市面上的管理类项目绝大多数都是这种搭配。后端 Java 用 Spring Boot生态成熟做事务、做权限、做并发控制都不虚前端 Vue 上手快组件化开发效率高Element UI 那一套表格、表单、弹窗组件拿来就能用。更重要的是这套组合对新手真的很友好。后端有 MyBatis Plus 这种工具单表 CRUD 几乎不用写 SQL前端有 Vue Router 管页面跳转、Vuex/Pinia 管全局状态再加上 Axios 请求后端接口整个链路清晰得跟说明书一样。你拿到的源码虽然是别人写好的但只要你懂 Spring Boot 的基本分层就能顺着 Controller - Service - Mapper 把逻辑捋出来改起来也不至于无从下手。1.3 多角色与多门店的业务闭环打开系统你会发现登录账号的权限不同看到的菜单和操作完全不一样。店长能看销售报表、管进货审核收银员只有收银和查库存的权限财务能看成本利润。这套系统把用户、角色、菜单做成了关联表登录后根据角色动态加载菜单而不是写死在页面上。多门店或者说单门店多仓库在代码里通常体现为所有业务单据都要挂一个门店或仓库 ID。比如进货单入到哪个仓库、销售单出到哪个仓库库存表里也是按“商品 仓库”组合记录数量。这个设计不要轻易去掉一旦去掉后面你想做连锁场景就得重新改造特别痛苦。2. 架构设计与数据库落地2.1 后端分层与关键依赖这套源码的后端基本逃不开三层结构。Controller 层只做参数接收和结果返回不碰业务Service 层存放核心逻辑比如下单扣库存、进货单审核Mapper 层用 MyBatis Plus 操作数据库简单查询直接继承 BaseMapper复杂统计自己写 XML。依赖管理上pom.xml 里通常会有这些玩意spring-boot-starter-web 提供接口能力mybatis-plus-boot-starter 做 ORMmysql-connector-java 连数据库lombok 省掉 getter/setter还有些项目会引入 Sa-Token 或 Spring Security 做登录鉴权JWT 做无状态令牌。如果你第一次看 pom.xml不用每个都看懂重点抓住 web、mybatis、数据库这三样就能启动起来。2.2 前端组织与组件化前端部分Vue 项目的 src 目录一般是这样分的api 目录放所有请求接口的封装每个模块一个 JS 文件views 目录放页面组件比如商品管理页、进货单页、收银台页router 目录配置路由和守卫store 或 pinia 用于存登录用户信息、菜单列表。实际开发里面最容易提升效率的就是组件化。比如商品表格在商品管理和库存管理里都要出现就抽成一个公共组件通过 props 传数据、通过事件通知父组件刷新。这套源码里如果组件抽得好你会发现页面写得非常薄大部分逻辑都在 JS 文件里。2.3 数据库表设计重点中的重点我统计过这类管理系统核心表一般就十几张但每一张都有讲究。给你列一下最关键的几张表名作用关键字段product商品档案id, 条码, 品名, 分类, 进价, 售价, 单位, 状态category商品分类id, 父id, 分类名stock库存id, 商品id, 仓库id, 数量, 预警值supplier供应商id, 名称, 联系人, 电话purchase进货单id, 单号, 供应商id, 总金额, 状态, 操作人purchase_item进货单明细id, 进货单id, 商品id, 数量, 进价sale_order销售单id, 单号, 收银员, 会员id, 实付金额, 积分sale_order_item销售明细id, 销售单id, 商品id, 数量, 成交价member会员id, 手机号, 姓名, 积分, 等级sys_user系统用户id, 用户名, 密码, 角色id, 门店idsys_role角色id, 角色名, 权限标识stock_record库存流水id, 商品id, 变动数量, 变动类型, 关联单号这里要重点提醒商品条码在表里要设唯一索引。超市里扫码枪扫的就是条码一旦有重复条码收银时就会弹出两条商品让你选体验非常糟糕。另外金额字段一定要用 decimal千万别用 double否则算账算到一分钱的时候你会疯掉。还有一个容易被忽略的点库存表要冗余一个商品名称字段进去这样查库存列表不用频繁关联商品表查询效率高很多。3. 核心模块功能拆解3.1 商品档案从条码到价格商品管理是整套系统的地基。商品表里每一条记录对应货架上的一个 SKU。这个模块的常规操作是新增商品、编辑信息、上下架、批量导入导出。编辑信息的时候价格变化要谨慎售价变了但库存没变很正常可如果进价变了会影响后面的毛利统计所以很多源码里会加一个“调价记录表”或者“商品价格历史表”。条码这里多说一句。除了商品自带的国标条码很多超市自己也会编内部码比如生鲜区域的产品没有条码就称重后贴一个自生成条码规则一般是 20 位数前几位是商品 ID中间是重量或价格后几位是校验位。源码里如果提供了“自定义条码生成工具类”你要看懂它的规则因为收银扫到这种条码要能解析出来。3.2 进货入库与库存流水进货不是直接改库存就完事一定是“建进货单 - 审核 - 入库”这三步。为什么这么设计因为入库这个动作要管钱的采购员建单、库管员核对实物、店长审核批准各环节分权防止一个人既买东西又收货。这套源码里的进货单一般都有状态字段0 草稿、1 待审核、2 已入账、3 已作废。入库的时候有两件大事要做第一件是更新库存表库存数量加上本次进货数量第二件是写一条库存流水流水里记录单号、商品、变动数量、变动前数量、变动后数量、操作人。库存流水是审计的关键依据以后盘点对不上账就靠流水反查哪个环节出了问题。千万别图省事只改库存不写流水那等于账目没有过程记录出了事说不清楚。3.3 收银下单并发与事务处理收银模块是整个系统技术含量最高的地方没有之一。你以为收银就是减库存要考虑的东西多了一次性买了五种商品五个商品的库存都要减如果用的是会员还要累加积分如果用了优惠券还要重新计算实付金额最后生成销售单还得把每一个明细分开存。这套源码里你会看到一个典型的写法SaleOrderService 里有一个 createOrder 方法上面加了 Transactional 注解。这个注解保证整个下单流程要么全部成功要么全部失败。比如减库存成功了、但生成销售单失败了事务回滚库存还会还原成原样。你要是把事务去掉早晚会出现库存负数或者卖出去了库存没减的灵异事件。并发问题更坑。超市早上开门的瞬间大家都在排队结算如果两个收银员同时卖同一种商品最后一件库存被两个人同时读到都觉得自己能减结果库存变成负数。解决方式通常是两种一是数据库行锁查询库存的时候用 for update 把这一行锁住处理完再释放二是乐观锁在库存表加一个 version 字段更新的时候 check version。做毕业设计或练手项目用行锁更直观但要注意锁的粒度别锁到整张表。3.4 会员积分与促销逻辑会员模块看起来简单实际坑也不少。会员表通常按手机号做唯一标识注册时记录开卡时间。消费规则一般是满多少元积 1 分积分可以在下次消费时抵扣现金。源码里积分的处理最好用“先累加再冻结”的思路也就是订单完成后才真正把积分加到会员头上如果退货了积分再扣回去。促销就更有意思了。满减、折扣、第二件半价这些规则如果写死在代码里每次改活动都得改代码重新部署。好一点的源码会把促销做成规则表存满减门槛、折扣率、有效期、参与商品范围。收银时先算原始总价再逐条匹配促销规则计算出最优优惠。作为参考我在实际项目里都是把促销优先级排好先算满减、再算单品折扣、最后算会员折扣顺序不能乱不然优惠力度算出来会有争议。3.5 员工权限与操作日志超市人员流动大收银员、理货员、店长各有分工权限控制必须细。后端会在登录接口返回 Token前端把 Token 存起来每次请求带上。后端在 Controller 层通过注解或拦截器校验当前用户有没有对应权限比如删除商品需要 admin 权限普通收银员接口直接拒绝。操作日志这块源码里一般叫 operate_log每次新增、编辑、删除、审核都记录操作人、操作时间、操作内容和 IP。很多人觉得日志表可有可无等你遇到有人半夜把商品价格改乱了、又不承认的时候就知道日志有多重要了。日志别只记“修改了商品”要记清楚改前值、改后值必要时候还要能一键还原。4. 从源码到运行部署与启动实操4.1 环境准备与版本对应拿到源码第一件事不是双击打开而是核对环境版本。现在很多项目的 README 就是摆设环境信息字都懒得写但你还是得自己确认。以最常见的组合为例JDK 1.8 或 JDK 11MySQL 8.0 居多Maven 3.6Node.js 14 或 16前端如果是 Vue 2 时代的老项目还依赖 node-sass这个最容易翻车。我的建议是先装一个环境管理工具JDK 用多个版本切换的Node 环境也尽量用版本管理工具。因为同一个项目JDK 版本高了老的 Lombok 可能不兼容Node 版本太高node-sass 构建直接失败。别用最新版别用最新版别用最新版重要事情说三遍。4.2 数据库初始化的两种方式源码里的数据库脚本一般有两种形态一个是 .sql 文件一个是数据库工具生成的初始化脚本。先建数据库编码选 utf8mb4排序规则选 utf8mb4_general_ci 或 utf8mb4_unicode_ci 都行。然后执行脚本mysql -u root -p -e CREATE DATABASE IF NOT EXISTS supermarket DEFAULT CHARACTER SET utf8mb4; mysql -u root -p supermarket supermarket.sql执行完以后别急着启动先检查一下核心表里有没有初始数据。很多系统的根账号就是靠初始化数据插入的比如 sys_user 表里面有一行 admin / 123456如果你把表结构和数据删了想自己插密码加密规则对不上的话登录一辈子都进不去。顺带说一句MySQL 8 的默认密码加密插件是 caching_sha2_password如果你的 JDBC 连接报了 Authentication plugin 异常说明驱动版本太老把 mysql-connector-java 升到 8.0.x 就好。4.3 后端启动流程与常见配置后端启动前必须改一个文件application.yml 或 application.properties。数据库连接、端口、Redis 地址全靠它。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/supermarket?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: map-underscore-to-camel-case: true这里我踩过太多次坑了。serverTimezone 一定要加不加 MySQL 8 会报时间相关错误因为驱动默认用 UTC跟北京时间差了 8 个小时日期时间查出来全是错误的。还有 map-underscore-to-camel-case如果配置没开数据库里的 create_time 字段映射不进 createTime 属性查询结果全是 null这问题排查起来特别隐蔽。改完配置在项目根目录执行 mvn spring-boot:run或者在 IDEA 里直接运行启动类。看到 Spring Boot 的 Banner 打出来、端口正常监听后端就算起来了。此时先用浏览器或 Postman 调一下登录接口能返回 Token 就说明数据库连接和接口路由都没问题。4.4 前端启动与联调配置前端目录一般叫 frontend、web 或 ui。进去第一件事npm install如果用的是 npm遇到权限报错就尝试 cnpm install 或 yarn install。老项目如果是 vue-cli 3/4 创建的Node 版本 17 以上很可能报 openssl 错误那是老 webpack 不兼容新 Node解决方式要么降 Node要么在 package.json 里加一句scripts: { serve: set NODE_OPTIONS--openssl-legacy-provider vue-cli-service serve }启动以后访问 localhost:8080如果有页面但是调接口报错第一反应检查跨域。前端开发环境一般在 vue.config.js 里配置代理把 /api 开头的请求转发到后端 8080module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }这个方案比在后端写 CORS 配置要干净上线后前端打包出来的文件放到一样域名下也不会出现跨域问题。5. 我踩过的坑与排查记录5.1 数据库时区与中文乱码这是出现频率最高的启动问题。解决办法前面提过了jdbc URL 加 serverTimezoneAsia/Shanghai数据库创建时用 utf8mb4。如果你用的数据库工具是图形界面建库时默认字符集可能不是 utf8记得手动改。中文乱码还有一个隐形原因后端返回 JSON 时乱码那是 Spring Boot 的响应编码没设置 UTF-8在 yml 里加server: servlet: encoding: charset: utf-8 force: true5.2 库存超卖与金额精度超卖问题在并发测试时最容易暴露。你拿 JMeter 模拟五十个并发同时下单买同一个商品断言库存值大概率会发现库存变成负数。行锁和乐观锁我在前面已经讲过了实际项目中我优先推荐乐观锁因为行锁在并发量大的时候会导致很多请求排队等锁收银高峰期数据库连接可能被打满。乐观锁也不难在更新库存的 SQL 里加上“version 旧版本号”更新成功影响行数为 1 才继续往下走影响行数为 0 就提示“库存变化请重试”。金额精度问题则属于隐蔽型 Bug。如果代码里用了 Double 或者 Float 做金额运算两件商品单价 19.9总价很可能是 39.800000000000004。别看显示时四舍五入好像没事但明细相加对不上总账的时候差几分钱你就要找到怀疑人生。金额一律用 BigDecimal并且用字符串构造函数new BigDecimal(19.9)千万别 new BigDecimal(19.9)后者算出来的照样是一串小数。5.3 权限校验失效的前端问题很多 Vue 项目做完登录后直接用 localStorage 存用户信息然后靠 v-if 判断按钮显隐。这种控制只是界面上的“隐藏”不是真正的权限控制。有人打开浏览器开发者工具改一下 localStorage 里的角色就能看到管理员按钮接口如果也没拦那就能直接执行管理员操作。所以权限这东西必须后端拦截一次才叫真正安全。前端配合的方式一般是在路由配置里给每个页面加 meta 字段写清需要的权限标识然后在路由守卫里判断router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (!token to.path ! /login) { next(/login) } else { next() } })5.4 问题排查速查表现象常见原因解决方向400 Bad Request参数类型不匹配检查前端传参字段与后端实体属性名401 UnauthorizedToken 缺失或过期登录重新获取 Token检查请求头 Authorization405 Method Not AllowedGET/POST 方法不一致核对前端 method 与后端 GetMapping/PostMapping数据库表不存在初始化脚本没执行检查 .sql 脚本执行结果核对库名接口返回字段全是 null驼峰映射没开启开启 map-underscore-to-camel-case前端启动后白屏页面路由未匹配检查路由路径刷新后 404 需后端配置转发小票打印内容残缺打印机协议不匹配确认 ESC/POS 指令集检查纸张宽度5.5 部署上线要注意的事开发环境跑通了并不代表上线能跑。真正部署的坑在数据库密码不能明文硬编码至少要放到环境变量或配置中心前端打包用 npm run build产物是 dist 目录不能直接把源码挂到服务器上如果用 Nginx 托管前端刷新非首页路由会 404必须在 nginx.conf 里配置 try_files 把所有请求都指到 index.html。后端打包则用 Maven 打成 jar 包推荐的做法是构建一个一键启停脚本脚本里写清楚 Java 路径、JVM 参数、日志文件路径。生产环境内存给的别太少Spring Boot 默认最大堆内存是物理内存的 1/4小内存服务器可能直接 OOM脚本里主动指定 -Xms256m -Xmx512m 更稳。6. 二次开发与扩展方向6.1 新增一个业务模块的通用套路这套系统跑通了以后你迟早要加功能比如增加“保质期管理”。改代码前先在数据库加表比如 expiry_date 字段加到商品表加字段的操作可以用 MyBatis Plus 的自动填充也可以直接执行 ALTER TABLE。然后用 MyBatis Plus 的代码生成器直接生成实体、Mapper、Service、Controller省去手写重复代码。接着复制一个已有页面的路由和菜单配置把商品管理页改一改加一列展示保质期、一个搜索条件一个模块就算加完了。这个流程我称为“复制-修改-验证”三步法对所有管理类系统新模块开发都非常好用。核心是不要自己手搓代码全流程先找一个最接近的已有模块当模板改完再拿真实数据跑一遍。6.2 报表统计做数据可视化超市管理系统最容易出彩的地方是数据可视化。销售报表、毛利分析、库存周转率这些需求百分之百会被提出来。如果源码里已经有 ECharts那直接写几个后端统计接口比如按天统计销售额、按分类统计销售占比、按月对比毛利前端用 ECharts 柱状图和折线图展示效果立竿见影。统计接口不要一个个查数据库然后在内存里算SQL 里直接 group by 出来性能好得多。SQL 写不出来的再考虑用程序计算但数据量大时千万要用流式处理别把全表数据一次性加载到内存。这段时间我在改这套系统时最深的体会是系统好不好用不在界面多花哨而在报表给不给力老板问“上周哪个商品卖得最好”的时候能三分钟给出答案的系统才是好系统。6.3 移动端与硬件对接扩展再往后走这套系统可以往移动端延伸。Vue 技术栈顺手就可以用 uni-app 出一套扫码盘点的小程序后端接口基本复用还是挺划算的。硬件方面超市系统绕不开小票打印机和钱箱。小票打印机通常走 ESC/POS 指令后端生成打印内容通过网口或 USB 传给打印机前端只需要一个按钮触发打印接口就行。电子秤对接稍微复杂一点称重商品通过串口或网口把重量传过来但大部分管理类源码不会涉及真要做了优先用现成的称重集成 SDK别自己解析协议。我在实际使用中发现越往后做越能理解当初为什么这类系统要把业务单据和库存流水分得那么清楚。你加任何新功能只要单据有状态、流水有记录、金额用对类型基本不会出大乱子。做管理系统最重要的不是炫技而是每一步操作都有据可查每一个数字都经得起对账。最后再分享一个小技巧接手一套源码第一周别急着改功能把数据库的每张表主键、外键、唯一索引、常用查询字段先整理成一张脑图然后跟着业务单据把数据流走一遍。这套超市管理系统我前前后后陪客户调整了不下十次每次都是从“对完账、顺着流水查一遍”开始真正把数据流吃透了后面加功能、修 Bug 都会轻松很多。
