简介基于Java的MES生产管理系统源码是一套面向制造企业的完整制造执行系统实现涵盖生产计划、物料需求、车间控制、质量检测、设备维护等典型模块适合计算机专业学生用于毕业设计也适合Java开发者学习企业级系统架构。压缩包共1140个文件以396个Java源文件为核心承载业务逻辑268个JS和120个JSP页面负责前端交互展示另有CSS、JSON、XML等资源文件以及SQL数据库脚本和XLSX文档包体约8MB便于快速部署与研究。项目后端采用Spring Boot、MyBatis等主流框架前端集成Bootstrap、LayerUI等组件模块分层清晰读者可对照代码理解MES各模块的数据流与权限控制并可根据需求改造成自己的毕设项目。标签提及的C#、PHP也可能作为跨语言接口或对照方案为多技术栈学习提供额外参考。目前已有1432人学习浏览对想深入生产管理系统开发实战的读者来说是一份高价值参考资料。1. 基于 Java 的 MES 生产管理系统源码拆开这个 zip 前先想清楚的一件事基于 Java 的 MES 生产管理系统源码.zip属于典型的毕设级源码包文件齐全但能不能顺利跑起来全看你对 JDK、MySQL、配置文件这三处环境的判断。MES制造执行系统夹在 ERP 和车间设备之间管的是工单下发、工序流转、报工、完工质检这一串从计划到执行的核心链路比普通 CRUD 系统多了一层业务状态流转和数量校验逻辑。这套以 Spring Boot MyBatis MySQL 为后端、Layui 为前端的源码适合拿来做毕业设计、课程设计也适合刚入行的 Java 工程师拆开看数据模型和事务写法。先说一个现实这类 zip 包通常没有部署说明书十次启动报错有七八次是环境版本问题而不是源码本身的问题。那我们就按数据表设计、启动配置、报工业务、常见坑点四个层面拆开讲最后补一个可以直接展示的车间看板让整套工单数据有个看得见的出口。2. MES 核心数据模型工单、工序、报工、质检四张表怎么串起来拿到 zip 之后先别急着启动项目先翻 sql 目录。MES 这类系统的功能边界都写在表结构里做完多少业务、哪些模块是摆件读一遍建表脚本基本就有数了。下面以 Spring Boot 2.x MyBatis 版本为例展开如果你拿到的是基于若依框架二次改造的 MES 版本表名前缀和权限相关表会不同但工单到质检这条主链路的字段设计是通用的。2.1 工单状态不是字符串字段五个状态的流转条件几乎每一版 MES 源码里都有一张工单主表状态字段建议用 int 而不是 varchar。原因不复杂后端用枚举做映射、前端下拉框取值、报表 SQL 里写条件判断都比字符串方便也避免“已下发”和“ 已下发”这种带空格的历史脏数据。部分简化版源码会把状态直接写死在 service 里也能跑但可读性和扩展性都比较差。一个常见做法是在代码里定义工单状态枚举类把魔法数字包装成语义化对象public enum WorkOrderStatus { DRAFT(0, 草稿), RELEASED(1, 已下发), IN_PROGRESS(2, 生产中), WAIT_QC(3, 待质检), FINISHED(4, 已完工), CLOSED(5, 已关闭); private final int code; private final String desc; WorkOrderStatus(int code, String desc) { this.code code; this.desc desc; } public static WorkOrderStatus of(int code) { for (WorkOrderStatus status : values()) { if (status.code code) { return status; } } throw new IllegalArgumentException(未知工单状态: code); } public int getCode() { return code; } public String getDesc() { return desc; } }这个枚举做的事很简单把 0、1、2、3、4、5 这些数字从散落的判断逻辑里收拢到一处。实际业务流转条件是计划员创建工单后状态是草稿下发后变成已下发操作工第一次报工后进入生产中当累计报工数量等于计划数量时业务层把工单置为待质检质检通过后置为已完工最后计划员或管理员关闭工单。最容易漏的是“待质检”这一档很多简化版源码会省略它把完工和质检耦合在同一个按钮里后面想扩展返工、报废逻辑就很被动。看这套源码的状态字段时注意一点部分版本会把 FINISHED 和 CLOSED 合并成 4 个状态。合并不是错但你得在答辩时说清楚为什么关闭等价于完工不然评委追问一句就容易露馅。2.2 四张核心表的 DDL字段怎么设计才扛得住统计报表接着看最常用到的四张表mes_work_order工单、mes_process工序字典、mes_report报工记录、mes_quality_check质检记录。物料表、设备表、班次表在多数毕设里也有但业务耦合度比这四张低得多可以先放一边。-- 工序字典表 CREATE TABLE mes_process ( process_id BIGINT NOT NULL AUTO_INCREMENT COMMENT 工序ID, process_code VARCHAR(32) NOT NULL COMMENT 工序编码, process_name VARCHAR(64) NOT NULL COMMENT 工序名称, standard_time INT DEFAULT NULL COMMENT 标准工时(分钟), status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0停用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (process_id), UNIQUE KEY uk_process_code (process_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT工序字典表; -- 生产工单表 CREATE TABLE mes_work_order ( work_order_id BIGINT NOT NULL AUTO_INCREMENT COMMENT 工单ID, work_order_no VARCHAR(40) NOT NULL COMMENT 工单编号, product_id BIGINT NOT NULL COMMENT 产品ID, plan_qty DECIMAL(12,2) NOT NULL COMMENT 计划数量, completed_qty DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 已完成数量, status TINYINT NOT NULL DEFAULT 0 COMMENT 0草稿 1已下发 2生产中 3待质检 4已完工 5已关闭, priority TINYINT NOT NULL DEFAULT 2 COMMENT 优先级 1高 2中 3低, plan_start_time DATETIME DEFAULT NULL COMMENT 计划开始时间, plan_end_time DATETIME DEFAULT NULL COMMENT 计划结束时间, create_by VARCHAR(32) DEFAULT NULL COMMENT 创建人, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (work_order_id), UNIQUE KEY uk_work_order_no (work_order_no), KEY idx_status (status), KEY idx_plan_start (plan_start_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT生产工单表; -- 报工记录表 CREATE TABLE mes_report ( report_id BIGINT NOT NULL AUTO_INCREMENT COMMENT 报工ID, work_order_id BIGINT NOT NULL COMMENT 工单ID, process_id BIGINT NOT NULL COMMENT 工序ID, operator_id BIGINT NOT NULL COMMENT 操作工ID, report_qty DECIMAL(12,2) NOT NULL COMMENT 本次报工数量, shift VARCHAR(16) DEFAULT NULL COMMENT 班次 白班/夜班, report_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 报工时间, remark VARCHAR(255) DEFAULT NULL, PRIMARY KEY (report_id), KEY idx_wo (work_order_id), KEY idx_operator (operator_id), KEY idx_report_time (report_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报工记录表; -- 质检记录表 CREATE TABLE mes_quality_check ( check_id BIGINT NOT NULL AUTO_INCREMENT COMMENT 质检ID, work_order_id BIGINT NOT NULL COMMENT 工单ID, process_id BIGINT NOT NULL COMMENT 工序ID, check_by VARCHAR(32) DEFAULT NULL COMMENT 质检员, total_qty DECIMAL(12,2) NOT NULL COMMENT 送检数量, pass_qty DECIMAL(12,2) NOT NULL COMMENT 合格数量, defect_qty DECIMAL(12,2) NOT NULL DEFAULT 0 COMMENT 不合格数量, check_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (check_id), KEY idx_wo (work_order_id), KEY idx_check_time (check_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT质检记录表;为什么 plan_qty 和 report_qty 用 DECIMAL(12,2) 而不是 INT离散装配行业按件计数用 INT 说得过去但很多 MES 场景要按重量、面积、长度报工用 INT 会导致冲压、注塑这类按公斤计量的产线没法用。DECIMAL 能兼顾两种场景代价只是每行多几个字节。四张表都没有物理外键这是毕设源码的常见取舍逻辑外键配合普通索引分页查询少一次外键检查的开销代码里用 JOIN 关联即可。四张表的关系也很直观报工记录和质检记录通过 work_order_id 关联到工单通过 process_id 关联到工序。这里最忌讳的是质检记录只关联工单不关联工序那样哪个环节产生的废品永远查不出来。如果源码里用的是 MyBatis-Plus 而不是原生 MyBatis实体类上会有 TableName 注解表字段与实体属性的映射方式有差异但上述 DDL 的结构不受影响。表名关键字段业务含义mes_work_orderstatus / completed_qty / priority控制工单能否报工统计完成数量mes_reportwork_order_id / process_id / report_qty报工明细产量报表按它分组mes_quality_checktotal_qty / pass_qty / defect_qty合格率报表的数据源mes_processprocess_code / standard_time工序字典标准工时参与排产计算3. Spring Boot MyBatis 启动流程JDK、MySQL、配置文件三板斧这一章解决“下完 zip 不知从哪下手”的问题。这类源码包的目录结构是固定的花五分钟看清目录再决定动哪里能避开大量无效操作。3.1 先确认版本Spring Boot 原生版还是基于若依框架的改造版打开 pom.xml 第一行 parent 往下看 spring-boot-starter-parent 的版本号。Spring Boot 2.x 项目对应 JDK 8Spring Boot 3.x 需要 JDK 17。毕设类 MES 绝大多数是 2.x少数新做的若依框架版基于 Spring Boot 2.7 JDK 8也有直接改到 3.0 的但搭配的依赖组件兼容性风险更高不太建议选。判断是不是若依框架版看依赖里有没有 RuoYi 模块或若依的 common/security 组件看启动类所在包名是不是 com.ruoyi。如果是这一版的登录认证走的是若依自己的 Security 过滤链数据库里有 sys_user、sys_role、sys_menu 这一组表启动流程可以按下面步骤走但改权限逻辑要按若依文档来不能拿普通 SSM 项目的思路去找 session。如果依赖里出现 mybatis-plus-boot-starter说明源码走的是 MyBatis-Plus实体类用 TableName 映射启动方式和原生 MyBatis 一样只是 XML 里的主键生成策略略有差异。解压后用 IDEA 打开项目先确认目录结构unzip mes-system.zip -d mes-system cd mes-system tree -L 3 -d .常见结构如下不同版本名称会有差异mes-system/ ├── sql/ # 建库脚本和初始数据 ├── src/main/java/com/xxx/mes/ │ ├── controller/ # 页面与接口入口 │ ├── service/ # 业务逻辑层 │ ├── mapper/ # MyBatis Mapper 接口 │ ├── entity/ # 实体类 │ └── MesApplication.java # 启动类 ├── src/main/resources/ │ ├── application.yml # 数据库、端口、日志配置 │ ├── mapper/ # MyBatis XML │ └── static/ # Layui、ECharts 静态资源 └── pom.xml注意如果 IDEA 打开后没有自动识别 Maven 项目右键 pom.xml 选 Add as Maven Project如果 JDK 没匹配上在 Project Structure 里把 Project SDK 切到 1.8。另外个别 zip 包在 Windows 上用自带解压工具会出现资源文件丢失建议用 7-Zip 解压到纯英文路径不要放进带空格和中文的目录。这一步看着像玄学但很多启动失败确实栽在中文路径导致资源读取不到。3.2 初始化数据库与修改配置文件先看 sql 目录一般有两个文件init.sql 是建库建表data.sql 是初始数据默认账号、工序字典、产品样例。执行顺序不能反先建库再导数据否则初始数据没地方落。mysql -uroot -p sql/init.sql mysql -uroot -p sql/data.sql # 如果 init.sql 里没有建库语句需要先手动建库 mysql -uroot -p -e CREATE DATABASE mes_db DEFAULT CHARACTER SET utf8mb4;如果 init.sql 里已经有 CREATE DATABASE上面的建库命令会报错但不影响后续导入。执行完用show tables;能看到 mes_ 开头的表说明脚本没问题。接下来改 application.yml最关键的是数据库连接部分spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/mes_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue username: root password: 123456 server: port: 8080参数逐个说清楚characterEncodingutf8 控制与 MySQL 交互时的中文字符集缺失时插入中文会变问号serverTimezoneAsia/Shanghai 解决 MySQL 8.x 下的时区报错allowPublicKeyRetrievaltrue 应对 MySQL 8 的 caching_sha2_password 认证插件不加会报 Public Key Retrieval is not alloweduseSSLfalse 是开发环境跳过 SSL 握手内网测试不需要加密。password 用双引号包起来是因为 yaml 会把 123456 这种纯数字解析成整数连接池拿到类型不匹配的配置值会拒绝启动。注意如果本机同时装了 MySQL 5.7 和 8.0 两个实例尽量用客户端版本与项目驱动版本一致的实例去连可以减少排查噪音。3.3 启动项目与登录验证配置文件改好后在项目根目录执行mvn spring-boot:run或者先用 mvn package 打 jar再 java -jar 启动。调试阶段推荐 IDE 方式直接运行 MesApplication 的 main 方法方便打断点看业务。启动日志里看到 Started MesApplication in x.xxx seconds 才是真正加载完成只看到 Tomcat started on port 不算数。验证接口用 curl 打一下登录接口curl -X POST http://localhost:8080/login \ -H Content-Type: application/json \ -d {username:admin,password:admin123}不同源码的登录路径不同有的写在 RequestMapping(/api/login)有的是表单提交 /login。curl 返回 JSON 里带 token 或跳转地址都算通如果返回 404去 controller 包里搜 login 关键字把路径替换掉再试。浏览器能打开登录页并完成一次登录启动链路就算走通了。4. 报工与质检业务闭环事务、防重与统计的实现位置MES 里最核心的交互操作不是增删改查页面而是报工。报工的代码质量基本决定了这套源码的答辩含金量也是 Java 面试里“事务失效”这类高频问题最贴近实际的载体。4.1 报工 Service一次事务里完成数量校验、插入记录、状态流转报工接口的职责通常是三个校验当前工单状态和剩余数量、写入报工明细、累加完成数并触发状态变化。下面这段是这套 MES 里最常见的实现骨架Transactional(rollbackFor Exception.class) public void doReport(Long workOrderId, Long processId, BigDecimal qty, Long operatorId, String shift) { // 1. 锁行查询防止并发报工读到同一份数据 WorkOrder order workOrderMapper.selectByIdForUpdate(workOrderId); if (order null) { throw new BusinessException(工单不存在); } if (order.getStatus() ! WorkOrderStatus.IN_PROGRESS.getCode()) { throw new BusinessException(当前状态不允许报工); } // 2. 计划数量与已完成数量的差值校验 BigDecimal remain order.getPlanQty().subtract(order.getCompletedQty()); if (qty.compareTo(remain) 0) { throw new BusinessException(报工数量超过剩余数量剩余 remain); } // 3. 插入报工记录 MesReport report new MesReport(); report.setWorkOrderId(workOrderId); report.setProcessId(processId); report.setOperatorId(operatorId); report.setReportQty(qty); report.setShift(shift); reportMapper.insert(report); // 4. 累加完成数量 workOrderMapper.increaseCompletedQty(workOrderId, qty); // 5. 完成数量达到计划数量时自动进入待质检状态 BigDecimal after order.getCompletedQty().add(qty); if (after.compareTo(order.getPlanQty()) 0) { workOrderMapper.updateStatus(workOrderId, WorkOrderStatus.WAIT_QC.getCode()); } }这段逻辑有几个关键点值得拆开说。selectByIdForUpdate 是行级悲观锁MySQL InnoDB 下会锁住这张工单行直到事务提交单机部署的毕设系统里这是最稳妥的写法代价是并发能力有限以后如果接入多台服务器再考虑改成 version 乐观锁字段。Transactional(rollbackFor Exception.class) 指定受检异常也回滚这是很多人容易忽略的Spring 默认只对 RuntimeException 回滚如果业务异常类继承 Exception 而不写 rollbackFor就会出现数据半写入但异常被吞掉、事务照常提交的翻车现场。角色权限在报工环节也有体现状态字段的流转由 Service 层判断前端菜单只是入口真正的权限卡点在 Service 方法上。操作工角色不能直接调 updateStatus 跳过质检计划员不能替别人报工。这些在源码里通常体现为方法级注解或 if 判断读代码时可以顺带看一下。4.2 防重复提交数据库唯一约束比前端禁用按钮可靠前端在报工按钮上做“提交后禁用”“loading 状态”只能算体验优化拦不住绕过页面直接调接口的请求也拦不住两个浏览器标签页同时操作。真正可靠的是数据库层面约束。常见做法是在报工请求流水号上做唯一索引。业务里每次报工生成一个流水号例如日期加工单号加序号前端连同报工数据一起提交后端先查流水号是否存在存在就直接拒绝。更简洁的方案是给 mes_report 表加一个请求号字段和唯一键ALTER TABLE mes_report ADD COLUMN req_no VARCHAR(64) DEFAULT NULL COMMENT 请求流水号, ADD UNIQUE KEY uk_req_no (req_no);insert 时带上流水号重复提交时数据库抛 DuplicateKeyException在 controller 层捕获后返回“请勿重复提交”。这个方案比先查再插更干净因为极端并发下先查再插依然存在时间窗口而唯一索引是数据库写入时的强校验没有窗口期。4.3 合格率与班组产量的统计 SQL统计报表是 MES 源码包里的重头戏。最常见的两张报表是“工序合格率”和“班组每日产量”。合格率统计时容易犯的错误是直接拿质检表的合格数除以送检数而没有按工序分组SELECT p.process_name, SUM(qc.total_qty) AS total_qty, SUM(qc.pass_qty) AS pass_qty, ROUND(SUM(qc.pass_qty) / SUM(qc.total_qty) * 100, 2) AS pass_rate FROM mes_quality_check qc LEFT JOIN mes_process p ON qc.process_id p.process_id WHERE qc.check_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY p.process_name ORDER BY pass_rate ASC;用 LEFT JOIN 而不是 INNER JOIN是为了把有质检记录但工序字典没匹配上名称的记录也展示出来避免报表莫名少一行后还要排查半天。ORDER BY pass_rate ASC 排在最前面的不是合格率最高的工序而是最低的看板需要优先关注的就是它。如果报表粒度要落到班组就在查询里加上班次字段 shift或者关联工单表拿归属班组编码换的只是 GROUP BY 的分组字段。如果拿到的是若依框架版报表查询会多一层数据权限过滤Service 层可能被 DataScope 拦截按用户所属部门追加 SQL 条件。查出的数据和预期不一致时先确认当前用户的 dept_id 是否在目标部门下面。5. 实操避坑MySQL 8 驱动、中文乱码、报工超发、若依框架版选型编译型项目的问题大多能靠日志定位但下面这几类问题在 MES 源码包里出现频率极高而且报错信息要么迷惑性很强要么根本不报错只是数据错。每条按现象、原因、解决的顺序写可以直接对照排查。5.1 MySQL 8.x 连不上驱动和认证插件不匹配现象启动报Access denied for user rootlocalhost有时跟着Public Key Retrieval is not allowed。账号密码在 Navicat 里能连Java 项目就是连不上。原因MySQL 8.x 默认认证插件是 caching_sha2_password而源码包里带的 mysql-connector-java 往往还是 5.1.x旧驱动只支持 mysql_native_password第二个报错是因为第一次连接时需要拿服务端公钥连接参数里没允许这个动作。解决把 pom.xml 里的 MySQL 驱动版本换成 8.0.x 系列并在 application.yml 的 url 里加上 allowPublicKeyRetrievaltrue、useSSLfalse、serverTimezoneAsia/Shanghai。如果数据库是 5.7驱动沿用 5.1.x 也没问题按需加参数即可。这个坑在 MySQL 8 环境里出现概率极高且表面报错很有迷惑性建议作为第一排查项。5.2 中文乱码连接、页面、Tomcat 三处都要查现象登录后菜单、工单名称全是问号或者“锟斤拷”。原因乱码是典型的三处叠加问题数据库连接 url 没带 characterEncodingutf8写入时字符集不对页面响应头 content-type 没指定 UTF-8Tomcat 对 URI 参数的解码编码不是 UTF-8。三处只要有一处不对页面显示就会花。解决配置文件连接参数补上 characterEncodingutf8Spring Boot 项目确认 spring.servlet.encoding.forcetrueJSP 页面检查每页的 contentType 是否含 charsetUTF-8。再顺手查数据库和表的 charsetshow create table mes_work_order结果不是 utf8mb4 就转一遍。三条链路确认一致后再启动乱码类问题一次清干净。5.3 报工数量超过计划数量update 条件兜底现象连续报工或两个页面同时操作后completed_qty 比 plan_qty 大完成率报表出现 102% 这种数字。原因服务层如果只做了 select 再 update 的取值判断没有行锁也没有唯一约束两个并发请求能读到同一个 completed_qty各自校验通过后各加一次总数就超了。这类问题毕设里不一定会被并发触发但答辩演示时网络卡顿很容易暴露。解决4.1 的 selectByIdForUpdate 是一种方案更靠得住的是让数据库判断条件把累加语句改成带剩余量条件的 UPDATEUPDATE mes_work_order SET completed_qty completed_qty #{qty} WHERE work_order_id #{workOrderId} AND completed_qty #{qty} plan_qty;影响行数为 0 说明超额业务层抛异常并回滚。这样即使多个请求同时到达也只有第一个能更新成功后面全部被条件挡住。5.4 若依框架版和自研 SSM 版选错越改越乱现象下载的 zip 描述写着“基于 Java”解压后发现不是想象中的 SSM 三层结构登录入口找不到启动时过滤链拦截所有请求。原因现在交付的 MES 源码有一批是基于若依框架二次改造的。若依自带 Spring Security 认证链、Redis 登录态、代码生成器目录和自研 SSM 完全不同。用普通三层项目的经验去查 session 自然找不到入口想删掉权限模块又牵连启动时的依赖注入直接启动失败。解决先看启动类所在包名com.ruoyi 开头的是若依版com.xxx.mes 开头的一般是自研版。若依版不要动它的登录和权限核心只改业务表和页面自研版按第 3 章的配置走。答辩时若依版反而占优势能现场演示给不同角色分配菜单但作为 Java 工程师做二次开发若依版的学习成本更高后续加功能也会更快怎么取舍取决于交付对象。5.5 日志目录不存在与静态资源 404现象项目启动成功页面样式全丢控制台按固定节奏报日志文件无法创建。原因源码里配置了绝对路径比如日志写到 /home/mes/logs、上传文件写到 /data/uploadWindows 上没有这些目录。日志输出和上传功能会静默失效页面引用的 Layui 静态文件则可能因为打包时资源过滤没进 jar。解决全局搜 application.yml 和 application.properties 里的绝对路径全部改成相对路径日志改成 logs/上传目录改成 upload/带 ../ 的越级路径也顺手改掉。Spring Boot 打 jar 后如果静态资源没出现在 BOOT-INF/classes/static 下去 pom.xml 的 resources 配置里补一条包含 static 的声明。这类 404 不看 jar 包内容根本猜不到原因属于血泪经验。6. 给这套 MES 加一个车间看板半小时从 SQL 到 ECharts毕设答辩最直观的加分项是有一个能展示车间实时数据的看板页面。这套源码自带的首页一般只有统计卡片缺一张按产线对比的图表。下面补一个最小可用的看板从 SQL 到页面图表半小时能跑通。6.1 后端聚合接口按产线统计今日完成情况看板要展示的是今天各产线的计划数量和完工数量。在 Mapper XML 里加一条按日期分组的查询select idselectTodayLineProgress resultTypecom.example.mes.vo.LineProgressVO SELECT line_name AS lineName, COUNT(*) AS totalCount, SUM(CASE WHEN status 4 THEN 1 ELSE 0 END) AS finishedCount FROM mes_work_order WHERE plan_start_time CURDATE() AND plan_start_time CURDATE() INTERVAL 1 DAY GROUP BY line_name ORDER BY line_name /select这里用 CURDATE() AND CURDATE() INTERVAL 1 DAY而不是 DATE(plan_start_time) CURDATE()是为了让条件能走 idx_plan_start 索引。表只有几千行时感觉不到差别但导入几万条测试数据后响应时间差距就出来了。status 4 把已完工和已关闭都算作完工避免状态流转到关闭后数字从看板里消失造成跳动。Controller 层暴露一个 GET 接口前端用 fetch 读取RestController RequestMapping(/api/dashboard) public class DashboardController { GetMapping(/today) public ResultListLineProgressVO today() { return Result.ok(dashboardMapper.selectTodayLineProgress()); } }6.2 前端展示ECharts 的柱状图配置找一个有 Layui 的页面模板在 script 标签里引入 echarts.min.js然后初始化图表fetch(/api/dashboard/today) .then(function (res) { return res.json(); }) .then(function (res) { var data res.data; myChart.setOption({ tooltip: {}, legend: { data: [计划, 完工] }, xAxis: { type: category, data: data.map(function (d) { return d.lineName; }) }, yAxis: { type: value }, series: [{ name: 计划, type: bar, data: data.map(function (d) { return d.totalCount; }) }, { name: 完工, type: bar, data: data.map(function (d) { return d.finishedCount; }) }] }); });如果项目里前端是原生 HTML就放在 window.onload 里若是若依版走它自己的前端模块加载方式。注意后端 JSON 返回的字段名要和前端 d.lineName、d.totalCount 严格一致Java 的 VO 用驼峰命名JSON 序列化后就是驼峰前端别用下划线版本去取否则图表永远是空的。这套新增代码不碰原有业务表只是给已有数据多开一个导出出口。把看板放到登录后首页顶部刷新时能看到完成率随着报工实时上涨这种动态效果在答辩现场非常加分。我拿到这类源码包的习惯是先跑通再改代码。第一次拆 MES 时我直接钻进业务代码把状态流转和数据模型全看完才去启动结果在 MySQL 8 驱动上卡了一晚上。从那以后凡是 zip 源码第一件事永远是看 sql 目录和 application.yml把环境排干净再聊业务。这次补完看板整套工单链路的数据终于有了一个直观的出口。希望帮到你。本文还有配套的精品资源点击获取
