简介这套生产管理系统源代码面向制造型企业的信息化建设者、具备一定编程与数据库基础的开发者以及希望进行二次开发的技术团队提供覆盖生产计划、物料需求计划、库存管理、生产进度跟踪、质量控制、订单管理、报表分析、系统集成与权限管理等核心模块的完整实现可用于学习制造业务流程与系统架构或作为企业定制开发的起点。压缩包共165个文件约1.33MB以97个asp动态页面为主体配合16个js脚本、9个css样式、25个gif与11个jpg界面素材以及db、mdb数据库文件和txt说明构成一套可直接部署研究的Web系统雏形。目前已有2007人学习下载说明其在同类教学与参考资源中具有一定认可度。读者可从中了解MRP运算逻辑、出入库与盘点流程、条码采集接口、质量检验与报表统计等具体实现并借鉴其数据模型与权限控制设计为后续扩展与维护打下基础。1. 生产管理系统源代码一套能跑起来的 MES 底座长什么样很多团队做生产管理第一步就卡在“从零搭还是买现成”上。买现成贵且改不动从零搭又容易在工单状态机、库存扣减、报工回写这几个地方反复翻车。我最近拆了一套生产管理系统源代码它把工单、物料、报工、库存、看板这几条主线都串起来了属于那种“拿来能跑、改起来有抓手”的底座型资源。适合两类人一是中小制造企业的信息化负责人想快速验证自己的业务流程二是接私活的开发者需要一个能交付的生产管理骨架。下面按“它是什么、怎么跑、坑在哪”的顺序拆给你看。2. 先看清架构这套生产管理系统源代码的模块划分与选型逻辑拿到一份源代码别急着npm install或mvn spring-boot:run。先花二十分钟把目录结构和依赖关系摸清楚比后面调试三天都值。这套代码的模块划分比较典型属于“前后端分离 单体后端 关系型数据库”的组合适合中小规模产线日工单量在几千级别完全扛得住。2.1 目录结构与技术栈拆解后端是标准的 MVC 分层controller负责接口、service放业务逻辑、mapper或repository管数据访问实体类单独一层。前端是管理后台常见的布局左侧菜单、顶部面包屑、主区域表格加弹窗表单。数据库用 MySQL表结构里能明显看到工单主表、工单工序表、物料表、库存流水表这几张核心表。技术栈上后端如果是 Java 系大概率是 Spring Boot MyBatis如果是 Node 系就是 Express 或 NestJS TypeORM。前端一般是 Vue 或 React 配 Element UI / Ant Design。这套组合的好处是招人容易、资料多、出问题搜得到答案。选型逻辑很朴素生产管理系统的核心诉求是“数据准确、流程可追溯”不需要高并发架构单体加关系型数据库反而是最稳的选择。提示先看pom.xml或package.json里的依赖版本确认 JDK / Node 版本要求版本不匹配是新手第一个翻车点。2.2 核心数据模型工单、物料、库存三张表的关联生产管理系统的命脉在数据模型。这套代码里工单表work_order是主表记录工单号、产品、计划数量、状态、计划开始和结束时间。工单工序表work_order_process挂在外键上一个工单拆成多道工序每道工序有负责工位、报工数量、良品数、不良数。物料表material存物料编码、名称、规格、单位。库存流水表inventory_flow记录每一次出入库的变动包括关联工单、变动数量、变动类型、操作时间。关联关系是工单引用产品产品通过 BOM 关联物料报工时按 BOM 扣减物料库存同时写一条库存流水。这个链路听起来简单但实际改代码时最容易在“报工扣料”这一步出错——扣多了库存对不上扣少了物料虚高。理解这三张表的关联后面改业务逻辑才有底。2.3 工单状态机从创建到完工的流转规则工单状态是这套系统的骨架。常见状态有待排产、已排产、生产中、已完工、已关闭。状态流转不是随便改字段而是有约束的只有“待排产”能排产只有“已排产”能开工报工数量累计达到计划数量才能转“已完工”。代码里一般用一个枚举类加状态校验方法来实现比如WorkOrderStatus.canTransitTo(target)。改这块代码时血泪经验是别直接改数据库里的状态字段来“修数据”一定要走业务方法否则库存流水和工单状态会对不上后面查账查到你怀疑人生。状态机的校验逻辑通常集中在 service 层的一个方法里找到它所有状态变更的入口就都清楚了。3. 把系统跑起来环境准备、数据库初始化与首次登录架构看清了接下来动手。这一章的目标是让你在本地把系统跑起来能登录、能看到工单列表、能走一遍报工流程。整个过程分环境准备、数据库初始化、后端启动、前端启动四步每步都有容易卡住的地方。3.1 环境准备与依赖安装先确认本机环境。Java 系需要 JDK 8 或 11看pom.xml里的java.versionMaven 3.6 以上Node 系需要 Node 16 或 18npm 或 yarn。数据库统一用 MySQL 5.7 或 8.0字符集设utf8mb4排序规则utf8mb4_general_ci。# 检查版本版本不对先别往下走 java -version mvn -v node -v npm -v mysql --version版本确认后后端进项目根目录执行依赖拉取前端进web或frontend目录执行安装。这一步的坑在于镜像源默认源拉包慢或超时换成国内镜像能省不少时间。Maven 改settings.xml的mirrornpm 用npm config set registry指向可用源。# 后端拉依赖Java 系示例 mvn clean install -DskipTests # 前端装依赖 cd web npm install-DskipTests是跳过测试编译首次跑通阶段没必要等测试。等系统稳定了再跑全量测试。前端安装如果卡在某个包上先删node_modules和package-lock.json重来比逐个排查快。3.2 数据库初始化建库、导表与初始数据数据库是这套系统的黑匣子初始化不对后面全是玄学问题。先建库再执行项目里的 SQL 脚本。脚本一般在sql或db目录下分建表脚本和初始数据脚本两个文件。-- 建库字符集必须 utf8mb4否则中文物料名会乱码 CREATE DATABASE mes_demo DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 建一个专用账号别用 root 跑应用 CREATE USER mes_applocalhost IDENTIFIED BY ChangeMe_2024; GRANT ALL PRIVILEGES ON mes_demo.* TO mes_applocalhost; FLUSH PRIVILEGES;建库后依次导入建表脚本和初始数据脚本。初始数据里通常有默认管理员账号、基础物料、示例工单。导入完检查三件事表数量对不对、管理员账号在不在、示例工单的状态是不是“待排产”。这三项正常数据库这关就过了。# 导入建表和初始数据注意顺序不能反 mysql -u mes_app -p mes_demo sql/schema.sql mysql -u mes_app -p mes_demo sql/data.sql注意如果脚本里写死了USE xxx或库名导入前先确认库名一致否则会导到不存在的库里报错。3.3 配置文件修改与前后端启动数据库通了改后端配置文件。找到application.yml或application.properties把数据源地址、账号、密码改成刚才建的。连接池参数首次跑通阶段用默认值就行别一上来就调优。# application.yml 关键片段 spring: datasource: url: jdbc:mysql://localhost:3306/mes_demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: mes_app password: ChangeMe_2024 driver-class-name: com.mysql.cj.jdbc.DriverserverTimezone必须显式指定不写的话 MySQL 8 驱动会报时区错误这是高频翻车点。改完启动后端看到端口监听日志就算成功。前端改vite.config或vue.config里的代理地址指向后端端口然后npm run dev启动。浏览器打开前端地址用初始数据里的管理员账号登录能看到工单列表页整条链路就通了。# 后端启动Java 系 mvn spring-boot:run # 前端启动 cd web npm run dev登录后先别急着点报工先去物料页和工单页各看一眼数据是否完整。数据不完整就报工后面库存对不上排查成本翻倍。4. 改业务不翻车工单报工与库存扣减的代码改造点系统跑起来只是起点真正的工作量在改业务。生产管理系统改得最多的两处是报工逻辑和库存扣减这两块改错数据就废了。这一章讲清楚改哪里、怎么改、改完怎么验证。4.1 报工接口的入参校验与幂等处理报工接口是高频调用入口车间扫码枪一扫就发一次请求。网络抖动导致重复提交是常态所以幂等必须做。这套代码里报工接口一般在WorkOrderController的report方法入参包括工单号、工序号、报工数量、良品数、不良数、操作人。改造第一步是加入参校验报工数量必须大于零良品加不良必须等于报工数量工单状态必须是“生产中”。校验不通过直接返回明确错误码别让脏数据进库。// 报工入参校验放在 service 层入口 public void validateReport(ReportDTO dto) { if (dto.getQty() null || dto.getQty() 0) { throw new BizException(报工数量必须大于0); } if (dto.getGoodQty() dto.getBadQty() ! dto.getQty()) { throw new BizException(良品数加不良数必须等于报工数量); } WorkOrder wo workOrderMapper.selectByNo(dto.getOrderNo()); if (!WorkOrderStatus.IN_PRODUCTION.name().equals(wo.getStatus())) { throw new BizException(工单不在生产中状态不能报工); } }幂等的做法是给报工请求加唯一键工单号 工序号 报工批次号。批次号由前端生成重复提交时数据库唯一索引直接拦截捕获异常后返回“已处理”。这样即使前端重试也不会重复扣库存。4.2 库存扣减的事务边界与并发控制报工成功后要按 BOM 扣减物料库存这一步必须在同一个事务里否则报工成功、扣料失败库存就虚高了。事务边界划在 service 方法上报工写库和库存扣减写库要么全成要么全败。Transactional(rollbackFor Exception.class) public void report(ReportDTO dto) { validateReport(dto); // 1. 写报工记录 reportMapper.insert(buildReport(dto)); // 2. 更新工单工序累计报工数 processMapper.addReportQty(dto.getOrderNo(), dto.getProcessNo(), dto.getQty()); // 3. 按 BOM 扣减库存并写流水 ListBomItem boms bomMapper.selectByProduct(dto.getProductCode()); for (BomItem bom : boms) { int need bom.getQtyPerUnit() * dto.getGoodQty(); int affected inventoryMapper.deduct(bom.getMaterialCode(), need); if (affected 0) { throw new BizException(物料库存不足 bom.getMaterialCode()); } inventoryFlowMapper.insert(buildFlow(dto, bom, need)); } }并发控制靠deduct的 SQL 实现UPDATE inventory SET qty qty - #{need} WHERE material_code #{code} AND qty #{need}。用条件更新而不是先查后改避免并发下超扣。返回影响行数为零就抛异常回滚这是最省事也最可靠的写法。4.3 改完怎么验证三条对账 SQL改完报工和扣料别靠肉眼点页面验证。写三条对账 SQL跑一遍就知道数据对不对。-- 1. 工单累计报工数是否等于报工记录之和 SELECT wo.order_no, wo.reported_qty, (SELECT COALESCE(SUM(qty),0) FROM report_record r WHERE r.order_no wo.order_no) AS sum_qty FROM work_order wo WHERE wo.reported_qty (SELECT COALESCE(SUM(qty),0) FROM report_record r WHERE r.order_no wo.order_no); -- 2. 库存当前值是否等于初始值加流水净额 SELECT i.material_code, i.qty, (SELECT COALESCE(SUM(CASE WHEN f.flow_typeIN THEN f.qty ELSE -f.qty END),0) FROM inventory_flow f WHERE f.material_code i.material_code) AS flow_net FROM inventory i WHERE i.qty (SELECT COALESCE(SUM(CASE WHEN f.flow_typeIN THEN f.qty ELSE -f.qty END),0) FROM inventory_flow f WHERE f.material_code i.material_code); -- 3. 已完工工单是否还有未完成工序 SELECT wo.order_no FROM work_order wo JOIN work_order_process p ON p.order_no wo.order_no WHERE wo.status FINISHED AND p.reported_qty p.plan_qty;三条 SQL 都返回空结果说明数据一致。任何一条有结果就顺着那条链路查。这套对账习惯建议固化下来每次改完业务逻辑都跑一遍比事后救火强得多。5. 避坑清单部署和二次开发中最容易踩的五个坑这套代码我前后部署过几次也帮人改过业务下面五个坑是出现频率最高的。每条按“现象、原因、解决”写照着排查能省不少时间。5.1 中文乱码从建库到连接串的字符集链路现象是物料名、工单备注里的中文变成问号或乱码。原因通常是链路上某一环字符集不是utf8mb4建库时用了默认latin1或者连接串没带characterEncodingutf8或者表字段排序规则不一致。解决方法是逐环检查SHOW CREATE DATABASE看库字符集SHOW CREATE TABLE看表字符集连接串补上useUnicodetruecharacterEncodingutf8。三处统一成utf8mb4后重启应用乱码消失。5.2 报工后库存对不上事务没生效的典型表现现象是报工记录有了但库存没扣或者扣了但流水没写。原因多半是Transactional没生效方法被同类内部调用、异常被 catch 后没重新抛出、或者类没被 Spring 管理。解决方法是确认报工入口方法是从 controller 直接调用的 public 方法异常统一往上抛rollbackFor显式写Exception.class。改完用 4.3 的对账 SQL 验证。5.3 前端代理 404开发环境跨域配置错误现象是前端页面能打开但所有接口请求 404 或跨域报错。原因是前端代理没配或配错请求没转发到后端端口。解决方法是检查vite.config或vue.config里的proxy配置target指向后端实际端口changeOrigin设为truerewrite规则和接口前缀对齐。改完重启前端 dev server别只刷新页面。5.4 工单状态改不动状态机校验拦截现象是点“开工”或“完工”没反应或者提示状态不允许。原因是工单当前状态不满足流转条件比如工单还是“待排产”就直接点开工。解决方法是先看工单当前状态按状态机规则走待排产→排产→开工→报工→完工。别为了图快直接改数据库状态字段那样库存流水会对不上后面查账更麻烦。5.5 初始账号登不进密码加密方式不匹配现象是输入初始数据里的账号密码提示密码错误。原因是初始数据里的密码是明文或某种哈希而登录逻辑用的是另一种加密方式比如 BCrypt。解决方法是看登录 service 里的密码校验逻辑确认用的加密算法然后用同样的算法生成一个密码哈希更新到用户表里。别直接把校验逻辑改成明文比对那是给自己埋雷。6. 进阶用法用看板 SQL 和定时任务把系统用出价值系统跑通、业务改对之后真正的价值在数据利用上。这套代码自带一个简单的看板页但默认指标比较基础。我一般会补两条 SQL 和一个定时任务把产能和库存预警做出来这样系统才从“能用”变成“好用”。6.1 产能看板按工序统计日产量的聚合 SQL产能看板的核心是按工序、按天聚合报工数据算出计划完成率和良品率。下面这条 SQL 直接喂给看板接口前端按工序分组渲染即可。SELECT p.process_name, DATE(r.report_time) AS report_date, SUM(r.qty) AS total_qty, SUM(r.good_qty) AS good_qty, ROUND(SUM(r.good_qty) / SUM(r.qty) * 100, 2) AS good_rate, SUM(p.plan_qty) AS plan_qty, ROUND(SUM(r.qty) / SUM(p.plan_qty) * 100, 2) AS finish_rate FROM report_record r JOIN work_order_process p ON p.order_no r.order_no AND p.process_no r.process_no WHERE r.report_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY p.process_name, DATE(r.report_time) ORDER BY report_date DESC, p.process_name;good_rate是良品率finish_rate是计划完成率两个指标放一起看能快速定位哪道工序是瓶颈。时间窗口按需改INTERVAL 7 DAY看月度就改 30。6.2 库存预警定时任务扫描安全库存库存预警不用实时算定时任务每天扫一次就够。逻辑是查所有物料当前库存低于安全库存的写一条预警记录前端看板读预警表展示。// 每天早八点扫描安全库存低于阈值的写预警 Scheduled(cron 0 0 8 * * ?) public void scanLowStock() { ListMaterial materials materialMapper.selectAll(); for (Material m : materials) { Integer qty inventoryMapper.selectQtyByCode(m.getCode()); if (qty ! null qty m.getSafetyStock()) { alertMapper.insert(buildAlert(m, qty)); } } }cron表达式按实际班次调整两班倒的厂可以改成每 12 小时扫一次。预警记录建议加唯一约束物料 日期避免同一天重复写。6.3 一个习惯每次改业务前先跑对账 SQL 留基线最后说个习惯。我改这套系统养成了一个规矩动业务代码之前先把 4.3 那三条对账 SQL 跑一遍把结果存成基线文件改完再跑一遍对比差异。这样任何一次改动引入的数据问题都能在当天定位到具体是哪次提交造成的而不是等月底对账才发现。从那以后我每次改报工或库存相关逻辑都强制走一遍“留基线、改代码、跑对账”的流程翻车次数明显少了。希望帮到你。本文还有配套的精品资源点击获取
简介这套生产管理系统源代码面向制造型企业的信息化建设者、具备一定编程与数据库基础的开发者以及希望进行二次开发的技术团队提供覆盖生产计划、物料需求计划、库存管理、生产进度跟踪、质量控制、订单管理、报表分析、系统集成与权限管理等核心模块的完整实现可用于学习制造业务流程与系统架构或作为企业定制开发的起点。压缩包共165个文件约1.33MB以97个asp动态页面为主体配合16个js脚本、9个css样式、25个gif与11个jpg界面素材以及db、mdb数据库文件和txt说明构成一套可直接部署研究的Web系统雏形。目前已有2007人学习下载说明其在同类教学与参考资源中具有一定认可度。读者可从中了解MRP运算逻辑、出入库与盘点流程、条码采集接口、质量检验与报表统计等具体实现并借鉴其数据模型与权限控制设计为后续扩展与维护打下基础。1. 生产管理系统源代码一套能跑起来的 MES 底座长什么样很多团队做生产管理第一步就卡在“从零搭还是买现成”上。买现成贵且改不动从零搭又容易在工单状态机、库存扣减、报工回写这几个地方反复翻车。我最近拆了一套生产管理系统源代码它把工单、物料、报工、库存、看板这几条主线都串起来了属于那种“拿来能跑、改起来有抓手”的底座型资源。适合两类人一是中小制造企业的信息化负责人想快速验证自己的业务流程二是接私活的开发者需要一个能交付的生产管理骨架。下面按“它是什么、怎么跑、坑在哪”的顺序拆给你看。2. 先看清架构这套生产管理系统源代码的模块划分与选型逻辑拿到一份源代码别急着npm install或mvn spring-boot:run。先花二十分钟把目录结构和依赖关系摸清楚比后面调试三天都值。这套代码的模块划分比较典型属于“前后端分离 单体后端 关系型数据库”的组合适合中小规模产线日工单量在几千级别完全扛得住。2.1 目录结构与技术栈拆解后端是标准的 MVC 分层controller负责接口、service放业务逻辑、mapper或repository管数据访问实体类单独一层。前端是管理后台常见的布局左侧菜单、顶部面包屑、主区域表格加弹窗表单。数据库用 MySQL表结构里能明显看到工单主表、工单工序表、物料表、库存流水表这几张核心表。技术栈上后端如果是 Java 系大概率是 Spring Boot MyBatis如果是 Node 系就是 Express 或 NestJS TypeORM。前端一般是 Vue 或 React 配 Element UI / Ant Design。这套组合的好处是招人容易、资料多、出问题搜得到答案。选型逻辑很朴素生产管理系统的核心诉求是“数据准确、流程可追溯”不需要高并发架构单体加关系型数据库反而是最稳的选择。提示先看pom.xml或package.json里的依赖版本确认 JDK / Node 版本要求版本不匹配是新手第一个翻车点。2.2 核心数据模型工单、物料、库存三张表的关联生产管理系统的命脉在数据模型。这套代码里工单表work_order是主表记录工单号、产品、计划数量、状态、计划开始和结束时间。工单工序表work_order_process挂在外键上一个工单拆成多道工序每道工序有负责工位、报工数量、良品数、不良数。物料表material存物料编码、名称、规格、单位。库存流水表inventory_flow记录每一次出入库的变动包括关联工单、变动数量、变动类型、操作时间。关联关系是工单引用产品产品通过 BOM 关联物料报工时按 BOM 扣减物料库存同时写一条库存流水。这个链路听起来简单但实际改代码时最容易在“报工扣料”这一步出错——扣多了库存对不上扣少了物料虚高。理解这三张表的关联后面改业务逻辑才有底。2.3 工单状态机从创建到完工的流转规则工单状态是这套系统的骨架。常见状态有待排产、已排产、生产中、已完工、已关闭。状态流转不是随便改字段而是有约束的只有“待排产”能排产只有“已排产”能开工报工数量累计达到计划数量才能转“已完工”。代码里一般用一个枚举类加状态校验方法来实现比如WorkOrderStatus.canTransitTo(target)。改这块代码时血泪经验是别直接改数据库里的状态字段来“修数据”一定要走业务方法否则库存流水和工单状态会对不上后面查账查到你怀疑人生。状态机的校验逻辑通常集中在 service 层的一个方法里找到它所有状态变更的入口就都清楚了。3. 把系统跑起来环境准备、数据库初始化与首次登录架构看清了接下来动手。这一章的目标是让你在本地把系统跑起来能登录、能看到工单列表、能走一遍报工流程。整个过程分环境准备、数据库初始化、后端启动、前端启动四步每步都有容易卡住的地方。3.1 环境准备与依赖安装先确认本机环境。Java 系需要 JDK 8 或 11看pom.xml里的java.versionMaven 3.6 以上Node 系需要 Node 16 或 18npm 或 yarn。数据库统一用 MySQL 5.7 或 8.0字符集设utf8mb4排序规则utf8mb4_general_ci。# 检查版本版本不对先别往下走 java -version mvn -v node -v npm -v mysql --version版本确认后后端进项目根目录执行依赖拉取前端进web或frontend目录执行安装。这一步的坑在于镜像源默认源拉包慢或超时换成国内镜像能省不少时间。Maven 改settings.xml的mirrornpm 用npm config set registry指向可用源。# 后端拉依赖Java 系示例 mvn clean install -DskipTests # 前端装依赖 cd web npm install-DskipTests是跳过测试编译首次跑通阶段没必要等测试。等系统稳定了再跑全量测试。前端安装如果卡在某个包上先删node_modules和package-lock.json重来比逐个排查快。3.2 数据库初始化建库、导表与初始数据数据库是这套系统的黑匣子初始化不对后面全是玄学问题。先建库再执行项目里的 SQL 脚本。脚本一般在sql或db目录下分建表脚本和初始数据脚本两个文件。-- 建库字符集必须 utf8mb4否则中文物料名会乱码 CREATE DATABASE mes_demo DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; -- 建一个专用账号别用 root 跑应用 CREATE USER mes_applocalhost IDENTIFIED BY ChangeMe_2024; GRANT ALL PRIVILEGES ON mes_demo.* TO mes_applocalhost; FLUSH PRIVILEGES;建库后依次导入建表脚本和初始数据脚本。初始数据里通常有默认管理员账号、基础物料、示例工单。导入完检查三件事表数量对不对、管理员账号在不在、示例工单的状态是不是“待排产”。这三项正常数据库这关就过了。# 导入建表和初始数据注意顺序不能反 mysql -u mes_app -p mes_demo sql/schema.sql mysql -u mes_app -p mes_demo sql/data.sql注意如果脚本里写死了USE xxx或库名导入前先确认库名一致否则会导到不存在的库里报错。3.3 配置文件修改与前后端启动数据库通了改后端配置文件。找到application.yml或application.properties把数据源地址、账号、密码改成刚才建的。连接池参数首次跑通阶段用默认值就行别一上来就调优。# application.yml 关键片段 spring: datasource: url: jdbc:mysql://localhost:3306/mes_demo?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: mes_app password: ChangeMe_2024 driver-class-name: com.mysql.cj.jdbc.DriverserverTimezone必须显式指定不写的话 MySQL 8 驱动会报时区错误这是高频翻车点。改完启动后端看到端口监听日志就算成功。前端改vite.config或vue.config里的代理地址指向后端端口然后npm run dev启动。浏览器打开前端地址用初始数据里的管理员账号登录能看到工单列表页整条链路就通了。# 后端启动Java 系 mvn spring-boot:run # 前端启动 cd web npm run dev登录后先别急着点报工先去物料页和工单页各看一眼数据是否完整。数据不完整就报工后面库存对不上排查成本翻倍。4. 改业务不翻车工单报工与库存扣减的代码改造点系统跑起来只是起点真正的工作量在改业务。生产管理系统改得最多的两处是报工逻辑和库存扣减这两块改错数据就废了。这一章讲清楚改哪里、怎么改、改完怎么验证。4.1 报工接口的入参校验与幂等处理报工接口是高频调用入口车间扫码枪一扫就发一次请求。网络抖动导致重复提交是常态所以幂等必须做。这套代码里报工接口一般在WorkOrderController的report方法入参包括工单号、工序号、报工数量、良品数、不良数、操作人。改造第一步是加入参校验报工数量必须大于零良品加不良必须等于报工数量工单状态必须是“生产中”。校验不通过直接返回明确错误码别让脏数据进库。// 报工入参校验放在 service 层入口 public void validateReport(ReportDTO dto) { if (dto.getQty() null || dto.getQty() 0) { throw new BizException(报工数量必须大于0); } if (dto.getGoodQty() dto.getBadQty() ! dto.getQty()) { throw new BizException(良品数加不良数必须等于报工数量); } WorkOrder wo workOrderMapper.selectByNo(dto.getOrderNo()); if (!WorkOrderStatus.IN_PRODUCTION.name().equals(wo.getStatus())) { throw new BizException(工单不在生产中状态不能报工); } }幂等的做法是给报工请求加唯一键工单号 工序号 报工批次号。批次号由前端生成重复提交时数据库唯一索引直接拦截捕获异常后返回“已处理”。这样即使前端重试也不会重复扣库存。4.2 库存扣减的事务边界与并发控制报工成功后要按 BOM 扣减物料库存这一步必须在同一个事务里否则报工成功、扣料失败库存就虚高了。事务边界划在 service 方法上报工写库和库存扣减写库要么全成要么全败。Transactional(rollbackFor Exception.class) public void report(ReportDTO dto) { validateReport(dto); // 1. 写报工记录 reportMapper.insert(buildReport(dto)); // 2. 更新工单工序累计报工数 processMapper.addReportQty(dto.getOrderNo(), dto.getProcessNo(), dto.getQty()); // 3. 按 BOM 扣减库存并写流水 ListBomItem boms bomMapper.selectByProduct(dto.getProductCode()); for (BomItem bom : boms) { int need bom.getQtyPerUnit() * dto.getGoodQty(); int affected inventoryMapper.deduct(bom.getMaterialCode(), need); if (affected 0) { throw new BizException(物料库存不足 bom.getMaterialCode()); } inventoryFlowMapper.insert(buildFlow(dto, bom, need)); } }并发控制靠deduct的 SQL 实现UPDATE inventory SET qty qty - #{need} WHERE material_code #{code} AND qty #{need}。用条件更新而不是先查后改避免并发下超扣。返回影响行数为零就抛异常回滚这是最省事也最可靠的写法。4.3 改完怎么验证三条对账 SQL改完报工和扣料别靠肉眼点页面验证。写三条对账 SQL跑一遍就知道数据对不对。-- 1. 工单累计报工数是否等于报工记录之和 SELECT wo.order_no, wo.reported_qty, (SELECT COALESCE(SUM(qty),0) FROM report_record r WHERE r.order_no wo.order_no) AS sum_qty FROM work_order wo WHERE wo.reported_qty (SELECT COALESCE(SUM(qty),0) FROM report_record r WHERE r.order_no wo.order_no); -- 2. 库存当前值是否等于初始值加流水净额 SELECT i.material_code, i.qty, (SELECT COALESCE(SUM(CASE WHEN f.flow_typeIN THEN f.qty ELSE -f.qty END),0) FROM inventory_flow f WHERE f.material_code i.material_code) AS flow_net FROM inventory i WHERE i.qty (SELECT COALESCE(SUM(CASE WHEN f.flow_typeIN THEN f.qty ELSE -f.qty END),0) FROM inventory_flow f WHERE f.material_code i.material_code); -- 3. 已完工工单是否还有未完成工序 SELECT wo.order_no FROM work_order wo JOIN work_order_process p ON p.order_no wo.order_no WHERE wo.status FINISHED AND p.reported_qty p.plan_qty;三条 SQL 都返回空结果说明数据一致。任何一条有结果就顺着那条链路查。这套对账习惯建议固化下来每次改完业务逻辑都跑一遍比事后救火强得多。5. 避坑清单部署和二次开发中最容易踩的五个坑这套代码我前后部署过几次也帮人改过业务下面五个坑是出现频率最高的。每条按“现象、原因、解决”写照着排查能省不少时间。5.1 中文乱码从建库到连接串的字符集链路现象是物料名、工单备注里的中文变成问号或乱码。原因通常是链路上某一环字符集不是utf8mb4建库时用了默认latin1或者连接串没带characterEncodingutf8或者表字段排序规则不一致。解决方法是逐环检查SHOW CREATE DATABASE看库字符集SHOW CREATE TABLE看表字符集连接串补上useUnicodetruecharacterEncodingutf8。三处统一成utf8mb4后重启应用乱码消失。5.2 报工后库存对不上事务没生效的典型表现现象是报工记录有了但库存没扣或者扣了但流水没写。原因多半是Transactional没生效方法被同类内部调用、异常被 catch 后没重新抛出、或者类没被 Spring 管理。解决方法是确认报工入口方法是从 controller 直接调用的 public 方法异常统一往上抛rollbackFor显式写Exception.class。改完用 4.3 的对账 SQL 验证。5.3 前端代理 404开发环境跨域配置错误现象是前端页面能打开但所有接口请求 404 或跨域报错。原因是前端代理没配或配错请求没转发到后端端口。解决方法是检查vite.config或vue.config里的proxy配置target指向后端实际端口changeOrigin设为truerewrite规则和接口前缀对齐。改完重启前端 dev server别只刷新页面。5.4 工单状态改不动状态机校验拦截现象是点“开工”或“完工”没反应或者提示状态不允许。原因是工单当前状态不满足流转条件比如工单还是“待排产”就直接点开工。解决方法是先看工单当前状态按状态机规则走待排产→排产→开工→报工→完工。别为了图快直接改数据库状态字段那样库存流水会对不上后面查账更麻烦。5.5 初始账号登不进密码加密方式不匹配现象是输入初始数据里的账号密码提示密码错误。原因是初始数据里的密码是明文或某种哈希而登录逻辑用的是另一种加密方式比如 BCrypt。解决方法是看登录 service 里的密码校验逻辑确认用的加密算法然后用同样的算法生成一个密码哈希更新到用户表里。别直接把校验逻辑改成明文比对那是给自己埋雷。6. 进阶用法用看板 SQL 和定时任务把系统用出价值系统跑通、业务改对之后真正的价值在数据利用上。这套代码自带一个简单的看板页但默认指标比较基础。我一般会补两条 SQL 和一个定时任务把产能和库存预警做出来这样系统才从“能用”变成“好用”。6.1 产能看板按工序统计日产量的聚合 SQL产能看板的核心是按工序、按天聚合报工数据算出计划完成率和良品率。下面这条 SQL 直接喂给看板接口前端按工序分组渲染即可。SELECT p.process_name, DATE(r.report_time) AS report_date, SUM(r.qty) AS total_qty, SUM(r.good_qty) AS good_qty, ROUND(SUM(r.good_qty) / SUM(r.qty) * 100, 2) AS good_rate, SUM(p.plan_qty) AS plan_qty, ROUND(SUM(r.qty) / SUM(p.plan_qty) * 100, 2) AS finish_rate FROM report_record r JOIN work_order_process p ON p.order_no r.order_no AND p.process_no r.process_no WHERE r.report_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY p.process_name, DATE(r.report_time) ORDER BY report_date DESC, p.process_name;good_rate是良品率finish_rate是计划完成率两个指标放一起看能快速定位哪道工序是瓶颈。时间窗口按需改INTERVAL 7 DAY看月度就改 30。6.2 库存预警定时任务扫描安全库存库存预警不用实时算定时任务每天扫一次就够。逻辑是查所有物料当前库存低于安全库存的写一条预警记录前端看板读预警表展示。// 每天早八点扫描安全库存低于阈值的写预警 Scheduled(cron 0 0 8 * * ?) public void scanLowStock() { ListMaterial materials materialMapper.selectAll(); for (Material m : materials) { Integer qty inventoryMapper.selectQtyByCode(m.getCode()); if (qty ! null qty m.getSafetyStock()) { alertMapper.insert(buildAlert(m, qty)); } } }cron表达式按实际班次调整两班倒的厂可以改成每 12 小时扫一次。预警记录建议加唯一约束物料 日期避免同一天重复写。6.3 一个习惯每次改业务前先跑对账 SQL 留基线最后说个习惯。我改这套系统养成了一个规矩动业务代码之前先把 4.3 那三条对账 SQL 跑一遍把结果存成基线文件改完再跑一遍对比差异。这样任何一次改动引入的数据问题都能在当天定位到具体是哪次提交造成的而不是等月底对账才发现。从那以后我每次改报工或库存相关逻辑都强制走一遍“留基线、改代码、跑对账”的流程翻车次数明显少了。希望帮到你。本文还有配套的精品资源点击获取
