企业官网建设流程全解析

简介：本资源是一套基于Ruoyi框架开发的前后端分离式制造执行系统（MES）源码，面向制造业信息化开发者、工业软件实施工程师及高校智能制造方向学习者，旨在解决中小制造企业生产计划排程、物料追踪、设备与仓储协同等核心管理痛点。压缩包共113个文件，含41个HTML页面（构成完整前端界面）、22个Python脚本（支撑数据导入/工具类功能）、22张JPG/PNG图示（含系统架构图、模块流程图与界面截图）、12段MP4演示视频（覆盖部署、登录、排产、大屏等关键操作），以及CSS/JS/MD等配套文件，整体大小63.84MB。资源附带详尽部署教程与结构化目录，前端界面已预置dashboard、排班日历、库存看板、设备监控等核心页面，后端基于Spring Boot实现模块化业务逻辑，开箱即用性强。目前已有59人学习下载，适合快速搭建本地MES原型、理解制造业典型业务闭环或开展二次开发实践。 最近在折腾一套基于若依框架的MES系统源码，前后端分离的那种，里面带了数据库脚本、业务模块和一份部署文档。抽了个周末从零开始搭，中间踩了不少坑，今天把整个部署链路和二次开发思路捋一遍，给打算拿若依做车间管理系统的朋友做个参考。

这套项目解决的是中小型制造企业的生产执行问题：从基础资料维护、生产工单下达、工序报工，到质量检验、不良品登记、生产追溯，再到看板统计，一条线串起来。适合三类人看：一是MES项目的新人，想找一套能跑通的代码快速理解业务闭环；二是公司内部要做轻量化MES，不想从零写权限和菜单的；三是已经在用若依，想在这个基础上扩展生产制造模块的。

1. 这套MES源码该怎么看，整体设计是什么思路

1.1 为什么选RuoYi-Vue做MES底座，而不是重新造轮子

先聊一个很实际的问题。制造执行系统（MES）真正的业务复杂度在生产计划、工单流转、工序回报、质量追溯这些领域，但每个MES项目都绕不开一堆通用的后台能力：用户管理、角色权限、菜单路由、操作日志、数据字典、定时任务、代码生成器。这些要是每个项目都从头写一遍，三个月能出一个能用的原型都算快的。

若依这套脚手架（我用的RuoYi-Vue版本，Vue2 + Element UI，后端Spring Boot + MyBatis + Spring Security + JWT）恰好把这些通用能力都做好了。菜单和权限是动态的，数据库表结构都给你建好，代码生成器更是省事——建一张业务表，导入表结构，生成代码，配置菜单SQL，一个CRUD模块十分钟就能跑起来。做MES业务开发的时候，能把绝大部分精力放在工单流程、报工校验、质量归因这些真正需要思考的地方。

有人会问，为什么不用微服务架构？我的看法是，对于单工厂场景，几十个并发用户、几百台设备上报数据，单体应用完全扛得住，而且部署、排查、备份都简单得多。微服务那一套注册中心、配置中心、网关，对中小车间来说纯属给自己找麻烦。真要到了多工厂、多租户、数据量暴增的阶段，再考虑按模块拆分也不迟。

1.2 从车间视角梳理MES的功能矩阵

拿到源码别急着跑，先把功能模块摸清楚。这套MES从车间使用角度看，大致分这几块：

这个功能覆盖范围，对应的是轻量化MES的定位，和西门子、SAP那种重型的制造执行方案是两码事。重型方案强调复杂的排产算法（APS）、设备联网（IoT/SCADA）、工艺参数实时采集，这套源码更多是解决“人工记录纸质单据、生产进度靠问、质量问题找不到责任人”这类的痛点上线替代方案。

1.3 源码目录结构速览

拿到源码先在项目根目录逛一圈。后端是标准的若依多模块Maven工程：

• ruoyi-admin：启动入口，Controller层也主要在这
• ruoyi-framework：安全认证、拦截器、AOP切面、配置类
• ruoyi-system：系统管理相关的Service和Mapper
• ruoyi-common：通用工具类、常量、核心返回体封装
• ruoyi-quartz：定时任务模块

MES业务代码建议单独建模块（比如叫ruoyi-mes），和若依的系统代码隔离。好处是后续若依版本升级的时候，业务模块不会跟系统模块冲突，也方便团队按模块分工。

前端是Vue工程，src目录下重点关注：

• src/api：接口请求定义，按模块拆分，比如system.js、mes.js
• src/views：页面组件，按模块建目录
• src/router/index.js：前端路由定义，但注意若依是动态路由，菜单是从后端接口拉取的
• src/store：Pinia或Vuex的状态管理，存用户信息、权限标识
• src/utils/request.js：axios封装，统一处理token和响应拦截

第一次看这源码，我的建议是：先启动项目登录进去，把菜单都点一遍，然后对着数据库表结构看——一个菜单对应一张表或一组SQL，看到第三遍基本就通了。

2. 核心业务模块与关键代码逻辑

2.1 基础数据模块：物料、BOM、工艺路线怎么建模

MES的基础数据和ERP类似，但粒度更细。物料主数据是关键中的关键，主要字段包括物料编码、物料名称、规格型号、单位、物料类型（原料/半成品/成品）、默认仓库、状态。物料编码规则一定要在项目启动前定好，很多工厂上线失败就是因为物料编码混乱，同名不同码、一物多码的情况到处都是。

BOM（物料清单）是MES里最需要花心思建模的地方。思路是分成BOM头和BOM明细两张表，BOM头定义成品编码、版本号、状态；BOM明细定义这个成品由哪些物料组成，用量多少，损耗率多少。这里有个常见的坑：BOM的层级。单层BOM只维护直接子件，结构清晰，工厂维护起来简单；多层BOM需要递归展开，才能算出一件成品的完整用料。轻量化MES建议只做单层BOM，多层递归交给上层的MRP或ERP去算，否则数据库递归查询的性能和维护成本都很高。

工艺路线建模类似，route头表定义产品走哪条路线，route_process明细表定义这条路线包含哪些工序、每道工序在哪个工位执行、标准工时是多少。报工的时候就是按照这个工艺路线的顺序来，一道一道往下走。

这里分享一个教训：主数据整理是整个MES上线过程中工作量最大、最容易被低估的部分。系统功能开发完成可能只需要两个月，但把物料编码、BOM数据、工艺路线整理准确，没有专门的人盯着，半年都未必能搞定。MES能不能上线成功，七成取决于主数据，三成才是软件功能。

2.2 生产工单与报工流程的状态流转

工单是MES的核心单据，完整状态机应该是这样的：创建（待下达）→ 审核通过（已下达）→ 开工（已开工）→ 分批报工 → 全部工序完成（已完工）→ 关闭归档。工单下达的时候需要做几个关键校验：BOM是否存在且启用，工艺路线是否已经配置，库存齐套情况是否满足（按BOM展开算需求量和现有量的差额）。

报工是整个系统数据来源的入口，价值最大也最容易做砸。报工表的核心字段包括：工单ID、工序ID、报工人、报工时间、合格数量、不良数量、操作设备ID、班次、不良原因ID。报工的触发方式可以很灵活：

• PC端手工填报：操作工在车间电脑上登录系统，选择工单工序，填数量
• PDA/平板扫码：扫工单条码，自动带出工序信息，填数量提交
• 设备对接自动上报：通过OPC UA/Modbus等协议从设备侧自动采集数量，这条路最漂亮但实施成本也最高

报工必须有业务校验逻辑，简单说就是“报工数量不能大于工单剩余可报数量”。比如工单计划数是1000，前面已经报了700，这道工序最多只能报300，超了就报错。如果不做这个校验，现场数据就会失控，工单完工数量比计划数还大，后面统计全是错的。

2.3 质量追溯和看板数据是怎么算出来的

质量追溯是MES相对ERP最大的价值点。要实现“一物一码，一码到底”，核心思路就是把批次号贯穿整个生产链路。工单下达时生成一个工单批次号，建议规则是“日期+产线+流水号”，比如MO20250601001，这个号码一直到成品入库、出货都跟着走。

追溯的查询逻辑就是一个顺着关联关系逐级展开的过程：输入成品批次号 → 找到对应的工单 → 工单关联所有工序的报工记录 → 每条报工记录关联操作工、设备、班组 → 再通过工单关联原料批次号 → 原料批次号关联原料入库的质检单。用SQL描述就是几个JOIN的事，但要注意这里有个性能陷阱：大批量数据下多层关联查询会非常慢。生产环境通常会按日建汇总表，定时任务把当天的关键追溯链预计算好，查询直接查汇总表。

看板数据也一样。车间大屏要显示今日计划数、完工数、不良率、设备状态，如果每次都实时去count工单表、报工表、设备表，几千条数据还能扛，到几万条就明显卡顿。我的做法是写一个统计服务，每五分钟把汇总结果写入一张mes_dashboard_summary表，大屏从这张表取数。统计延迟五分钟对车间管理来说完全可接受。

3. 本地部署完整实操（开发环境）

3.1 安装清单与版本选择

先给一套我自己实测跑通的版本组合，照着准备就行：

这里特别说一下版本问题。RuoYi-Vue的原生架构是Spring Boot 2.x + JDK1.8，如果你用JDK17启动老版本，大概率会遇到JAXB缺失、CGLIB代理异常这些乱七八糟的问题。我见过太多人卡在环境上，其实不是代码有问题，就是版本不匹配。如果你一定要用新版本，建议直接找基于Spring Boot 3.x的RuoYi-Vue3。技术栈新不代表适合你，能跑通才是硬道理。

3.2 数据库初始化与配置文件修改

先用Navicat或命令行创建数据库，字符集选utf8mb4：

CREATE DATABASE `ry-mes` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

然后按顺序导入SQL脚本，顺序错了会报外键错误。通常第一批是若依的系统库脚本（ry_2024xxxx.sql），第二批是Quartz定时任务的表（ry_2024xxxx_quartz.sql），第三批才是MES业务模块的脚本（mes_xxx.sql）。导入完可以看一眼表数量，系统表加上业务表大概40张上下，如果明显偏少肯定有脚本没执行。

接下来改后端配置，重点改两个文件。第一个是application-druid.yml里的数据源：

spring: datasource: type: com.alibaba.druid.pool.DruidDataSource druid: url: jdbc:mysql://localhost:3306/ry-mes?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码

如果MySQL是8.0，driverClassName要改成com.mysql.cj.jdbc.Driver，url里一定要带serverTimezone，否则会报时区异常。

第二个是application.yml里的Redis配置：

redis: host: localhost port: 6379 password: database: 0

开发环境Redis如果没设密码，password就留空，别画蛇添足写一个错密码进去。

3.3 后端启动细节

后端启动入口在ruoyi-admin模块下的RuoYiApplication.java。直接右键运行main方法，或者用Maven命令：

mvn clean install -DskipTests cd ruoyi-admin mvn spring-boot:run

首次启动会下载大量依赖，建议配阿里云Maven镜像，不然下载速度会让人崩溃。启动成功的标志是控制台出现“启动成功”或者Spring Boot的Banner，默认端口8080。

启动完成后验证两个东西。一是访问Swagger接口文档：http://localhost:8080/swagger-ui/index.html ，能看到接口列表说明服务起来了；二是调登录接口验证数据库和Redis都正常：

curl -X POST http://localhost:8080/login \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"admin123"}'

能返回token说明数据库连接、Redis缓存、认证链路都是通的。注意RuoYi的Swagger需要开启配置才显示，有些版本要改application.yml里的swagger.enabled为true。

3.4 前端启动细节

前端进入前端目录，先安装依赖：

npm install

如果node-sass安装时报错，大概率是Node版本没对上。RuoYi-Vue的Vue2版本比较挑Node，建议直接用Node 16。装不上的话，可以把package.json里的node-sass替换成sass，然后重新install。安装完成后启动开发服务器：

npm run dev

默认端口是80，浏览器打开 http://localhost ，用admin/admin123登录。如果登录报502，多半是前端代理没指向后端。看vue.config.js里的devServer代理配置：

proxy: { '/dev-api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/dev-api': '' } } }

后端端口改了记得同步改这里，改完要重启前端开发服务器。

4. 生产环境部署教程（Linux服务器）

4.1 前端打包与Nginx配置

开发跑通之后就要上生产了。前端打包命令：

npm run build:prod

打包产物在dist目录，把这个目录整个丢到服务器的/opt/mes/dist就行。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; } # 上传文件访问路径 location /profile/ { alias /opt/mes/upload/; } }

这里解释几个关键点。try_files那行是Vue路由history模式必须的，否则刷新页面就404。location /prod-api/里的proxy_pass最后有个斜杠，意思是把/prod-api前缀去掉再转发到后端，比如请求 /prod-api/login 会转发到 http://127.0.0.1:8080/login。改完配置记得 nginx -t 检查语法再 reload。

4.2 后端打包与systemd服务管理

后端打包还是在ruoyi-admin模块下：

cd ruoyi-admin mvn clean package -DskipTests

生成的目标文件是ruoyi-admin.jar，大概几十MB。丢到服务器的/opt/mes目录下，然后用systemd管理进程，比nohup文明得多。在/etc/systemd/system/mes.service创建文件：

[Unit] Description=RuoYi MES Service After=network.target [Service] User=root WorkingDirectory=/opt/mes ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/mes/ruoyi-admin.jar SuccessExitStatus=143 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

然后执行：

systemctl daemon-reload systemctl enable mes systemctl start mes

看运行日志用 journalctl -u mes -f，能实时看输出，排查问题很方便。JVM参数里-Xms和-Xmx建议设成一样，避免运行中堆内存动态扩容引发性能抖动。服务器4G内存的话，给Java分配1.5G左右比较合理，剩下留给操作系统和MySQL。

4.3 生产环境性能与安全建议

本地能跑和生产能稳定跑是两回事，上生产前至少要把这几件事做了：

• MySQL开binlog，配好每日全量备份脚本。MES的数据是生产数据，丢一小时都够你喝一壶
• Redis设置密码，端口别用默认的6379，或者至少别让Redis直连公网，不然就是给黑客送分
• 日志按天切割并保留30天，避免日志文件撑爆磁盘。若依的logback配置默认是有的，检查一下路径和保留策略
• 文件上传路径改成独立目录（比如/opt/mes/upload），别放在/tmp下面，定期备份
• Nginx开启gzip，前端资源体积能减小一半多，加载速度快很多
• 阿里云/腾讯云的服务器记得在安全组里放通80端口，否则外部访问不了

5. 二次开发实战：用代码生成器实现报废原因维护

5.1 建表与导入代码生成器

讲一个实际的二次开发例子，把这个流程跑一遍基本就掌握若依的开发套路了。需求是增加一个“报废原因维护”功能，方便报工时选择不良原因。

第一步建表：

CREATE TABLE mes_scrap_reason ( id BIGINT AUTO_INCREMENT PRIMARY KEY COMMENT '主键', reason_code VARCHAR(50) NOT NULL COMMENT '报废原因编码', reason_name VARCHAR(100) NOT NULL COMMENT '报废原因名称', reason_type CHAR(1) DEFAULT '0' COMMENT '类型（0来料/1制程/2完工）', status CHAR(1) DEFAULT '0' COMMENT '状态（0正常 1停用）', remark VARCHAR(255) COMMENT '备注', create_by VARCHAR(64) COMMENT '创建者', create_time DATETIME COMMENT '创建时间', update_by VARCHAR(64) COMMENT '更新者', update_time DATETIME COMMENT '更新时间', PRIMARY KEY (id) ) ENGINE=InnoDB COMMENT='报废原因表';

注意表名和字段注释要规范，因为若依代码生成器会把这些注释自动生成到前端表单的label上，注释写得好，连前端页面文案都省了。在建表时加上create_by、create_time这些字段，代码生成器会自动生成创建时间、更新时间的处理逻辑。

第二步进入系统工具→代码生成，点“导入”，选择mes_scrap_reason表。导入后编辑配置：生成模块名填mes，业务名填scrap_reason，所属包填com.ruoyi.mes。配置好之后点“生成代码”，会下载一个zip包。

5.2 生成代码集成和菜单SQL

把zip包解压，按照目录结构把文件复制到项目对应位置：

• java/main/java/com/ruoyi/mes/controller/MesScrapReasonController.java
• java/main/java/com/ruoyi/mes/domain/MesScrapReason.java
• java/main/java/com/ruoyi/mes/mapper/MesScrapReasonMapper.java
• java/main/java/com/ruoyi/mes/service/IMesScrapReasonService.java + impl
• resources/mapper/mes/MesScrapReasonMapper.xml
• 前端views/mes/scrapReason/index.vue
• 前端api/mes/scrapReason.js

复制完还不能直接用，关键是配置菜单权限。若依的菜单是存在数据库表sys_menu里的，需要在系统管理→菜单管理里新增目录和菜单，或者直接执行生成包里的menu.sql。SQL里最重要的几个字段是parent_id（父菜单ID）、component（前端组件路径）、perms（权限标识）、menu_type（M目录、C菜单、F按钮）。perms字段要和前端v-hasPermi指令里写的权限标识一致，否则按钮显示不出来。

配置完菜单后，刷新前端页面，菜单栏就会出现“报废原因维护”，点进去就是一套能增删改查的页面。从建表到菜单可用，二十分钟搞定，这就是若依代码生成器的价值，也是MES快速交付的基础。

5.3 二次开发的几个核心习惯

用若依做MES二次开发，有几个习惯建议早点养成。Controller要继承BaseController，这样自带分页、导出、参数校验这些能力；分页查询用startPage()加TableDataInfo返回，参数接收用实体对象，不要一个个参数手撸。

Service的命名规范跟若依保持一致，I开头接口，Impl结尾实现。复杂业务逻辑写ServiceImpl里，Controller只做参数接收和响应返回，别把逻辑堆在Controller里。

前端接口统一走request.js封装的请求实例，每个接口方法对应api目录下一个函数，不要在Vue组件里直接调axios。这样页面和接口层解耦，后面前端页面重构不会波及接口定义。

6. 部署与开发中常见问题排查实录

6.1 前端启动和打包类问题

Q1：npm install报node-sass安装失败。

这个坑太经典了。解决办法是把package.json里的node-sass删掉，换成sass，然后重新npm install。命令：

npm uninstall node-sass npm install sass@1.32.13 --save-dev

或者用官方推荐的npmmirror镜像安装node-sass二进制：

npm install node-sass --sass-binary-site=https://npmmirror.com/mirrors/node-sass/

Q2：npm run dev启动后页面白屏，控制台报错。

先检查浏览器地址是不是 http://localhost:80 ，不是8080。RuoYi-Vue开发服务器默认端口是80，如果被系统服务占用会启动失败。看控制台报错信息，如果是module解析失败，几乎都是依赖没装全，删掉node_modules目录重新install一次。

6.2 后端启动和接口类问题

Q3：后端启动报Failed to configure a DataSource。

这个问题九成是配置文件里的数据源连不上。先ping一下数据库地址，再用命令行手动连一下MySQL，确认账号密码是对的。另外确认MySQL允许远程连接，root用户默认只能localhost访问，需要授权或者新建一个专用账号。

Q4：登录接口报错“用户不存在/密码错误”，但明明用了admin/admin123。

先确认初始化SQL脚本执行成功了。若依默认的管理员账号是admin，密码admin123，如果登录失败，看看数据库sys_user表里有没有admin这条记录，password字段是不是密文而不是明文。如果表是空的，重新导入系统初始化脚本。

Q5：接口返回401或token失效。

前端登录成功后token存在cookie里，后端通过Redis校验。Redis重启后token就丢了，需要重新登录。如果Redis设置了密码但后端没配，会一直报认证失败。排查思路就是：先看Redis能不能连上，再看后端有没有连的是同一个Redis实例。

6.3 部署访问类问题

Q6：部署后前端能打开，但点登录接口调不通。

F12打开浏览器开发者工具，看Network面板，接口请求地址如果是http://your-server/prod-api/login，然后返回404或502，问题出在Nginx代理。检查Nginx里location /prod-api/配置的proxy_pass是不是localhost:8080，这里比较容易搞错的就是proxy_pass结尾的斜杠有没有写对。

Q7：上传的文件404访问不了。

若依上传的文件默认通过/profile/路径访问，Nginx里如果没有配location /profile/，或者alias指向的目录和实际上传目录不一致，就会404。对照application.yml里的ruoyi.profile配置项找到实际路径，再和Nginx的alias对上。

6.4 我整理的避坑清单

几个项目跑下来，我个人的体感是：MES开发和普通管理系统开发最大的区别，在于业务约束特别多。普通管理系统增删改查就行，MES每个动作都有状态流转，都有数量校验，都有上下游联动。所以用若依可以快速搭界面，但核心业务逻辑一定要自己写扎实，尤其要注意事务控制——比如工单下达时要同时校验库存、更新工单状态、生成批次号，这三个操作必须在一个事务里，否则数据会不一致。

另外一个小技巧：RuoYi的日志记录和操作日志默认是切面实现的，开发期建议把日志级别调到DEBUG，能看到完整SQL，排错效率翻倍。生产环境再调回INFO，避免日志量过大。配置在application.yml里的logging.level，可以单独给某个mapper包设DEBUG：

logging: level: com.ruoyi.mes.mapper: debug

最后再分享一个我的习惯。每次用代码生成器生成一个模块之后，我习惯把生成的菜单SQL、前端页面文件和后端java文件按“模块名/日期”归档到项目docs/generated目录下。后面如果要回滚、换人交接、复盘新增了哪些功能，一目了然。MES项目周期动辄几个月，这种看似很小的工作习惯，关键时刻能省下大把找代码的时间。

本文还有配套的精品资源，点击获取