简介：这是一套面向制造型企业的生产管理系统完整源代码，涵盖生产计划、物料需求、库存管理、进度跟踪、质量控制与订单管理等核心模块，适合有ASP编程基础、希望学习或二次开发制造类信息系统的开发人员使用。资源包共165个文件，以97个asp动态页面为主体，对应采购入库、销售出库、原料领料、成品管理和员工管理等功能逻辑；辅以css样式、js交互、gif/jpg图片素材及htm页面，并含db/mdb数据库文件和exe辅助工具，整体压缩包仅1.33MB，结构紧凑便于快速部署。系统内置MRP物料需求计算、库存预警、条形码/RFID进度采集、质量检验与不合格品处理、报表分析等完整业务链，数据库设计覆盖原材料、在制品与成品三类库存对象，支持与ERP/CRM/SCM系统集成，可作为企业信息化改造或课程设计的参考基座。目前已有2002人学习下载，对想掌握传统ASP生产管理业务流程、理解模块化开发与权限控制的开发者而言，具备较高的实战参考价值。
1. 生产管理系统源代码：先搞清它在解决什么问题
拿到生产管理系统源代码时，很多开发者的第一反应是赶紧编译、启动、看页面。但一个真实车间里，这套系统的难点从来不在页面，而是工单状态怎么流转、报工时库存怎么扣、质检不合格怎么回退。一套能用的生产管理系统源代码，核心是把"排产-领料-加工-报工-入库"这条链路用数据串起来，让操作工在终端录报工，计划员看工单进度，仓库看物料占用。本文要讲的是把这样的源码读懂、跑起来、并按业务改动的完整路径。我以一套常见的 Spring Boot + Vue 前后端分离源码为对象，带你走一遍从环境初始化到二次开发的落地流程。适合准备接手 MES、小 ERP、车间管理系统的开发者，也适合打算自己从零拼一套生产流程管理系统的人。
2. 拆解一套可落地的生产管理系统：技术选型与核心模块
先讲清楚我为什么总把 Spring Boot + Vue + MySQL 当作这类系统的默认组合。生产管理系统的难点是数据关系密集，工单要挂物料，物料要挂工序，报工要动库存，中间还夹着质检。Spring Boot 负责把事务和接口管起来，Vue 让车间用户不用装客户端，MySQL 则让排产和库存这种强一致数据有地方可靠落地。相比老式单体 JSP 系统，前后端分离的最大好处是车间终端和办公室看板可以复用同一套接口；相比 Python 系的轻量框架，Java 生态在多人维护、插件质量和事务控制上更稳。接手一套源码时，如果看到前后端两块代码，先别急着启动，第一步应该是把模块边界画出来：前端管录入与展示，后端管业务规则和事务，数据库管约束。生产管理系统源代码之所以让人觉得头大，不是类写得多，而是每张表都和其他表藕断丝连，理清依赖关系才走得动。
2.1 为什么是 Spring Boot + Vue 而不是单体 JSP
我见过不少旧系统把页面、SQL、业务逻辑全揉在 Tomcat 的 JSP 里，改一个下拉框都可能要重启服务。新写的或重构过的生产管理系统源码，绝大多数是 Spring Boot 做接口、Vue 做单页应用、MyBatis 或 MyBatis-Plus 管 SQL。选这套不是因为流行，而是边界清楚：后端 Service 层只谈生产规则，前端只谈交互，数据库表设计只谈约束。这样拆开以后，车间加一台扫码枪、加一块大屏，都只需要新增前端页面，后端接口几乎不动。
如果你准备在源码上做二次开发，我建议优先看三个文件：pom.xml 里的依赖版本、application.yml 里的数据源配置、以及数据库初始化脚本里的表注释。这三个文件能告诉你这套系统允许你改到什么程度。版本方面不用追求最新，Spring Boot 2.x 配 MyBatis-Plus 就是大多数 MES 源码的真实水平，够用且资料多。核心依赖我给一个参考，具体版本以你手上的源码为准：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency>这里要注意，MyBatis-Plus 的版本必须和 Spring Boot 主版本兼容。如果你启动时报 BeanCreationException，多半是 3.5.3 和 Spring Boot 2.6 以下的自动配置冲突，换个 3.4.x 就能解决。pom.xml 里如果还有 lombok，也要确认 IDE 装好了插件，否则实体类的 getter 和 setter 全是红的。
2.2 核心数据模型：物料、工序、工单、报工如何关联
生产管理系统数据模型看起来表很多，核心其实是一棵以工单为主干、以物料和工序为枝叶的树。物料表存"是什么"，工序表存"怎么做"，工单表存"做多少"，报工表则记录"每道工序实际做了多少"。我建表时有个习惯，所有业务表都要带 version 字段，后面讲并发时会用到；所有与库存相关的字段用 DECIMAL，不用浮点。下面这段 SQL 是这类源码里最常见的骨架，你可以拿它对比手上的项目。
CREATE TABLE `material` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '物料ID', `material_no` VARCHAR(32) NOT NULL COMMENT '物料编码', `material_name` VARCHAR(64) NOT NULL COMMENT '物料名称', `spec` VARCHAR(64) DEFAULT NULL COMMENT '规格', `version` INT NOT NULL DEFAULT 0 COMMENT '乐观锁版本号', PRIMARY KEY (`id`), UNIQUE KEY `uk_material_no` (`material_no`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='物料主数据'; CREATE TABLE `process` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '工序ID', `process_no` VARCHAR(32) NOT NULL COMMENT '工序编码', `process_name` VARCHAR(64) NOT NULL COMMENT '工序名称', `sort_no` INT NOT NULL DEFAULT 0 COMMENT '同一工艺流程中的工序顺序', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='工序定义'; CREATE TABLE `production_order` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `order_no` VARCHAR(32) NOT NULL COMMENT '工单号', `material_id` BIGINT NOT NULL COMMENT '生产物料ID', `qty` DECIMAL(12,2) NOT NULL COMMENT '计划数量', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0草稿 1已下发 2生产中 3已完成 4已关闭', `version` INT NOT NULL DEFAULT 0, PRIMARY KEY (`id`), KEY `idx_material` (`material_id`), CONSTRAINT `fk_order_material` FOREIGN KEY (`material_id`) REFERENCES `material` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='生产工单'; CREATE TABLE `work_report` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `order_id` BIGINT NOT NULL COMMENT '工单ID', `process_id` BIGINT NOT NULL COMMENT '工序ID', `report_qty` DECIMAL(12,2) NOT NULL COMMENT '报工数量', `report_time` DATETIME NOT NULL COMMENT '报工时间', `operator_id` BIGINT NOT NULL COMMENT '操作员ID', PRIMARY KEY (`id`), KEY `idx_order_process` (`order_id`, `process_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='工序报工记录';这里要注意的是外键的粒度。很多生产管理系统源码为了性能会故意不建物理外键，只留索引和字段名注释，靠 Service 层保证引用关系。我不反对这样做，但新手二开时经常会因为某个表的 ID 关联错字段而查出脏数据，所以宁可像上面这样建物理外键，让数据库在报错时把问题暴露出来，而不是让数据悄悄写坏。报工表比想象中复杂，同一张工单在多道工序上要反复报工，所以用 order_id 加 process_id 作为业务键；后面做库存扣减时，还要从报工记录反推物料消耗，这张表就是最直接的凭据。工单状态字段我在枚举里定义成数字，因为前端下拉框和数据库中转都方便，真要看含义再查枚举类即可。这套模型看起来简单，但足以支撑一个几万行规模的小型生产管理系统，再往上加批次号、BOM 版本、工位字段，都是在这棵树上长分支。
3. 把源码跑起来：环境准备、初始化与最小启动命令
拿到生产管理系统源代码，第一个要跑通的是数据库，先于后端和前端。因为 Spring Boot 启动时如果连不上数据库，大概率直接报错退出；反过来数据库就绪了，后端起没起都有排查头绪。环境方面我要求至少有 MySQL 8.0 和 JDK 8 以上，MySQL 5.7 跑多数旧版源码也没问题，但时区配置会有些差别。数据库初始化脚本一般在源码根的 sql 或 doc 目录下，顺序不能乱：先建库，再执行表结构脚本，最后执行 data 脚本。很多第一次上手的人直接双击运行整个 sql 文件，结果被外键约束卡在中间，这时候拆开执行就是最快的排错方式。
3.1 初始化数据库：建库、执行脚本与基础主数据
# 1. 创建数据库并指定字符集 mysql -uroot -p -e "CREATE DATABASE prod_mgmt DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;" # 2. 按顺序执行表结构脚本 mysql -uroot -p prod_mgmt < sql/01_schema.sql # 3. 导入基础数据：物料、工序、用户、角色 mysql -uroot -p prod_mgmt < sql/02_data.sql # 4. 验证是否导入成功 mysql -uroot -p -e "USE prod_mgmt; SHOW TABLES; SELECT COUNT(*) FROM material;"执行成功后能看到业务表都在，material 表至少有几十条物料。这里我把建库和数据脚本分开执行，是为了让 MySQL 的 utf8mb4 设置生效后再写入中文备注，避免中文乱码。data 脚本里一般带的还有管理员账号、部门、车间配置，这些基础数据是后续页面能下拉出物料和生产线的关键，千万不要为了省事跳过导入。如果执行过程报外键错误，不要急着删表重建，先看是哪个批次的脚本引用了还没创建的表，多半是把表结构脚本里的建表顺序搞反了。
基础数据这部分，很多源码的第二版会为了演示方便，在 data 脚本里放一个统一的演示车间，物料编码和工序编码都有固定前缀。你真正切到生产环境时，要把这些演示数据清掉，重新录入真实的物料和工艺路线。清数据时注意不要直接用 DELETE FROM 把表清空，因为自增 ID 不会重置，后面新数据的 ID 直接从几百甚至几千开始，看日志时容易恍惚。要么用 TRUNCATE，要么在初始化脚本里预留 ID 段。
3.2 启动后端与前端：端口、配置与首个接口验证
数据库就绪后，后端启动前要改 application.yml。最常改的是数据源密码和端口，其次是多环境配置：本地开发用 dev 配置，服务器用 prod 配置，二开时先确认当前激活的是哪个环境，否则会出现本地连不上数据库，却因为加载了 prod 配置而一时看不懂。下面是我惯用的最小配置，放在 src/main/resources/application-dev.yml 里。
server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/prod_mgmt?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: root driver-class-name: com.mysql.cj.jdbc.Driver jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: mapper-locations: classpath*:/mapper/**/*.xml configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl注意 serverTimezone=Asia/Shanghai，MySQL 8 的驱动默认时区是 UTC，不配这个参数你会在查询日期字段时发现少了 8 小时。map-underscore-to-camel-case 是几乎所有 Java 生产管理源码的标配，它让数据库的 order_no 自动映射成 orderNo，省掉大量手写映射代码。mapper-locations 指向 XML 文件位置，如果你发现 Mapper 接口找不到 SQL，多半是这里路径和实际目录不一致。启动后端用 mvn spring-boot:run 或打好的 jar 都行，开发阶段我更推荐在 IDE 里直接运行启动类，报错能直接看堆栈。看到 Tomcat started on port 8080，说明后端起来了。
前端 Vue 项目一般在 web 目录下，先 npm install 再 npm run dev。前后端联调最常见的坎是跨域，开发环境两种解决办法：后端加 CORS 过滤器，或者前端配置代理。我习惯让前端走代理，因为上线后前后端很可能在同域下，配置文件改起来更平滑。
// vue.config.js module.exports = { devServer: { port: 8081, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } };配置好后，前端页面里请求 /api 开头的接口都会被转发到 8080 端口。验证最小链路的方式是调一个不需要登录态的健康检查接口或登录接口，比如在浏览器直接访问 http://localhost:8081/api/health，如果能返回 JSON，说明数据库、后端、前端代理三层都已经打通。这一步之后再去点页面上的工单查询，看到数据列表才不奇怪。启动顺序是从下往上，排错顺序则是从浏览器往数据库一层层退，这是我在源码环境上摸出来的习惯。
4. 按业务改代码：工单流转与报工逻辑的二次开发
整个生产管理系统源代码里，最常被二次开发改动的就是工单状态机和报工接口。业务上工单从草稿变成下发、进入生产中、全部完成后关闭；报工则是把"计划数量"逐步变成"实际数量"，同时拉动库存。改动这两个地方时，最怕的是没有守住状态边界和事务边界，下面分别说。
4.1 工单创建到下发：状态机怎么设计
状态机不是非得引入工作流引擎，多数生产管理源码用一张状态字段加上 Service 层校验就能管住。我的设计原则是状态流转必须走统一入口，不允许在 Controller 里直接 setStatus。比如工单下发，Service 里更新状态前先判断当前状态是不是草稿，否则直接抛业务异常。下面这段代码展示了典型的改法。
public void dispatchOrder(Long orderId) { ProductionOrder order = orderMapper.selectById(orderId); if (order == null) { throw new BizException("工单不存在"); } OrderStatus current = OrderStatus.of(order.getStatus()); if (current != OrderStatus.DRAFT) { throw new BizException("只有草稿状态的工单才能下发，当前状态：" + current.getDesc()); } order.setStatus(OrderStatus.DISPATCHED.getCode()); order.setDispatchTime(LocalDateTime.now()); orderMapper.updateById(order); }这段代码看起来简单，但它把两个关键规则固定住了：状态的判断在 Service 层而不在页面，状态的变更通过调用方法而不是直接暴露字段。前端工单列表里的"下发"按钮，只能调用这个接口，不能自行更新状态。生产管理系统后期容易翻车的点，往往就是有人为了省事，在数据库里手工把某张工单的状态改了，导致后续报工流程全部错乱。改状态一定要走代码入口，哪怕是一条 SQL 也要在注释里写明为什么。状态码用枚举管理，OrderStatus.of 用来做转换，比到处写魔法数字安全得多。
如果业务上有工单取消、暂停、返工这些动作，我不建议把状态字段无限扩展，而是给工单加一个子状态或者叫 flag 字段。比如暂停只是临时挂起，主状态还是生产中，关闭只是终止后续流程，不改变已经完成的报工数据。这样设计报表统计时不用到处判断状态组合，也避免了同时出现"已关闭但有报工数据"这种别扭状态。工单完成条件也值得单独写清楚：所有工序的已报工数量都不小于计划数量，并且质检合格批次已经入库，缺一不可。
4.2 报工与质检联动：事务边界和库存扣减
报工是生产管理系统源代码里事务最密集的地方。一次报工至少要干三件事：插入报工记录、更新工单已报工数量、扣减物料库存。这三件事必须在一个事务里完成，否则就会出现报工记录有了但库存没扣的脏数据。常见的做法是在 Service 方法上加 @Transactional，并且把检查库存、更新工单、插入记录都放进同一个方法里。下面这段是简化后的报工逻辑。
@Transactional(rollbackFor = Exception.class) public ReportResult report(ReportRequest req) { ProductionOrder order = orderMapper.selectById(req.getOrderId()); if (order.getStatus() != OrderStatus.DISPATCHED.getCode() && order.getStatus() != OrderStatus.IN_PROCESS.getCode()) { throw new BizException("工单不处于可报工状态"); } BigDecimal reported = getReportedQty(order.getId()); BigDecimal remainQty = order.getQty().subtract(reported); if (req.getReportQty().compareTo(remainQty) > 0) { throw new BizException("报工数量超过未报工数量"); } // 扣库存，这里省略库存表的更新 SQL inventoryService.deduct(order.getMaterialId(), req.getReportQty(), req.getOrderId()); // 插入报工记录 WorkReport report = new WorkReport(); report.setOrderId(order.getId()); report.setProcessId(req.getProcessId()); report.setReportQty(req.getReportQty()); report.setReportTime(LocalDateTime.now()); report.setOperatorId(req.getOperatorId()); workReportMapper.insert(report); return new ReportResult(report.getId()); }事务注解用 rollbackFor = Exception.class，而不是默认的 RuntimeException，是为了让 SQL 异常和业务异常都能回滚。库存扣减在报工之前还是之后，取决于系统对负库存的容忍度：先扣库存再写报工，如果写报工失败，库存会因事务回滚自动恢复；如果反过来，就可能在并发时报工成功但扣减失败。报工之后通常还要触发质检任务，质检不通过时，要么把这批报工数量冲红，要么进入返工流程。冲红在实现上不要直接删报工记录，而是插入一条负数量记录，这样报表统计才有完整的追溯轨迹。
质检和报工是否在一个事务里，要看业务要求：质检是异步的，建议放宽成独立接口，质检员在终端确认后再调"合格入库"接口；如果质检必须在报工后立刻同步完成，那就把质检状态一起写进报工表。先想清楚这两条，再动手拆分事务，否则代码写出来很容易在并发下出现对不上的账。我在实际项目里见过最典型的问题，就是报工接口里调用远程质检服务，远程服务超时导致整个事务回滚，操作工点了几次都报不上工。这种场景要做一个补偿机制，而不是无限加大事务范围。
5. 生产管理系统源码的二开避坑：5个常见问题
5.1 初始化脚本执行到一半报外键约束失败
现象：执行 sql/01_schema.sql 时，中途提示 Cannot add foreign key constraint，但表看起来已经建了不少。原因：脚本里建表顺序没有按依赖排列，被引用的父表还没创建，比如 production_order 引用了 material，但 material 的建表语句在后面。解决：不要一个脚本从头跑到尾，拆成每张表一个 SQL 文件，或者手动把父表放在最前面。生产管理系统源码的表依赖通常集中在物料、工单、报工之间，把物料和工序放最前，工单其次，报工和库存流水放最后。如果脚本已经跑了一半，优先 DROP 掉刚建的表，再按正确顺序执行，而不是在失败点硬改表结构。
5.2 报工成功后库存变成了负数
现象：操作工连续报工，库存却出现 -5 这种负数，删除报工记录后库存也没恢复。原因：报工前没有检查库存，或者检查库存和扣减之间没有加锁，两个并发请求同时读到库存足够，然后各自扣了一笔。解决：扣库存的 SQL 带上"库存 >= 扣减量"这个条件，或者先用 SELECT ... FOR UPDATE 锁住物料行。我习惯用带条件更新，一条 SQL 解决并发问题：
UPDATE material_stock SET stock_qty = stock_qty - #{qty} WHERE material_id = #{materialId} AND stock_qty >= #{qty};如果更新行数为 0，说明库存不足，直接抛业务异常让事务回滚。这一步比任何应用层判断都靠谱，因为数据库的行锁天然保证了同一时刻只有一个事务能扣减同一物料。报工表里的负数量冲红记录也要注意，它会让报表里的累计报工数量看着正常，但库存流水会多出两条，统计时要按净数量算。
5.3 前端调接口报 404，但后端日志显示请求已进入
现象：页面点击工单查询，Network 面板显示 404，后端控制台却能打印出对应的 Controller 日志。原因：前端和后端的路由前缀不一致。常见的是前端请求 /api/report，后端接口路径是 /api/v1/report，或者代理配置把 /api 转发到了错误的 context-path。解决：先看后端 Controller 的 @RequestMapping 类级注释，再看前端 api 模块里的 baseURL。如果是 Spring Boot 配置了 server.servlet.context-path，那代理 target 也要对应改。我见过一个翻车案例，后端 context-path 写成 /mes，前端 proxy 只配了 /api 到根路径，结果所有请求都落在了 404 上。解决方法就是在代理配置里多配一条。
5.4 查询出来的日期比数据库里的时间少了 8 小时
现象：报工时间页面上显示 02:00，数据库里明明是 10:00。原因：MySQL 连接串没有 serverTimezone=Asia/Shanghai，JDBC 驱动用了 UTC，Jackson 也没有设置 GMT+8，两层叠加导致日期被格式化时减了 8 小时。解决：在 application.yml 里同时配好连接串时区和 Jackson 时区，就是前面 3.2 节里那两行配置。注意如果数据已经写入了错误的日期，修配置后要手动 UPDATE 一次把历史数据改回来，这个我在项目里踩过，报表按日统计对不上账，排查了很久才发现是时区问题。
5.5 多人同时报工，最后一条覆盖了前面记录
现象：同一工单同一工序，两个人各报 100，数据库里却只有一条记录。原因：报工表缺少唯一约束，或者代码里更新工单已报工数量时没有并发控制，两个事务先读后写，后写的把前面覆盖了。解决：给 work_report 表加上 order_id、process_id、operator_id、report_time 这些字段的联合唯一约束不一定现实，因为同一操作员可能在同一分钟报两次。更稳的是用乐观锁，在 production_order 表上做版本控制。下面这段是更新工单状态的 SQL，带上 version 条件：
UPDATE production_order SET reported_qty = reported_qty + #{qty}, version = version + 1 WHERE id = #{orderId} AND version = #{version};如果更新行数为 0，说明版本已经变化，需要把当前工单重新查出来再算一次剩余数量。这个技巧看着简单，但能避免绝大多数并发报工的脏数据。生产管理系统里最怕的就是账实不符，版本字段相当于给数据加了一道保险。
6. 从能跑到能上线：验证方法与我常用的一个进阶技巧
源码本地跑通只是第一步，真正上线前要用脚本把完整业务流程过一遍，而不是只在页面上点几个按钮。我常用的是一个 Bash 脚本，依次调用登录、建工单、下发、报工、入库接口，每一步用 jq 校验返回结果，出错立即退出。这套流程验证的不只是接口通不通，还有事务边界和状态机是否正确。脚本里建工单数量用可变参数传入，配合随机数生成工单号，可以反复跑而不产生脏数据。
进阶技巧是在工单号生成上融入批次规则。生产管理系统的工单号经常是生产部门最能感知的字段，我用日期加流水号来生成：YYYYMMDD + 车间编号 + 四位流水号，后端用 Redis 或数据库序列保证并发下不重复。生成的逻辑放在独立的 generator Service 里，所有创建工单的入口都调它，避免页面和接口各写一套导致重号。工单号一旦生成就不允许修改，只在关闭或作废时做标记，这样追溯订单和批次时能顺着工单号一路查到报工和质检记录。这套规则对报表按月统计也友好，因为日期就嵌在编号里，不需要额外的分区字段。
我自己的习惯是，改生产管理系统源码时，先改状态机和事务边界，再碰页面和样式。因为业务规则没有守住，界面做得再好看，上线后也会被车间用户骂"系统数据和现场对不上"。报工逻辑里那个 version 字段，几乎每个项目都帮我救过场，现在已经是我的骨架标配。每套生产管理系统源代码都有自己的脾气，但数据一致性、状态可控、库存不出现负数这三条底线是通用的，守住这三条，系统再破也坏不到哪去。希望帮到你。
本文还有配套的精品资源，点击获取
