拓冰网站定制 
简介基于Ruoyi框架的前后端分离MES源码带详细部署教程是一套面向制造业中小企业的制造执行系统解决方案覆盖系统管理、主数据、物料产品、生产排产、仓储库存、条码与设备管理等核心模块适合需要快速搭建生产信息化平台的开发人员或制造企业IT团队参考。压缩包共113个文件包含41个html前端页面、22个py脚本、22个jpg与12个png图片素材以及4个mp4演示视频和配套css/js/md文档整体63.84MB目录按模块划分便于查找。已有75人学习下载。详细部署教程能指导完成前后端环境搭建与配置前端页面直观后端逻辑完整并配有排班日历、统计报表和大屏展示等模块实现便于二次开发与业务扩展是一份兼具学习与工程落地参考价值的MES源码。1. 基于 Ruoyi 的前后端分离 MES 源码直接上手的车间制造执行系统制造执行系统MES在制造企业里属于「承上启下」的关键一层上面接 ERP 的生产计划下面接车间现场的设备、人员和物料。传统企业上 MES 往往要砸几十万买套商业软件而且业务流程固定死车间稍微有点特殊工序就得定制定制一次就是好几个月的实施周期。这套基于 Ruoyi 框架的前后端分离 MES 源码把车间管理最常见的几个板块——基础数据、生产工单、报工、质检、设备点检——都做成了可运行的功能模块代码给你数据库脚本给你连前端 Vue 页面也一并附上。你不需要从零搭建权限管理和用户体系因为 Ruoyi 已经帮你把部门、用户、角色、菜单这一整套后台管理框架搭好了。直接在这上面扩展自己车间的业务逻辑比买套封闭的商业系统更有可控性。适合准备二次开发实施项目的工程师、做毕业设计或课设的学生以及想快速验证 MES 功能流程的产品经理和车间信息化负责人。2. MES 核心模块拆解从工单下发到报工入库的完整链路MES 系统不管叫什么名字业务主链路基本都是同一套基础数据先建好然后生产计划下来生成工单工单发给产线产线按工序执行执行完了报工汇报工时同步走质检最后入库。理解了这条主链路看源码才不会一头雾水。2.1 基础资料模块物料、BOM 与工艺路线基础资料是 MES 的骨架。这套源码里物料档案的表结构设计得比较常规核心字段包括物料编码、物料名称、规格型号、计量单位、物料分类、默认仓库。这个表在源码中对应表前缀mes_material实际改造时建议把 ERP 的编码规则直接搬过来免得两套系统编码对不上。BOM物料清单是产品结构在系统里的表达方式。源码里的 BOM 表分为主表和明细表主表记录这个 BOM 属于哪个产品、版本号、状态草稿/发布/停用明细表则记录每一层子件的编码、用量、损耗率、工序号。头明细分离的好处是可以一个 BOM 头下发到多个工单改子件用量时只改明细不影响头表引用。注意损耗率这个字段实务中很多公司会漏掉它直接影响物料需求计算调试时要确认默认值是 0 还是会取到 ERP 同步过来的值。工艺路线决定了产品按什么顺序加工。源码里工艺路线的实现是一个主表和多个工序子表子表按工序号排序每个工序绑定一种资源人或设备并填写标准工时。这套设计在大多数机械加工、电子组装车间够用了遇到超复杂的柔性产线再扩展。2.2 生产工单从计划下达到执行闭环生产工单是 MES 的核心单据。源码里工单主表保存工单号、产品编码、计划数量、开始/结束时间、优先级、工单状态、创建人。状态机是重点常见状态包括创建、已下发、执行中、已完工、已关闭、已挂起、已取消。如果你在改业务最忌讳的是把状态当成一个字符串随便存后面报表统计会乱掉建议用状态字段加一个状态流转表记录每一次的「状态变更事件」这样排查问题的时候能看到这单是什么时候下发、什么时候报完的。派工与报工在主链路里是上下两道动作。派工是把工单的某道工序分配给指定班组或指定机台报工则是作业员完成这批活之后登记数量与工时。源码里的报工表字段建议关注这几个报工数量、合格数量、不良数量、报工时间、报工人、关联工序、关联设备。报工数量与合格数量的差值就是不良品直接流到质量管理模块去这个逻辑比较合理。硬件扫码接入、工序计件、按批次报工的场景需要在报工表上增加批次号字段和防重复字段否则扫码枪连续扫两次会生成两条重复记录这个属于常见的改造点。2.3 质量管理模块检验单、不良品与追溯质量管理在源码里做成了一套独立的检验流程来料检验、首件检验、巡检、完工检验。四类检验共用一套检验单主表和检验明细表区别只靠检验类型字段区分。检验明细表记录检验项目、标准值、实测值、判定结果合格/不合格一个检验单可能包含多个检验项目所以明细表和主表是主从关系。不良品登记是质量管理里比较关键的一个地方。报工后不合格数量会自动流转到不良品台账台账里可以维护不良原因比如来料不良、作业不良、设备不良、设计不良。很多实施项目统计直通率时发现数据对不上就是因为不良数据的来源没有闭环——报工时报了不良质检又没有关联到对应工单。建议在开发时保持不良记录带工单号和工序号两个外键后端逻辑层校验这两个字段必填。2.4 设备管理与点检计划设备管理模块相对简单就是设备台账、点检计划、保养计划。设备台账核心字段包括设备编号、设备名称、所在车间、设备状态状态可以分为运行、停机、维修、报废四种。设备状态最好用事实表来存即「当前状态」字段与「状态变更历史」记录并存从历史表里可以统计设备停机时长和 OEE 设备综合效率。点检计划的逻辑是在系统里给每个设备配置点检周期每班 / 每日 / 每周然后按周期生成一张点检任务点检人登录后在移动端或 PC 端执行确认。为了避免点检流于形式建议在业务代码里把关卡做进去设备状态为「维修」中不允许点检通过或者点检异常时必须录入异常描述才能提交。源码里默认是简单记录点检结果你跟现场实施的时候可以按车间要求补上这些硬性校验。3. 部署实操全流程从零到登录进首页源码带一份详细的部署文档不过实际动手时仍然会遇到一堆环境版本匹配的问题。我按常见的生产环境方案把步骤走一遍照着做基本半小时能跑起来。3.1 环境版本选型与准备清单这套系统是经典的前后端分离结构后端 Spring Boot MyBatis Redis前端 Vue Element UI用 Nginx 做静态托管。部署前先检查环境版本不匹配是最常见的翻车原因。环境组件推荐版本坑点说明JDK1.8 或 11高版本 JDK 大概率遇到反射或禁用 openJdk 选项的报错Maven3.63.8 以上存在中央仓库下载失败需要配置阿里云镜像MySQL5.7 或 8.08.0 的驱动名、SSL、时区问题都比 5.7 多建议先用 5.7 跑通Redis3.x/5.x/6.x服务端必须能连通注意bind与protected-mode配置Node.js14 或 16前端构建依赖 node-sass 时版本对不上会直接报错Nginx1.18配置反向代理与gzip打开否则前端页面慢3.2 后端启动全过程后端工程结构上是标准的 Ruoyi 多模块 Maven 项目核心模块是ruoyi-admin启动入口、ruoyi-framework、ruoyi-system、ruoyi-commonMES 业务相关代码一般在ruoyi-system或单独建一个mes模块里具体看这份源码的分类方式。创建数据库并导入脚本CREATE DATABASE IF NOT EXISTS mes DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE mes; SET NAMES utf8mb4; SOURCE /path/to/sql/ruoyi_mes.sql; SOURCE /path/to/sql/mes_business.sql;提示Sql 文件名以压缩包内文档为准通常包含若依框架本身的菜单权限脚本 MES 业务表的初始化脚本两个都得执行漏一个会导致登录后菜单空白。导入完成后修改application-druid.yml里的数据库连接信息spring: datasource: druid: master: url: jdbc:mysql://127.0.0.1:3306/mes?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 driverClassName: com.mysql.cj.jdbc.DriverserverTimezoneAsia/Shanghai必加不加的话 MySQL 5.7 容易报The server time zone value的错。Redis 配置在application.yml里默认连localhost:6379密码留空如果你本地 Redis 设了密码就在spring.redis.password处填上。改完后在项目根目录执行mvn clean package -Dmaven.test.skiptrue构建成功后找到ruoyi-admin/target/ruoyi-admin.jar启动java -jar ruoyi-admin.jar --server.port8080观察控制台输出出现Started RuoYiApplication且没有数据库连接异常时后端就完成了。此时可以用浏览器直接访问http://127.0.0.1:8080用管理员账号登录账号密码在初始化脚本里定义了。3.3 前端启动与 Nginx 配置前端工程是标准的 Vue 项目目录名称一般是ruoyi-ui或mes-ui。开发调试阶段直接用npm run dev生产环境就用npm run build:prod把静态资源产出到dist目录。前端默认在后端未启动时访问会出现跨域问题开发模式绕过去的方式是改vue.config.js里的代理配置devServer: { host: 0.0.0.0, port: 8088, proxy: { /prod-api: { target: http://127.0.0.1:8080, changeOrigin: true, pathRewrite: { ^/prod-api: } } } }/dev-api线上用 Nginx 托管时也要做同样的路径转发。Nginx 配置参考如下server { listen 80; server_name your-server-ip; location / { root /opt/mes/dist; index index.html; try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意proxy_pass http://127.0.0.1:8080/末尾的斜杠不能漏漏了路径就会变成/prod-api/xxx转发后端接收不到正确请求。刷新 Nginx 之后访问服务器 IP 就能看到登录页。登录进去后先检查菜单是否完整若左侧菜单空白多半是初始化脚本没执行干净回到第 3.2 步重新核对两个 SQL 文件。3.4 部署验证清单部署完不是点击登录就结束建议按下面清单过一遍确定 MES 的关键页面都能正常读写新增一条物料信息确认列表能查出来编码唯一性校验生效创建一个产品 BOM维护两行子件明细发布后到工单页面能引用到建一张生产工单下发走一遍报工操作确认库存台账数量增加新建一张检验单录入一行检验结果保存后状态变为已完成修改当前用户密码并重新登录确认 token 刷新正常这套流程跑完部署这一步就稳了。4. 二次开发实战基于 Ruoyi 脚手架扩展 MES 业务跑通只是第一步实际项目一定需要改功能。Ruoyi 框架最有价值的地方就是它的代码生成器和权限体系你可以用低代码方式快速生产新表的增删改查代码。4.1 Ruoyi 代码结构与生成器用法后端代码包结构大致是com.ruoyi.framework、com.ruoyi.system、com.ruoyi.web.controller业务代码参考已有 MES 模块的位置放置。启用代码生成器前先在数据库建一张新表比如「工序流转卡」表CREATE TABLE mes_process_card ( card_id BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 流转卡ID, card_no VARCHAR(50) NOT NULL COMMENT 流转卡编号, work_order_no VARCHAR(50) NOT NULL COMMENT 关联工单号, product_code VARCHAR(50) NOT NULL COMMENT 产品编码, process_seq INT NOT NULL COMMENT 工序序号, process_name VARCHAR(100) NOT NULL COMMENT 工序名称, operator VARCHAR(50) DEFAULT COMMENT 操作人, start_time DATETIME DEFAULT NULL COMMENT 开始时间, end_time DATETIME DEFAULT NULL COMMENT 结束时间, quantity DECIMAL(10,2) NOT NULL COMMENT 流转数量, status CHAR(1) NOT NULL COMMENT 状态0待执行 1执行中 2已完成, remark VARCHAR(500) DEFAULT COMMENT 备注, create_by VARCHAR(64) DEFAULT COMMENT 创建者, create_time DATETIME DEFAULT NULL COMMENT 创建时间, update_by VARCHAR(64) DEFAULT COMMENT 更新者, update_time DATETIME DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (card_id) ) ENGINEInnoDB AUTO_INCREMENT1 COMMENT工序流转卡;登录系统后在「系统工具 → 代码生成」里导入这张表配置生成配置——只选「生成类型」里的控制器、Service、Mapper、页面生成到本地源码对应目录。生成完毕编译启动项目菜单 SQL 也会一并生成在菜单管理里刷新后就能看到新的页面了。这个过程本身是 Ruoyi 的标准能力不是每家公司都有利用好多数用户只当后台管理用没有意识到它在 MES 这种业务型系统里价值巨大。4.2 后端改造加上状态流转校验自动生成的代码只是基本的增删改查业务逻辑需要自己补齐。以流转卡为例状态从「待执行」直接改到「已完成」是不合理的中间必须经过「执行中」。在 Service 层加校验逻辑Override public void updateStatus(MesProcessCard card) { MesProcessCard dbCard mesProcessCardMapper.selectById(card.getCardId()); if (dbCard null) { throw new ServiceException(流转卡不存在); } // 只允许按顺序流转0 - 1 - 2 String current dbCard.getStatus(); String target card.getStatus(); if (0.equals(current) 2.equals(target)) { throw new ServiceException(不允许跳过执行中状态直达完成); } if (2.equals(current)) { throw new ServiceException(流转卡已完成不能变更状态); } if (card.getStartTime() null 1.equals(target)) { card.setStartTime(new Date()); } mesProcessCardMapper.updateStatus(card); }这段代码守住了三个边界状态跳跃改不了、已完成的单改不了、进入执行中自动写开始时间。业务型系统在自动生成的 CRUD 之上要补的一定是状态机这一层不补全的话后台数据就会出现各种逻辑矛盾的记录。4.3 前端页面联动选择与动态校验前端页面在src/views/mes/processCard/index.vue中改造重点是让「产品编码」下拉框关联 BOM 信息选完产品自动带出工序列表handleProductChange(val) { this.form.processOptions this.bomList.filter(item item.productCode val); this.form.processName ; },之后再做一步动态校验当status为「已完成」时quantity不能为空且必须大于 0这个校验可以用若依表单自带的rules判断也可以在提交方法里加一次兜底submitForm() { if (this.form.status 2 this.form.quantity 0) { this.$modal.msgError(完工数量必须大于0); return; } this.$refs[form].validate((valid) { if (valid) { // 提交逻辑 } }); }页面改造完成后建议清一下浏览器缓存再进菜单刷新看效果。4.4 权限配置角色与数据范围新表生成后默认只授予管理员角色。若要分配给车间班组长、操作工、质检员等不同角色的用户进入「系统管理 → 角色管理」分别勾选菜单权限并设置数据权限为「仅本人数据」或「本部门数据」。MES 项目里数据权限尤其重要产线工人如果能看到全公司所有订单数据既有管理风险也不利于操作聚焦。源码里已经集成了 Ruoyi 的数据范围控制只要在查询方法上加DataScope注解即可按部门过滤具体在com.ruoyi.common.annotation.DataScope与DataScopeAspect中有实现。5. 部署与运行避坑五类高频问题排查记录跑过若依项目的人都有一个共识部署层面的大坑集中在环境匹配和路径配置。以下问题是我在复现过程中实际撞到的每条都是可以照方抓药的血泪经验。5.1 前端构建时 node-sass 安装失败现象npm install执行到一半报gyp ERR! stack Error: not found: python2或者node-sass一直拉不到二进制包进度卡死。原因node-sass 需要从 GitHub 下载对应 node 版本的二进制文件国内网络环境中下载经常被重置而且 node 版本与 node-sass 版本不匹配时构建直接失败。解决换用淘宝镜像源并指定sass_binary_sitenpm config set registry https://registry.npmmirror.com npm config set sass_binary_site https://npmmirror.com/mirrors/node-sass/ npm install若镜像已无法匹配当前 node 版本最省事的办法是装 Node 14 或 Node 16配合node-sass4.14.1或源码里自带的版本。实测用 Node 16 node-sass 对应版本没有再撞墙。5.2 MySQL 8 连接报 Public Key Retrieval 错误现象后端日志出现Public Key Retrieval is not allowed但换了 5.7 就正常。原因MySQL 8 默认使用caching_sha2_password认证插件Druid 连接池在非 SSL 模式下无法自动获取服务端公钥。解决JDBC URL 追加allowPublicKeyRetrievaltrue或者把连接用户改为mysql_native_password插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;生产环境一般两招都上保证不因密码插件差异中断连接。5.3 前端登录成功后请求接口全部 404现象登录页面能加载出来但输入账号密码点击登录后接口全部 404浏览器 F12 里看到请求地址还是/prod-api/login。原因Nginx 的 location/prod-api/路径转发配错了或者前端请求的 baseURL 与后端 context-path 不一致。解决第一确认vue.config.js或.env.production里VUE_APP_BASE_API的值为/prod-api第二确认 Nginx 中location /prod-api/的proxy_pass末尾带斜杠第三后端application.yml里的server.servlet.context-path保持为空。三条都对上再刷新浏览器。5.4 文件上传失败提示目录不存在现象上传产品图片或导入 Excel 时报文件保存失败后端日志显示java.io.FileNotFoundException或目录访问被拒绝。原因源码中默认的上传路径是/tmp/ruoyi/upload这个路径在部分 Linux 环境下不预存在且运行账号可能没有写权限。解决在application.yml中显式配置绝对路径ruoyi: profile: /data/ruoyi/upload创建目录并授权mkdir -p /data/ruoyi/upload chown -R appuser:appuser /data/ruoyi重启服务后再次上传验证。5.5 定时任务重复执行两次现象配置了「按日生成点检任务」的定时任务每天早上发现任务跑了两遍数据库里生成两条重复记录。原因Ruoyi 定时任务默认是单实例调度但如果部署了多副本节点且没有引入分布式锁每个节点都会触发一次本地单机复现时常见原因是启用了调试热加载导致任务注册了两遍。解决确认线上只有单节点调度开关开启本地排查时进入「系统监控 → 定时任务」停掉多余同名任务或给任务方法加上 Redis 分布式锁// 任务入口 public void generateTask() { String lockKey mes:dailyTask:lock; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(30)); if (!locked) { log.warn(任务已在其他节点执行); return; } doGenerateTask(); }加锁之后重复执行的问题彻底消失。这项工作在源码里没有集成但对于多实例部署是必备能力。6. 进阶验证缓存预热与并发报工的性能调优MES 上了产线之后最容易暴露的系统问题就是高频报工接口的并发写入以及基础资料查询把数据库拖慢。把性能这一层补上系统才能真正扛住现场压力。先看基础资料。物料、BOM、设备这些数据的特点是读多写少而且写操作集中在盘点或排程时段。我会把物料基础数据在系统启动时预加载到 Redis给业务查询接口留一份缓存。若依框架中RedisCache已经封装好了setCacheObject与getCacheObject方法直接注入使用即可PostConstruct public void initMaterialCache() { ListMesMaterial list mesMaterialService.selectAll(); redisCache.setCacheObject(mes:material:all, list, 24L, TimeUnit.HOURS); }查询方法改成先读缓存缓存没有再去查库并回填。注意这里缓存过期时间要根据库存更新的频率调整库存数量发生变动时自行删除对应的缓存 key避免查到旧库存引发车间领料纠纷。报工接口的并发问题比缓存更值得重点提前处理。成品报工一般出现在换班前后或月底冲刺同一产品编码的报工请求会瞬间涌进来数据库的库存扣减和合格率计算是核心瓶颈。后端接口需要加synchronized或数据库乐观锁。妙处在于课设项目里没多少人深入这一层但真实车间几百号工人同时点报工没有并发控制的话数据一定乱。给报工表增加版本号字段用乐观锁避免同一产品的库存被覆盖Update(UPDATE mes_stock SET quantity quantity #{count}, version version 1 WHERE product_code #{productCode} AND version #{oldVersion}) int updateStockWithVersion(Param(productCode) String productCode, Param(count) BigDecimal count, Param(oldVersion) Integer oldVersion);更新失败时返回 0业务层检测到后重试一次再失败就提示用户「当前操作冲突请稍后重试」。乐观锁对读多写少的库存表非常友好性能损失可以忽略却能防止最后一条报工把前面几条的数量覆盖掉。生产环境最快的验证手段是压测。开工前先选一台测试机用wrk -t4 -c50 -d30s http://your-server:8080/prod-api/mes/workOrder/report对报工接口打一轮请求观察日志里的平均响应时间和报错率。如果响应时间超过 800 毫秒优先查数据库慢查询日志SHOW VARIABLES LIKE slow_query_log; SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;慢查询日志里出现mes_work_order_report全表扫描时给work_order_no、report_time建立联合索引。这套动作做完再压测一轮响应时间通常能降到 300 毫秒以内。从那以后我经手每个 MES 项目的验收都强制走一遍同样的流程先压测再查慢日志然后才敢让系统上线。这套源码本身已经把若依框架最稳的底子给你了二次开发和部署的门槛都不算高但真正的价值在于架构里留出的扩展位——你每一次加的校验、缓存的预加载、锁的引入都是在把一套「能跑的代码」变成「敢在现场用的系统」。希望帮到你。本文还有配套的精品资源点击获取 基于Ruoyi的前后端分离MES源码：从部署到二次开发实战
简介基于Ruoyi框架的前后端分离MES源码带详细部署教程是一套面向制造业中小企业的制造执行系统解决方案覆盖系统管理、主数据、物料产品、生产排产、仓储库存、条码与设备管理等核心模块适合需要快速搭建生产信息化平台的开发人员或制造企业IT团队参考。压缩包共113个文件包含41个html前端页面、22个py脚本、22个jpg与12个png图片素材以及4个mp4演示视频和配套css/js/md文档整体63.84MB目录按模块划分便于查找。已有75人学习下载。详细部署教程能指导完成前后端环境搭建与配置前端页面直观后端逻辑完整并配有排班日历、统计报表和大屏展示等模块实现便于二次开发与业务扩展是一份兼具学习与工程落地参考价值的MES源码。1. 基于 Ruoyi 的前后端分离 MES 源码直接上手的车间制造执行系统制造执行系统MES在制造企业里属于「承上启下」的关键一层上面接 ERP 的生产计划下面接车间现场的设备、人员和物料。传统企业上 MES 往往要砸几十万买套商业软件而且业务流程固定死车间稍微有点特殊工序就得定制定制一次就是好几个月的实施周期。这套基于 Ruoyi 框架的前后端分离 MES 源码把车间管理最常见的几个板块——基础数据、生产工单、报工、质检、设备点检——都做成了可运行的功能模块代码给你数据库脚本给你连前端 Vue 页面也一并附上。你不需要从零搭建权限管理和用户体系因为 Ruoyi 已经帮你把部门、用户、角色、菜单这一整套后台管理框架搭好了。直接在这上面扩展自己车间的业务逻辑比买套封闭的商业系统更有可控性。适合准备二次开发实施项目的工程师、做毕业设计或课设的学生以及想快速验证 MES 功能流程的产品经理和车间信息化负责人。2. MES 核心模块拆解从工单下发到报工入库的完整链路MES 系统不管叫什么名字业务主链路基本都是同一套基础数据先建好然后生产计划下来生成工单工单发给产线产线按工序执行执行完了报工汇报工时同步走质检最后入库。理解了这条主链路看源码才不会一头雾水。2.1 基础资料模块物料、BOM 与工艺路线基础资料是 MES 的骨架。这套源码里物料档案的表结构设计得比较常规核心字段包括物料编码、物料名称、规格型号、计量单位、物料分类、默认仓库。这个表在源码中对应表前缀mes_material实际改造时建议把 ERP 的编码规则直接搬过来免得两套系统编码对不上。BOM物料清单是产品结构在系统里的表达方式。源码里的 BOM 表分为主表和明细表主表记录这个 BOM 属于哪个产品、版本号、状态草稿/发布/停用明细表则记录每一层子件的编码、用量、损耗率、工序号。头明细分离的好处是可以一个 BOM 头下发到多个工单改子件用量时只改明细不影响头表引用。注意损耗率这个字段实务中很多公司会漏掉它直接影响物料需求计算调试时要确认默认值是 0 还是会取到 ERP 同步过来的值。工艺路线决定了产品按什么顺序加工。源码里工艺路线的实现是一个主表和多个工序子表子表按工序号排序每个工序绑定一种资源人或设备并填写标准工时。这套设计在大多数机械加工、电子组装车间够用了遇到超复杂的柔性产线再扩展。2.2 生产工单从计划下达到执行闭环生产工单是 MES 的核心单据。源码里工单主表保存工单号、产品编码、计划数量、开始/结束时间、优先级、工单状态、创建人。状态机是重点常见状态包括创建、已下发、执行中、已完工、已关闭、已挂起、已取消。如果你在改业务最忌讳的是把状态当成一个字符串随便存后面报表统计会乱掉建议用状态字段加一个状态流转表记录每一次的「状态变更事件」这样排查问题的时候能看到这单是什么时候下发、什么时候报完的。派工与报工在主链路里是上下两道动作。派工是把工单的某道工序分配给指定班组或指定机台报工则是作业员完成这批活之后登记数量与工时。源码里的报工表字段建议关注这几个报工数量、合格数量、不良数量、报工时间、报工人、关联工序、关联设备。报工数量与合格数量的差值就是不良品直接流到质量管理模块去这个逻辑比较合理。硬件扫码接入、工序计件、按批次报工的场景需要在报工表上增加批次号字段和防重复字段否则扫码枪连续扫两次会生成两条重复记录这个属于常见的改造点。2.3 质量管理模块检验单、不良品与追溯质量管理在源码里做成了一套独立的检验流程来料检验、首件检验、巡检、完工检验。四类检验共用一套检验单主表和检验明细表区别只靠检验类型字段区分。检验明细表记录检验项目、标准值、实测值、判定结果合格/不合格一个检验单可能包含多个检验项目所以明细表和主表是主从关系。不良品登记是质量管理里比较关键的一个地方。报工后不合格数量会自动流转到不良品台账台账里可以维护不良原因比如来料不良、作业不良、设备不良、设计不良。很多实施项目统计直通率时发现数据对不上就是因为不良数据的来源没有闭环——报工时报了不良质检又没有关联到对应工单。建议在开发时保持不良记录带工单号和工序号两个外键后端逻辑层校验这两个字段必填。2.4 设备管理与点检计划设备管理模块相对简单就是设备台账、点检计划、保养计划。设备台账核心字段包括设备编号、设备名称、所在车间、设备状态状态可以分为运行、停机、维修、报废四种。设备状态最好用事实表来存即「当前状态」字段与「状态变更历史」记录并存从历史表里可以统计设备停机时长和 OEE 设备综合效率。点检计划的逻辑是在系统里给每个设备配置点检周期每班 / 每日 / 每周然后按周期生成一张点检任务点检人登录后在移动端或 PC 端执行确认。为了避免点检流于形式建议在业务代码里把关卡做进去设备状态为「维修」中不允许点检通过或者点检异常时必须录入异常描述才能提交。源码里默认是简单记录点检结果你跟现场实施的时候可以按车间要求补上这些硬性校验。3. 部署实操全流程从零到登录进首页源码带一份详细的部署文档不过实际动手时仍然会遇到一堆环境版本匹配的问题。我按常见的生产环境方案把步骤走一遍照着做基本半小时能跑起来。3.1 环境版本选型与准备清单这套系统是经典的前后端分离结构后端 Spring Boot MyBatis Redis前端 Vue Element UI用 Nginx 做静态托管。部署前先检查环境版本不匹配是最常见的翻车原因。环境组件推荐版本坑点说明JDK1.8 或 11高版本 JDK 大概率遇到反射或禁用 openJdk 选项的报错Maven3.63.8 以上存在中央仓库下载失败需要配置阿里云镜像MySQL5.7 或 8.08.0 的驱动名、SSL、时区问题都比 5.7 多建议先用 5.7 跑通Redis3.x/5.x/6.x服务端必须能连通注意bind与protected-mode配置Node.js14 或 16前端构建依赖 node-sass 时版本对不上会直接报错Nginx1.18配置反向代理与gzip打开否则前端页面慢3.2 后端启动全过程后端工程结构上是标准的 Ruoyi 多模块 Maven 项目核心模块是ruoyi-admin启动入口、ruoyi-framework、ruoyi-system、ruoyi-commonMES 业务相关代码一般在ruoyi-system或单独建一个mes模块里具体看这份源码的分类方式。创建数据库并导入脚本CREATE DATABASE IF NOT EXISTS mes DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE mes; SET NAMES utf8mb4; SOURCE /path/to/sql/ruoyi_mes.sql; SOURCE /path/to/sql/mes_business.sql;提示Sql 文件名以压缩包内文档为准通常包含若依框架本身的菜单权限脚本 MES 业务表的初始化脚本两个都得执行漏一个会导致登录后菜单空白。导入完成后修改application-druid.yml里的数据库连接信息spring: datasource: druid: master: url: jdbc:mysql://127.0.0.1:3306/mes?useUnicodetruecharacterEncodingutf8zeroDateTimeBehaviorconvertToNulluseSSLfalseserverTimezoneAsia/Shanghai username: root password: 你的密码 driverClassName: com.mysql.cj.jdbc.DriverserverTimezoneAsia/Shanghai必加不加的话 MySQL 5.7 容易报The server time zone value的错。Redis 配置在application.yml里默认连localhost:6379密码留空如果你本地 Redis 设了密码就在spring.redis.password处填上。改完后在项目根目录执行mvn clean package -Dmaven.test.skiptrue构建成功后找到ruoyi-admin/target/ruoyi-admin.jar启动java -jar ruoyi-admin.jar --server.port8080观察控制台输出出现Started RuoYiApplication且没有数据库连接异常时后端就完成了。此时可以用浏览器直接访问http://127.0.0.1:8080用管理员账号登录账号密码在初始化脚本里定义了。3.3 前端启动与 Nginx 配置前端工程是标准的 Vue 项目目录名称一般是ruoyi-ui或mes-ui。开发调试阶段直接用npm run dev生产环境就用npm run build:prod把静态资源产出到dist目录。前端默认在后端未启动时访问会出现跨域问题开发模式绕过去的方式是改vue.config.js里的代理配置devServer: { host: 0.0.0.0, port: 8088, proxy: { /prod-api: { target: http://127.0.0.1:8080, changeOrigin: true, pathRewrite: { ^/prod-api: } } } }/dev-api线上用 Nginx 托管时也要做同样的路径转发。Nginx 配置参考如下server { listen 80; server_name your-server-ip; location / { root /opt/mes/dist; index index.html; try_files $uri $uri/ /index.html; } location /prod-api/ { proxy_pass http://127.0.0.1:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }注意proxy_pass http://127.0.0.1:8080/末尾的斜杠不能漏漏了路径就会变成/prod-api/xxx转发后端接收不到正确请求。刷新 Nginx 之后访问服务器 IP 就能看到登录页。登录进去后先检查菜单是否完整若左侧菜单空白多半是初始化脚本没执行干净回到第 3.2 步重新核对两个 SQL 文件。3.4 部署验证清单部署完不是点击登录就结束建议按下面清单过一遍确定 MES 的关键页面都能正常读写新增一条物料信息确认列表能查出来编码唯一性校验生效创建一个产品 BOM维护两行子件明细发布后到工单页面能引用到建一张生产工单下发走一遍报工操作确认库存台账数量增加新建一张检验单录入一行检验结果保存后状态变为已完成修改当前用户密码并重新登录确认 token 刷新正常这套流程跑完部署这一步就稳了。4. 二次开发实战基于 Ruoyi 脚手架扩展 MES 业务跑通只是第一步实际项目一定需要改功能。Ruoyi 框架最有价值的地方就是它的代码生成器和权限体系你可以用低代码方式快速生产新表的增删改查代码。4.1 Ruoyi 代码结构与生成器用法后端代码包结构大致是com.ruoyi.framework、com.ruoyi.system、com.ruoyi.web.controller业务代码参考已有 MES 模块的位置放置。启用代码生成器前先在数据库建一张新表比如「工序流转卡」表CREATE TABLE mes_process_card ( card_id BIGINT(20) NOT NULL AUTO_INCREMENT COMMENT 流转卡ID, card_no VARCHAR(50) NOT NULL COMMENT 流转卡编号, work_order_no VARCHAR(50) NOT NULL COMMENT 关联工单号, product_code VARCHAR(50) NOT NULL COMMENT 产品编码, process_seq INT NOT NULL COMMENT 工序序号, process_name VARCHAR(100) NOT NULL COMMENT 工序名称, operator VARCHAR(50) DEFAULT COMMENT 操作人, start_time DATETIME DEFAULT NULL COMMENT 开始时间, end_time DATETIME DEFAULT NULL COMMENT 结束时间, quantity DECIMAL(10,2) NOT NULL COMMENT 流转数量, status CHAR(1) NOT NULL COMMENT 状态0待执行 1执行中 2已完成, remark VARCHAR(500) DEFAULT COMMENT 备注, create_by VARCHAR(64) DEFAULT COMMENT 创建者, create_time DATETIME DEFAULT NULL COMMENT 创建时间, update_by VARCHAR(64) DEFAULT COMMENT 更新者, update_time DATETIME DEFAULT NULL COMMENT 更新时间, PRIMARY KEY (card_id) ) ENGINEInnoDB AUTO_INCREMENT1 COMMENT工序流转卡;登录系统后在「系统工具 → 代码生成」里导入这张表配置生成配置——只选「生成类型」里的控制器、Service、Mapper、页面生成到本地源码对应目录。生成完毕编译启动项目菜单 SQL 也会一并生成在菜单管理里刷新后就能看到新的页面了。这个过程本身是 Ruoyi 的标准能力不是每家公司都有利用好多数用户只当后台管理用没有意识到它在 MES 这种业务型系统里价值巨大。4.2 后端改造加上状态流转校验自动生成的代码只是基本的增删改查业务逻辑需要自己补齐。以流转卡为例状态从「待执行」直接改到「已完成」是不合理的中间必须经过「执行中」。在 Service 层加校验逻辑Override public void updateStatus(MesProcessCard card) { MesProcessCard dbCard mesProcessCardMapper.selectById(card.getCardId()); if (dbCard null) { throw new ServiceException(流转卡不存在); } // 只允许按顺序流转0 - 1 - 2 String current dbCard.getStatus(); String target card.getStatus(); if (0.equals(current) 2.equals(target)) { throw new ServiceException(不允许跳过执行中状态直达完成); } if (2.equals(current)) { throw new ServiceException(流转卡已完成不能变更状态); } if (card.getStartTime() null 1.equals(target)) { card.setStartTime(new Date()); } mesProcessCardMapper.updateStatus(card); }这段代码守住了三个边界状态跳跃改不了、已完成的单改不了、进入执行中自动写开始时间。业务型系统在自动生成的 CRUD 之上要补的一定是状态机这一层不补全的话后台数据就会出现各种逻辑矛盾的记录。4.3 前端页面联动选择与动态校验前端页面在src/views/mes/processCard/index.vue中改造重点是让「产品编码」下拉框关联 BOM 信息选完产品自动带出工序列表handleProductChange(val) { this.form.processOptions this.bomList.filter(item item.productCode val); this.form.processName ; },之后再做一步动态校验当status为「已完成」时quantity不能为空且必须大于 0这个校验可以用若依表单自带的rules判断也可以在提交方法里加一次兜底submitForm() { if (this.form.status 2 this.form.quantity 0) { this.$modal.msgError(完工数量必须大于0); return; } this.$refs[form].validate((valid) { if (valid) { // 提交逻辑 } }); }页面改造完成后建议清一下浏览器缓存再进菜单刷新看效果。4.4 权限配置角色与数据范围新表生成后默认只授予管理员角色。若要分配给车间班组长、操作工、质检员等不同角色的用户进入「系统管理 → 角色管理」分别勾选菜单权限并设置数据权限为「仅本人数据」或「本部门数据」。MES 项目里数据权限尤其重要产线工人如果能看到全公司所有订单数据既有管理风险也不利于操作聚焦。源码里已经集成了 Ruoyi 的数据范围控制只要在查询方法上加DataScope注解即可按部门过滤具体在com.ruoyi.common.annotation.DataScope与DataScopeAspect中有实现。5. 部署与运行避坑五类高频问题排查记录跑过若依项目的人都有一个共识部署层面的大坑集中在环境匹配和路径配置。以下问题是我在复现过程中实际撞到的每条都是可以照方抓药的血泪经验。5.1 前端构建时 node-sass 安装失败现象npm install执行到一半报gyp ERR! stack Error: not found: python2或者node-sass一直拉不到二进制包进度卡死。原因node-sass 需要从 GitHub 下载对应 node 版本的二进制文件国内网络环境中下载经常被重置而且 node 版本与 node-sass 版本不匹配时构建直接失败。解决换用淘宝镜像源并指定sass_binary_sitenpm config set registry https://registry.npmmirror.com npm config set sass_binary_site https://npmmirror.com/mirrors/node-sass/ npm install若镜像已无法匹配当前 node 版本最省事的办法是装 Node 14 或 Node 16配合node-sass4.14.1或源码里自带的版本。实测用 Node 16 node-sass 对应版本没有再撞墙。5.2 MySQL 8 连接报 Public Key Retrieval 错误现象后端日志出现Public Key Retrieval is not allowed但换了 5.7 就正常。原因MySQL 8 默认使用caching_sha2_password认证插件Druid 连接池在非 SSL 模式下无法自动获取服务端公钥。解决JDBC URL 追加allowPublicKeyRetrievaltrue或者把连接用户改为mysql_native_password插件ALTER USER rootlocalhost IDENTIFIED WITH mysql_native_password BY 你的密码;生产环境一般两招都上保证不因密码插件差异中断连接。5.3 前端登录成功后请求接口全部 404现象登录页面能加载出来但输入账号密码点击登录后接口全部 404浏览器 F12 里看到请求地址还是/prod-api/login。原因Nginx 的 location/prod-api/路径转发配错了或者前端请求的 baseURL 与后端 context-path 不一致。解决第一确认vue.config.js或.env.production里VUE_APP_BASE_API的值为/prod-api第二确认 Nginx 中location /prod-api/的proxy_pass末尾带斜杠第三后端application.yml里的server.servlet.context-path保持为空。三条都对上再刷新浏览器。5.4 文件上传失败提示目录不存在现象上传产品图片或导入 Excel 时报文件保存失败后端日志显示java.io.FileNotFoundException或目录访问被拒绝。原因源码中默认的上传路径是/tmp/ruoyi/upload这个路径在部分 Linux 环境下不预存在且运行账号可能没有写权限。解决在application.yml中显式配置绝对路径ruoyi: profile: /data/ruoyi/upload创建目录并授权mkdir -p /data/ruoyi/upload chown -R appuser:appuser /data/ruoyi重启服务后再次上传验证。5.5 定时任务重复执行两次现象配置了「按日生成点检任务」的定时任务每天早上发现任务跑了两遍数据库里生成两条重复记录。原因Ruoyi 定时任务默认是单实例调度但如果部署了多副本节点且没有引入分布式锁每个节点都会触发一次本地单机复现时常见原因是启用了调试热加载导致任务注册了两遍。解决确认线上只有单节点调度开关开启本地排查时进入「系统监控 → 定时任务」停掉多余同名任务或给任务方法加上 Redis 分布式锁// 任务入口 public void generateTask() { String lockKey mes:dailyTask:lock; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofSeconds(30)); if (!locked) { log.warn(任务已在其他节点执行); return; } doGenerateTask(); }加锁之后重复执行的问题彻底消失。这项工作在源码里没有集成但对于多实例部署是必备能力。6. 进阶验证缓存预热与并发报工的性能调优MES 上了产线之后最容易暴露的系统问题就是高频报工接口的并发写入以及基础资料查询把数据库拖慢。把性能这一层补上系统才能真正扛住现场压力。先看基础资料。物料、BOM、设备这些数据的特点是读多写少而且写操作集中在盘点或排程时段。我会把物料基础数据在系统启动时预加载到 Redis给业务查询接口留一份缓存。若依框架中RedisCache已经封装好了setCacheObject与getCacheObject方法直接注入使用即可PostConstruct public void initMaterialCache() { ListMesMaterial list mesMaterialService.selectAll(); redisCache.setCacheObject(mes:material:all, list, 24L, TimeUnit.HOURS); }查询方法改成先读缓存缓存没有再去查库并回填。注意这里缓存过期时间要根据库存更新的频率调整库存数量发生变动时自行删除对应的缓存 key避免查到旧库存引发车间领料纠纷。报工接口的并发问题比缓存更值得重点提前处理。成品报工一般出现在换班前后或月底冲刺同一产品编码的报工请求会瞬间涌进来数据库的库存扣减和合格率计算是核心瓶颈。后端接口需要加synchronized或数据库乐观锁。妙处在于课设项目里没多少人深入这一层但真实车间几百号工人同时点报工没有并发控制的话数据一定乱。给报工表增加版本号字段用乐观锁避免同一产品的库存被覆盖Update(UPDATE mes_stock SET quantity quantity #{count}, version version 1 WHERE product_code #{productCode} AND version #{oldVersion}) int updateStockWithVersion(Param(productCode) String productCode, Param(count) BigDecimal count, Param(oldVersion) Integer oldVersion);更新失败时返回 0业务层检测到后重试一次再失败就提示用户「当前操作冲突请稍后重试」。乐观锁对读多写少的库存表非常友好性能损失可以忽略却能防止最后一条报工把前面几条的数量覆盖掉。生产环境最快的验证手段是压测。开工前先选一台测试机用wrk -t4 -c50 -d30s http://your-server:8080/prod-api/mes/workOrder/report对报工接口打一轮请求观察日志里的平均响应时间和报错率。如果响应时间超过 800 毫秒优先查数据库慢查询日志SHOW VARIABLES LIKE slow_query_log; SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;慢查询日志里出现mes_work_order_report全表扫描时给work_order_no、report_time建立联合索引。这套动作做完再压测一轮响应时间通常能降到 300 毫秒以内。从那以后我经手每个 MES 项目的验收都强制走一遍同样的流程先压测再查慢日志然后才敢让系统上线。这套源码本身已经把若依框架最稳的底子给你了二次开发和部署的门槛都不算高但真正的价值在于架构里留出的扩展位——你每一次加的校验、缓存的预加载、锁的引入都是在把一套「能跑的代码」变成「敢在现场用的系统」。希望帮到你。本文还有配套的精品资源点击获取