简介这是一套面向中小企业开发者与Java学习者的开源ERP进销存系统源码围绕采购、销售、库存与财务等核心业务帮助读者理解企业资源计划系统的完整实现思路。压缩包共1448个文件约14.26MB以png、gif、jpg等界面素材java后端代码js、html、css、jsp前端页面以及xml、json、properties配置和sql数据库脚本为主另含jar依赖与少量php、aspx等文件覆盖前后端与数据库各层。系统采用MySQL存储商品、客户、供应商与交易数据包含进销存模块、财务核算、角色权限管理、报表分析及数据库初始化脚本并预留API集成扩展空间。目前已有769人学习下载适合希望二次开发或搭建进销存管理平台的读者参考可据此掌握模块划分、表结构设计与部署要点。1. 拿到一套 ERP 进销存源码先别急着改代码很多做企业信息化的朋友第一次拿到一套 ERP 进销存系统源码时第一反应是打开 IDE 改界面、加字段、调菜单。我见过太多这样的案例某开发者拿到源码当天就动手改采购单逻辑结果第三天发现库存扣减对不上第五天发现财务凭证生成错乱最后只能推倒重来。这套源码本质上是一套基于 MySQL 的关系型业务系统核心链路是「采购入库 → 库存变动 → 销售出库 → 应收应付 → 报表汇总」任何一处改动都会沿着这条链路传导。它适合中小型商贸公司、批发零售场景也适合作为二次开发的学习底座。但前提是你得先把它跑起来、把数据流摸清楚再谈改。这一章不讲代码只讲拿到源码后前两小时该干什么。2. 环境搭建与数据库初始化把 MySQL 跑通再谈业务2.1 技术栈确认与依赖清单在动手之前先把源码包里的技术栈摸清楚。常见的 ERP 进销存源码后端多为 JavaSpring Boot / SSM或 PHPThinkPHP / Laravel前端多为 Vue 或 jQuery 老框架数据库统一是 MySQL 5.7 或 8.0。打开源码根目录先找这几个文件pom.xml或composer.json依赖管理、application.yml或.env数据库配置、sql/目录建表脚本。这三个文件决定了你能不能跑起来。我一般会先看sql/目录下的文件数量和大小。如果只有一个init.sql说明建表和数据在一起如果有schema.sql和data.sql分开说明结构清晰适合二次开发。注意看建表语句里的存储引擎InnoDB 是必须的MyISAM 不支持事务进销存系统里库存扣减和财务凭证必须走事务遇到 MyISAM 直接改。依赖版本这块血泪经验是不要盲目升级。源码里写死 Spring Boot 2.3.x你就别升到 3.xJDK 版本从 8 升到 17 看起来爽但 MyBatis 和某些老工具类会直接翻车。常见做法是先用源码推荐的版本跑通再考虑渐进升级。2.2 数据库建库与导入的完整命令假设你已经装好了 MySQL 8.0接下来按顺序执行。先建库字符集用utf8mb4排序规则用utf8mb4_general_ci不要用utf8否则商品名称里的特殊字符会丢。# 登录 MySQL注意 -p 后面不要加空格 mysql -u root -p # 建库字符集必须 utf8mb4 CREATE DATABASE erp_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; # 建一个专用账号别用 root 跑业务 CREATE USER erp_user% IDENTIFIED BY Erp2024; GRANT ALL PRIVILEGES ON erp_db.* TO erp_user%; FLUSH PRIVILEGES; EXIT; # 导入建表脚本注意路径替换成你本地的 mysql -u erp_user -p erp_db /path/to/sql/schema.sql # 导入初始数据 mysql -u erp_user -p erp_db /path/to/sql/data.sql这段命令的逻辑说明先建库再建账号权限只给erp_db避免误操作其他库。导入时用-u erp_user而不是 root提前验证账号权限是否正常。如果schema.sql里包含CREATE DATABASE语句先注释掉再导入否则会报库已存在。参数说明utf8mb4_general_ci比utf8mb4_unicode_ci快进销存系统里商品名称、客户地址用 general_ci 足够。如果源码要求utf8mb4_0900_ai_ciMySQL 8.0 默认那就按源码来别自作主张改排序规则否则外键关联可能出问题。2.3 配置文件修改与启动验证数据库导入完成后找到后端配置文件。Spring Boot 项目改application-dev.ymlPHP 项目改.env。重点改四个参数数据库地址、端口、账号、密码。连接池参数也要看一眼进销存系统并发不高但库存扣减时会有行锁竞争连接池最小空闲连接建议设为 5最大 20。# application-dev.yml 关键片段 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/erp_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: erp_user password: Erp2024 hikari: minimum-idle: 5 maximum-pool-size: 20 connection-timeout: 30000改完后启动项目观察控制台日志。如果看到Started Application in X seconds说明后端起来了。前端如果是 Vue 项目npm install后npm run dev注意代理配置里的后端地址要和实际端口一致。启动成功后用默认账号登录常见是 admin/123456进去先看「商品管理」「库存查询」「采购订单」三个菜单能不能正常打开数据能不能加载。这一步过了环境就算通了。3. 核心表结构与库存扣减逻辑别让并发把你坑了3.1 进销存三张主表与关联关系任何 ERP 进销存系统核心都绕不开三张表商品表、库存表、出入库流水表。商品表存基础信息编码、名称、规格、单位库存表存当前数量商品 ID、仓库 ID、数量、锁定数量流水表存每一次变动单据号、商品 ID、变动类型、变动数量、变动后数量。这三张表的关系是商品表 1 对多 库存表库存表 1 对多 流水表。常见做法是库存表加一个version字段做乐观锁或者直接用SELECT ... FOR UPDATE做悲观锁。我一般会先看源码用的是哪种。如果是乐观锁扣减时 SQL 长这样UPDATE stock SET quantity quantity - #{num}, version version 1 WHERE product_id #{productId} AND warehouse_id #{warehouseId} AND quantity #{num} AND version #{version};这条 SQL 的逻辑是只有库存充足且版本号匹配时才扣减返回影响行数为 0 就说明扣减失败需要重试或提示。参数说明quantity #{num}是防止超卖的关键条件没有这个条件并发时库存会扣成负数。version字段是乐观锁标记每次更新加 1。如果是悲观锁SQL 是SELECT quantity FROM stock WHERE ... FOR UPDATE然后在事务里更新。悲观锁在并发高时容易死锁进销存系统并发通常不高两种都能用但源码用哪种你就跟着用哪种别混搭。3.2 库存扣减的完整事务流程库存扣减不是一条 SQL 就完事它必须和单据状态、流水记录在同一个事务里。我拆过一套源码它的销售出库流程是这样的先校验订单状态再锁库存再扣减再写流水再改订单状态。五步必须在同一个Transactional里任何一步失败全部回滚。Transactional(rollbackFor Exception.class) public void saleOutbound(Long orderId) { // 1. 查订单校验状态 Order order orderMapper.selectById(orderId); if (order.getStatus() ! OrderStatus.PAID) { throw new BizException(订单状态不允许出库); } // 2. 遍历明细逐条扣减库存 for (OrderItem item : order.getItems()) { // 3. 乐观锁扣减返回 0 说明库存不足或版本冲突 int affected stockMapper.deduct(item.getProductId(), item.getWarehouseId(), item.getNum(), item.getVersion()); if (affected 0) { throw new BizException(库存不足或并发冲突商品 item.getProductId()); } // 4. 写流水 stockFlowMapper.insert(buildFlow(item, order)); } // 5. 改订单状态 order.setStatus(OrderStatus.OUTBOUND); orderMapper.updateById(order); }这段代码的关键点rollbackFor Exception.class确保任何异常都回滚包括检查异常。扣减返回 0 时直接抛异常整个事务回滚不会出现「扣了一半」的情况。流水记录在扣减成功后写入保证流水和库存一致。参数说明item.getVersion()是从库存表查出来的版本号如果源码里没有版本号字段说明用的是悲观锁那deduct方法里应该先SELECT ... FOR UPDATE。两种方式不要混用否则锁失效。3.3 库存对账与流水追溯系统跑一段时间后库存表的数据和流水表汇总的数据可能对不上。常见原因是有人直接改数据库、事务中途失败但没回滚干净、或者并发扣减时乐观锁重试逻辑有 bug。我一般会写一个对账 SQL定期跑一遍。-- 对账库存表当前数量 vs 流水表汇总数量 SELECT s.product_id, s.warehouse_id, s.quantity AS stock_qty, COALESCE(SUM(f.change_num), 0) AS flow_qty, s.quantity - COALESCE(SUM(f.change_num), 0) AS diff FROM stock s LEFT JOIN stock_flow f ON s.product_id f.product_id AND s.warehouse_id f.warehouse_id GROUP BY s.product_id, s.warehouse_id, s.quantity HAVING diff ! 0;这条 SQL 的逻辑是把库存表的当前数量和流水表的变动汇总做对比diff不为 0 的就是对不上的记录。参数说明change_num是流水表的变动数量入库为正、出库为负汇总后应该等于当前库存。如果源码的流水表用type字段区分出入库那汇总时要加CASE WHEN转换正负号。发现对不上之后不要直接改库存表先查流水表里该商品的所有记录按时间排序找到第一笔对不上的流水往前推。常见原因是某笔出库流水写了但库存没扣或者库存扣了但流水没写。修复时补一笔调整流水而不是直接改库存数字这样追溯链才完整。4. 权限模块与二次开发入口改哪里不会崩4.1 权限表结构与菜单加载逻辑ERP 系统的权限模块通常由五张表组成用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。用户登录后后端根据用户 ID 查角色再根据角色查菜单前端拿到菜单树后动态渲染路由。这套逻辑看起来简单但改的时候容易崩因为菜单表和前端路由是强绑定的。我一般会先看菜单表里的path字段和前端路由配置文件是否一致。如果源码前端是 Vue路由文件在src/router/index.js菜单表里的path必须和路由里的path完全匹配否则点击菜单会白屏。常见做法是新增菜单时先在菜单表插入记录再在前端路由文件里加对应组件两边path和component要对上。-- 查角色对应的菜单树 SELECT m.id, m.parent_id, m.name, m.path, m.component FROM menu m JOIN role_menu rm ON m.id rm.menu_id WHERE rm.role_id #{roleId} AND m.status 1 ORDER BY m.sort_order;参数说明status 1表示菜单启用sort_order控制排序。如果源码没有status字段说明菜单不支持禁用二次开发时要注意别删菜单只能改name和path。4.2 新增业务模块的四个步骤二次开发最常见的需求是加一个新模块比如「供应商对账」。按这四步走基本不会崩。第一步建表。新模块独立建表不要往现有表里加字段。表名加前缀比如biz_supplier_reconcile避免和源码原有表冲突。第二步后端加 Controller、Service、Mapper。Controller 里加RequiresPermissions(biz:reconcile:list)之类的权限注解Service 里写业务逻辑Mapper 里写 SQL。注意包名要和源码一致否则 Spring 扫描不到。第三步菜单表插入记录。parent_id指向「财务管理」或「供应商管理」的菜单 IDpath设为/biz/reconcilecomponent设为biz/reconcile/index。第四步前端加路由和页面。路由文件里加{ path: /biz/reconcile, component: () import(/views/biz/reconcile/index.vue) }然后在views/biz/reconcile/下建index.vue。这四步的顺序不能乱先建表再写后端后端跑通了再配菜单和前端。我见过有人先改前端结果后端接口 404排查半天。4.3 权限注解与数据隔离权限注解只控制「能不能访问接口」不控制「能看哪些数据」。进销存系统里不同仓库的管理员只能看自己仓库的库存这需要在 SQL 里加数据隔离条件。// 在 Service 里获取当前用户的数据权限范围 Long userId SecurityUtils.getUserId(); ListLong warehouseIds warehouseService.getWarehouseIdsByUser(userId); // 查询库存时带上仓库范围 ListStock stocks stockMapper.selectByWarehouseIds(warehouseIds);参数说明getWarehouseIdsByUser根据用户角色查关联的仓库 ID 列表管理员返回全部普通用户返回部分。SQL 里用IN条件过滤。如果源码没有数据隔离逻辑二次开发时一定要补上否则不同仓库的人能看到别人的库存业务上会出大问题。5. 避坑与排查那些让我加班到凌晨的坑5.1 库存扣成负数现象并发测试时库存表出现负数流水表里出库数量大于入库数量。原因扣减 SQL 里没有quantity #{num}条件或者用了乐观锁但没检查影响行数直接更新了。解决在扣减 SQL 里强制加quantity #{num}更新后检查affected rows为 0 就抛异常回滚。如果是悲观锁SELECT ... FOR UPDATE之后要在事务里重新校验数量。5.2 单据编号重复现象采购订单号或销售订单号出现重复数据库唯一索引报错。原因单据编号生成用了SELECT MAX(no) 1并发时两个请求拿到同一个最大值。解决改用数据库序列或 Redis 自增或者用时间戳 随机数 用户 ID 组合。如果源码用的是MAX 1直接改成INSERT时用UUID或雪花算法生成别在应用层拼。5.3 事务不回滚现象库存扣减失败抛了异常但订单状态还是改了数据不一致。原因异常被try-catch吞了或者抛的是检查异常但Transactional没配rollbackFor。解决Transactional(rollbackFor Exception.class)必须加catch块里如果要处理异常处理完必须重新抛出RuntimeException否则事务不会回滚。5.4 菜单改了但前端不生效现象菜单表里改了path前端点击还是跳旧页面。原因前端路由是静态配置的菜单表只控制显示隐藏不控制路由跳转。解决改菜单表的同时同步改前端路由文件。如果源码支持动态路由检查后端返回的菜单树里component字段是否正确映射到前端组件路径。5.5 报表查询慢现象月度销售报表查询超过 10 秒数据库 CPU 飙升。原因流水表数据量大报表 SQL 没走索引或者用了SELECT *全表扫描。解决在流水表的create_time、product_id、warehouse_id上建联合索引报表 SQL 只查需要的字段避免SELECT *。如果数据量超过百万考虑按月分表或加汇总表。6. 二次开发进阶从能跑到好用6.1 用定时任务做库存日结库存对账不能靠人工跑 SQL我一般会加一个定时任务每天凌晨 2 点跑一次对账把差异记录写进日志表第二天上班直接看日志。Scheduled(cron 0 0 2 * * ?) public void dailyStockReconcile() { ListStockDiff diffs stockMapper.selectDiff(); if (!diffs.isEmpty()) { log.error(库存对账差异{} 条, diffs.size()); diffLogMapper.batchInsert(diffs); } }参数说明cron 0 0 2 * * ?表示每天凌晨 2 点执行。selectDiff就是前面那条对账 SQL。差异记录写日志表不要直接改库存保留追溯依据。6.2 用 AOP 记录关键操作日志进销存系统里谁改了库存、谁删了订单必须留痕。我一般会写一个 AOP 切面拦截所有带Log注解的方法把操作人、操作时间、方法名、参数写进日志表。Around(annotation(logAnno)) public Object around(ProceedingJoinPoint point, Log logAnno) throws Throwable { Object result point.proceed(); SysLog sysLog new SysLog(); sysLog.setUserId(SecurityUtils.getUserId()); sysLog.setMethod(point.getSignature().getName()); sysLog.setParams(JSON.toJSONString(point.getArgs())); sysLog.setCreateTime(new Date()); sysLogMapper.insert(sysLog); return result; }参数说明point.getArgs()是方法参数序列化后存库。注意别把密码之类的敏感参数记进去可以在切面里过滤。6.3 验证二次开发是否成功的三个检查点改完代码后别急着上线先过这三个检查点。第一库存对账 SQL 跑一遍diff必须为 0。第二并发测试跑一遍用 JMeter 模拟 50 个并发扣减同一商品库存不能为负流水条数要和扣减次数一致。第三权限测试跑一遍用不同角色的账号登录确认只能看到自己仓库的数据越权接口返回 403。这三个检查点过了基本可以放心。从那以后我每次改完库存相关代码都强制走一遍对账 SQL 和并发测试再也不敢直接点「保存」就完事。希望帮到你。本文还有配套的精品资源点击获取