基于SpringBoot的电缆生产管理系统：架构设计与核心业务实现-编程实验室

简介：生产管理系统是制造业数字化转型的核心，它通过整合订单、物料、设备和人员信息，实现生产过程的透明化、精细化和可追溯。其核心原理在于将业务流程数据化，利用数据库和业务逻辑层固化生产规则，从而优化排程、控制成本并提升质量。在电缆制造这类流程复杂、产品非标化程度高的行业，一套深度契合行业特性的生产管理系统技术价值尤为凸显。它需要精准管理以“米”为单位的长度生产、多级BOM（物料清单）和复杂的工艺路线。本系统基于SpringBoot单体架构，结合MyBatis和MySQL，实现了从销售订单、MRP计算、车间报工到质量追溯的全生命周期管理，为电缆企业提供了一个可落地的数字化解决方案骨架。

1. 项目背景与核心价值：为什么电缆行业需要专属的生产管理系统？

如果你在电缆制造企业待过，或者做过相关的信息化项目，就会知道这行当的生产管理有多“酸爽”。表面上看，电缆不就是铜丝、塑料、橡胶这些原料的组合吗？但实际生产流程的复杂程度，远超外行想象。从订单接收到最终成品入库，中间要经历拉丝、绞线、绝缘、成缆、铠装、护套、测试、包装等数十道工序。每一道工序都涉及不同的设备、工艺参数、质量标准和物料流转。更头疼的是，电缆产品规格极其繁多，导体截面、芯数、电压等级、护套材料、颜色、长度等任何一个参数变化，都可能产生一个新的“非标品”。

这就导致传统靠Excel表格和纸质流转卡的管理方式完全失灵。生产计划排程混乱、物料消耗统计不准、在制品（WIP）堆积如山、质量追溯困难、订单交付延期……这些都是家常便饭。我见过不少年产值几个亿的电缆厂，车间主任每天最重要的工作就是拿着对讲机满车间跑，去“找”某盘半成品电缆到底做到哪一步了，或者紧急协调某个订单的原料是否到位。

所以，一个专门为电缆行业定制的生产管理系统，其核心价值就凸显出来了。它不是一个通用的ERP或MES系统，而是深度结合了电缆生产工艺、BOM（物料清单）特点、质量检验流程的垂直领域解决方案。这个基于SpringBoot的毕业设计源码，其意义就在于提供了一个可落地、可二次开发的“骨架”，让开发者或企业能够快速构建起符合自身管理需求的数字化平台。它解决的不仅仅是“有没有系统”的问题，更是“系统懂不懂行”的问题。通过将电缆行业特有的业务逻辑（如以“米”为单位的长度管理、分段报工、成盘入库等）固化到系统中，能极大提升生产透明度、协同效率和成本控制能力。

2. 系统架构与技术选型：SpringBoot为何是此类项目的理想起点？

拿到这个源码包，解压后看到那一堆熟悉的Java文件，你可能会想：为什么是SpringBoot？现在微服务、云原生不是很火吗？对于电缆生产管理这类偏重内部流程、数据一致性要求高、且通常部署在工厂内网环境的系统，SpringBoot的单体应用架构往往是更务实、更高效的选择。

2.1 技术栈全景与选型理由

这套源码典型的技术栈应该是：SpringBoot 2.x + Spring MVC + MyBatis/MyBatis-Plus + MySQL + Thymeleaf / 前后端分离（Vue/React）。我们逐一拆解其选型背后的逻辑：

SpringBoot作为基石：它的核心优势是“约定大于配置”和快速启动。对于毕业设计或中小型企业的初始项目而言，开发者不需要在繁琐的XML配置、依赖冲突上耗费大量时间。内嵌的Tomcat服务器使得打包即运行（java -jar），部署极其简单，非常适合工厂IT运维能力相对薄弱的环境。从热词中看到有人搜索“springboot版本太高”的问题，这恰恰提醒我们，在启动此类项目时，应选择一个长期支持（LTS）且生态稳定的版本，如SpringBoot 2.7.x，避免追求最新版带来的未知兼容性问题。
MyBatis作为数据持久层：相比全自动化的JPA/Hibernate，MyBatis提供了更灵活的SQL掌控能力。电缆行业的业务报表往往涉及复杂的多表关联和聚合计算（例如，统计某个规格电缆的月度产量、原料耗用、合格率），手写优化过的SQL比自动生成的语句在性能上更有保障。MyBatis-Plus在此基础上进一步提供了通用的CRUD操作，能大幅减少基础数据访问的代码量。
数据库选型MySQL：开源、成熟、社区活跃，是绝大多数国内项目的首选。对于生产管理系统，需要特别注意数据库表的设计要贴合业务。例如，电缆的“生产工单”表，除了常规信息，很可能会有“总长度（米）”、“已完成长度（米）”、“盘号”、“当前工序”等字段。
前端技术选择：如果源码是前后端不分离的（使用Thymeleaf、JSP等模板引擎），那么它更侧重于快速实现和简化部署，所有东西打成一个包。如果是前后端分离的（提供独立的Vue/React前端源码），则意味着更现代的开发模式，前后端可以并行开发，前端用户体验更好，但部署稍复杂。对于工厂内网环境，两种模式都有其应用场景。

2.2 项目结构深度解析

一个结构清晰的SpringBoot项目是理解和二次开发的基础。通常，这个源码包解压后，标准的Maven项目结构如下：

cable-production-system/ ├── src/main/java/ │ ├── com.xxx.cable/ │ │ ├── controller/ # 控制层，接收请求，调用服务 │ │ ├── service/ # 业务逻辑层，核心所在 │ │ │ ├── impl/ # 服务实现类 │ │ ├── dao/ # 数据访问层（或mapper目录），MyBatis接口 │ │ ├── entity/ # 实体类，与数据库表对应 │ │ ├── dto/ # 数据传输对象，用于前后端交互 │ │ ├── vo/ # 视图对象，用于页面展示 │ │ └── config/ # 配置类，如数据源、拦截器、Swagger等 │ └── resources/ │ ├── mapper/ # MyBatis的XML映射文件 │ ├── static/ # 静态资源（css, js, images） │ ├── templates/ # 模板文件（如果是Thymeleaf） │ └── application.yml # 核心配置文件 ├── sql/ # 数据库初始化脚本 └── pom.xml # Maven依赖管理文件

关键点：你需要重点关注service层和mapper层的代码。service层包含了“创建生产计划”、“工序报工”、“质量检验录入”等核心业务逻辑。而mapper的XML文件则定义了这些业务背后的数据操作，从这里你能最直观地看到系统是如何处理电缆行业特有数据的。

注意：在导入项目到IDE（如IntelliJ IDEA或Eclipse）时，第一件事是检查pom.xml中的依赖版本是否兼容，尤其是SpringBoot父工程版本。根据热词中“springboot版本太高”的提示，如果本地环境JDK版本较低（如JDK 8），应避免使用SpringBoot 3.x（要求JDK 17+），选择SpringBoot 2.7.x更为稳妥。

3. 核心业务模块拆解：系统如何管理电缆生产的全生命周期？

一个完整的电缆生产管理系统，其核心业务模块是环环相扣的。下面我们深入几个关键模块，看看这套源码是如何实现从订单到产品出库的闭环管理的。

3.1 基础数据管理：系统的“地基”

这是所有功能的起点，如果基础数据不准，整个系统输出的都是垃圾。电缆行业的基础数据尤为复杂：

产品库（物料主数据）：不仅仅是一个产品编号和名称。它需要定义电缆的系列、型号、电压等级、导体材质（铜/铝）、标称截面、芯数、绝缘材料、护套材料、颜色、标准米重等数十个属性。在数据库中，这可能是一张主表加多张扩展属性表的结构。
BOM（物料清单）管理：电缆的BOM是典型的“倒树状”结构。成品电缆由护套、铠装层、成缆线芯等组成，线芯又由绝缘层和导体组成。BOM需要精确管理每一层所需的材料、规格、用量（如导体用铜的重量、绝缘料用量与长度和截面相关）。系统需要支持多级BOM的展开和汇总计算，这是进行物料需求计划（MRP）的基础。
工艺路线管理：定义生产一根/一盘电缆需要经过的所有工序（如拉丝→退火→绞线→绝缘→成缆→护套→测试），以及每道工序使用的设备类型、标准工时、能耗、质量检测点等。这是生产排程和车间调度的依据。

在源码中，你可能会找到类似ProductController、BomController、ProcessRouteController这样的类，以及对应的增删改查页面。二次开发时，这里最容易遇到的坑是数据完整性和校验。例如，删除一个已被生产订单引用的产品或BOM时，必须有严格的约束提示，而不是直接级联删除导致数据混乱。

3.2 销售订单与生产计划管理：从需求到指令

客户订单来了，系统如何将其转化为生产任务？

销售订单录入：录入客户信息、产品规格、长度、交货日期、特殊技术要求等。
订单评审与分解：系统需要支持对订单进行技术评审（是否有生产能力？）和交期评审。通过后，根据产品BOM和库存情况，自动或手动生成“生产计划单”或“生产工单”。
生产工单：这是车间执行的依据。一个核心字段是“计划生产长度”。工单需要与具体的“工艺路线”关联，并可能被拆分成更小的“批次”或“盘号”来执行，以适应实际生产中的设备能力和物料情况。

源码中，ProductionOrderService的createOrderFromSales方法很可能包含了这部分核心逻辑。这里的关键算法是物料需求计算（MRP）：根据订单产品、BOM和现有库存（原料、半成品），计算出需要采购或生产的物料清单和时间。虽然毕业设计项目可能简化了MRP逻辑，但这是一个非常重要的扩展点。

3.3 车间执行与进度跟踪：系统的“眼睛”

这是系统与生产现场交互最频繁的部分，也是数据采集的入口。

工序派工与报工：班组长通过系统，将生产工单中的任务派发到具体的机台或工人。工人完成一定量（如完成了一盘500米的绝缘工序）后，进行“报工”。报工数据包括：操作员、设备、生产长度、合格长度、废料长度、开始/结束时间。电缆行业报工的特殊性在于“长度报工”，系统需要实时累加已完工长度，并更新工单进度。
在制品（WIP）跟踪：系统需要实时展示每个工单、每盘电缆当前所处的工序位置。这通常通过扫描“流转卡”或“盘号”条码来实现。源码中可能有一个WorkInProgress实体，记录着盘号、当前工序、状态（待加工、加工中、已完工）、位置等信息。
设备状态监控：通过与设备PLC接口集成（这属于高级功能，毕业设计可能未实现），可以自动采集设备运行、停机、故障状态，为生产效率和设备维护提供数据支持。

3.4 质量管理与追溯：产品的“身份证”

电缆是安全性要求极高的产品，质量追溯是刚需。

检验标准管理：定义每道工序或最终成品的检验项目（如导体电阻、绝缘厚度、耐压测试）、标准值、公差范围。
检验数据录入：质检员对生产出的电缆进行检验，将实测数据录入系统。系统自动判断是否合格，并对不合格品进行记录（不合格现象、原因、处理方式：返工、降级、报废）。
全流程追溯：通过唯一的“盘号”或“生产批号”，可以正向追溯这盘电缆所用的原料批次、生产班组、机台、工艺参数、检验记录；也可以反向追溯，查询某一批原料最终用在了哪些成品电缆上。这在出现质量问题时至关重要。源码中的QualityInspectionRecord实体和相关的查询服务，是实现追溯功能的核心。

3.5 库存与物流管理：物料的“管家”

原料库存：管理铜杆、塑料颗粒、护套料等原料的入库、出库、盘点。关键点是原料的批次管理，因为不同批次的原料性能可能有细微差异。
半成品/成品库存：管理生产出的各工序半成品（如绝缘线芯）和最终成品电缆的入库。电缆库存管理的特点是按“盘”管理，每盘都有唯一的盘号、长度、存放位置（仓库、货位）。出库时，可能需要根据订单长度进行配盘（从多个盘中截取所需长度）。
发运管理：关联销售订单，生成发货单、物流单，更新库存状态。

4. 数据库设计与关键表结构分析

理解了业务，我们再看数据库设计，就能明白其所以然。以下是几个核心业务表的设计思路（仅为示例，非源码确切表结构）：

4.1 产品与BOM相关表

-- 产品主表 CREATE TABLE `product` ( `id` bigint PRIMARY KEY, `product_code` varchar(50) UNIQUE NOT NULL COMMENT '产品编码', `product_name` varchar(100) NOT NULL COMMENT '产品名称', `spec_model` varchar(200) COMMENT '规格型号', `conductor_material` varchar(20) COMMENT '导体材质', `conductor_section` decimal(10,2) COMMENT '标称截面(mm²)', `core_number` int COMMENT '芯数', `voltage_grade` varchar(20) COMMENT '电压等级', `unit` varchar(10) DEFAULT '米' COMMENT '单位', -- ... 其他属性 ); -- BOM主表 CREATE TABLE `bom` ( `id` bigint PRIMARY KEY, `parent_product_id` bigint NOT NULL COMMENT '父项产品ID', `version` varchar(20) COMMENT 'BOM版本', `effective_date` date COMMENT '生效日期', FOREIGN KEY (`parent_product_id`) REFERENCES `product`(`id`) ); -- BOM明细表 CREATE TABLE `bom_detail` ( `id` bigint PRIMARY KEY, `bom_id` bigint NOT NULL COMMENT 'BOM ID', `component_product_id` bigint NOT NULL COMMENT '子项物料ID', `quantity` decimal(15,4) NOT NULL COMMENT '数量', `unit` varchar(10) COMMENT '单位', `loss_rate` decimal(5,2) DEFAULT 0 COMMENT '损耗率(%)', `operation_seq` int COMMENT '工序顺序', FOREIGN KEY (`bom_id`) REFERENCES `bom`(`id`), FOREIGN KEY (`component_product_id`) REFERENCES `product`(`id`) );

设计要点：bom_detail中的quantity字段计算是难点。对于电缆，子项用量往往与父项“长度”相关，需要通过公式计算（如铜重量 = 长度 * 截面 * 密度 * 芯数）。在业务逻辑层需要封装此计算。

4.2 生产执行相关表

-- 生产工单表 CREATE TABLE `production_order` ( `id` bigint PRIMARY KEY, `order_no` varchar(50) UNIQUE NOT NULL COMMENT '工单号', `sales_order_id` bigint COMMENT '关联销售订单', `product_id` bigint NOT NULL COMMENT '产品ID', `plan_quantity` decimal(15,2) NOT NULL COMMENT '计划生产数量(长度:米)', `completed_quantity` decimal(15,2) DEFAULT 0 COMMENT '已完成数量', `status` varchar(20) DEFAULT 'NEW' COMMENT '状态: NEW, RELEASED, IN_PROGRESS, COMPLETED, CLOSED', `plan_start_time` datetime COMMENT '计划开始时间', `plan_end_time` datetime COMMENT '计划完成时间', -- ... 其他字段 ); -- 工单工序明细表 (关联工艺路线) CREATE TABLE `order_process` ( `id` bigint PRIMARY KEY, `production_order_id` bigint NOT NULL, `process_code` varchar(50) NOT NULL COMMENT '工序编码', `process_name` varchar(100) COMMENT '工序名称', `sequence` int COMMENT '工序顺序', `planned_quantity` decimal(15,2) COMMENT '本工序计划数量', `completed_quantity` decimal(15,2) DEFAULT 0 COMMENT '本工序完成数量', `status` varchar(20) DEFAULT 'PENDING' COMMENT '状态: PENDING, WORKING, FINISHED', `work_center_id` bigint COMMENT '工作中心/设备', FOREIGN KEY (`production_order_id`) REFERENCES `production_order`(`id`) ); -- 报工记录表 CREATE TABLE `work_report` ( `id` bigint PRIMARY KEY, `order_process_id` bigint NOT NULL COMMENT '对应工单工序', `report_no` varchar(50) COMMENT '报工单号', `report_length` decimal(15,2) NOT NULL COMMENT '报工长度(米)', `qualified_length` decimal(15,2) COMMENT '合格长度', `waste_length` decimal(15,2) COMMENT '废料长度', `report_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '报工时间', `operator_id` bigint COMMENT '操作员', `equipment_id` bigint COMMENT '设备', FOREIGN KEY (`order_process_id`) REFERENCES `order_process`(`id`) );

关键逻辑：工人报工时，系统需要执行一个事务操作：1. 插入work_report记录；2. 更新order_process表的completed_quantity；3. 更新production_order表的completed_quantity。必须保证这三步的原子性，否则会导致进度数据不一致。这通常在WorkReportService的submitReport方法中用@Transactional注解实现。

4.3 库存与追溯相关表

-- 库存批次表（原料/半成品/成品通用） CREATE TABLE `inventory_lot` ( `id` bigint PRIMARY KEY, `product_id` bigint NOT NULL, `lot_number` varchar(100) NOT NULL COMMENT '批次号', `quantity` decimal(15,4) NOT NULL COMMENT '数量', `warehouse_id` bigint COMMENT '仓库', `location` varchar(100) COMMENT '货位', `production_date` date COMMENT '生产日期（针对成品）', `supplier_batch` varchar(100) COMMENT '供应商批次（针对原料）', -- ... 其他 ); -- 生产追溯表（核心） CREATE TABLE `production_trace` ( `id` bigint PRIMARY KEY, `finished_lot_id` bigint NOT NULL COMMENT '成品批次ID', `raw_material_lot_id` bigint NOT NULL COMMENT '原料批次ID', `consumed_quantity` decimal(15,4) COMMENT '消耗数量', `production_order_id` bigint COMMENT '关联生产工单', `process_step` varchar(50) COMMENT '消耗发生的工序', `trace_time` datetime DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (`finished_lot_id`) REFERENCES `inventory_lot`(`id`), FOREIGN KEY (`raw_material_lot_id`) REFERENCES `inventory_lot`(`id`) );

追溯实现：production_trace表记录了物料消耗的流向。当原料出库用于生产时，系统会记录一条追溯信息，将原料批次与即将产生的半成品/成品关联起来。这种“批次套批次”的关系，通过递归查询，就能实现完整的正反向追溯链。

5. 核心功能实现与代码导读

让我们深入到几个典型业务场景的代码实现中，看看SpringBoot如何支撑这些复杂的业务逻辑。

5.1 生产工单创建与MRP计算（Service层逻辑）

假设我们要实现一个根据销售订单创建生产工单的服务方法。这个过程涉及库存检查、BOM展开和物料预留。

@Service @Transactional public class ProductionOrderServiceImpl implements ProductionOrderService { @Autowired private SalesOrderMapper salesOrderMapper; @Autowired private ProductMapper productMapper; @Autowired private BomMapper bomMapper; @Autowired private InventoryMapper inventoryMapper; @Autowired private ProductionOrderMapper orderMapper; @Override public ProductionOrder createOrderFromSales(Long salesOrderId) { // 1. 获取销售订单详情 SalesOrder salesOrder = salesOrderMapper.selectById(salesOrderId); if (salesOrder == null) { throw new BusinessException("销售订单不存在"); } // 2. 获取产品信息及BOM Product product = productMapper.selectById(salesOrder.getProductId()); Bom bom = bomMapper.selectLatestByProductId(product.getId()); if (bom == null) { throw new BusinessException("产品[" + product.getProductCode() + "]未定义BOM"); } // 3. 展开BOM，计算物料需求 (简化版，实际更复杂) List<MaterialRequirement> requirements = calculateMaterialRequirements(bom, salesOrder.getOrderQuantity()); // 4. 检查库存可用性 for (MaterialRequirement req : requirements) { BigDecimal availableStock = inventoryMapper.selectAvailableStock(req.getMaterialId()); if (availableStock.compareTo(req.getRequiredQuantity()) < 0) { // 库存不足，可以触发采购申请或提示 throw new BusinessException("物料[" + req.getMaterialCode() + "]库存不足，需求:" + req.getRequiredQuantity() + ", 可用:" + availableStock); } } // 5. 锁定库存（预留） for (MaterialRequirement req : requirements) { inventoryMapper.reserveStock(req.getMaterialId(), req.getRequiredQuantity(), salesOrderId); } // 6. 创建生产工单 ProductionOrder newOrder = new ProductionOrder(); newOrder.setOrderNo(generateOrderNo()); // 生成唯一工单号 newOrder.setSalesOrderId(salesOrderId); newOrder.setProductId(product.getId()); newOrder.setPlanQuantity(salesOrder.getOrderQuantity()); newOrder.setStatus(OrderStatus.NEW); // ... 设置其他字段 orderMapper.insert(newOrder); // 7. 根据工艺路线，生成工单工序明细 List<ProcessRoute> routes = processRouteMapper.selectByProductId(product.getId()); for (ProcessRoute route : routes) { OrderProcess orderProcess = new OrderProcess(); orderProcess.setProductionOrderId(newOrder.getId()); orderProcess.setProcessCode(route.getProcessCode()); // ... 复制其他信息 orderProcessMapper.insert(orderProcess); } return newOrder; } private List<MaterialRequirement> calculateMaterialRequirements(Bom bom, BigDecimal orderQuantity) { // 递归或循环展开BOM，考虑父子件关系和用量公式 // 这里是业务核心算法，需要根据BOM明细中的用量、单位、损耗率进行计算 // 例如：子件需求 = 父件计划数量 * 子件单件用量 * (1 + 损耗率) List<MaterialRequirement> result = new ArrayList<>(); // ... 具体计算逻辑 return result; } }

实操心得：calculateMaterialRequirements方法是MRP的核心，也是性能瓶颈。对于BOM层级深、产品种类多的企业，需要优化算法，考虑使用缓存（如Redis）存储已计算的BOM展开结果，或者采用异步计算的方式。同时，库存检查和预留必须在同一个事务中，否则在高并发下会出现“超卖”问题。

5.2 车间报工与进度更新（Controller与Service协作）

前端提交报工数据后，后端如何处理？

@RestController @RequestMapping("/api/work-report") public class WorkReportController { @Autowired private WorkReportService workReportService; @PostMapping("/submit") public ApiResponse submitWorkReport(@RequestBody @Valid WorkReportSubmitDTO dto) { // DTO中包含：工单工序ID、报工长度、操作员、设备、合格长度等 try { WorkReport report = workReportService.submitReport(dto); return ApiResponse.success("报工成功", report); } catch (BusinessException e) { return ApiResponse.fail(e.getMessage()); } } } @Service public class WorkReportServiceImpl implements WorkReportService { @Transactional(rollbackFor = Exception.class) // 关键：开启事务 @Override public WorkReport submitReport(WorkReportSubmitDTO dto) { // 1. 校验数据：报工长度不能超过未完成数量等 OrderProcess process = orderProcessMapper.selectById(dto.getOrderProcessId()); BigDecimal remaining = process.getPlannedQuantity().subtract(process.getCompletedQuantity()); if (dto.getReportLength().compareTo(remaining) > 0) { throw new BusinessException("报工长度[" + dto.getReportLength() + "]超过工序剩余量[" + remaining + "]"); } // 2. 创建报工记录 WorkReport report = new WorkReport(); BeanUtils.copyProperties(dto, report); report.setReportTime(new Date()); workReportMapper.insert(report); // 3. 更新工序完成量 process.setCompletedQuantity(process.getCompletedQuantity().add(dto.getQualifiedLength())); // 通常用合格长度更新进度 if (process.getCompletedQuantity().compareTo(process.getPlannedQuantity()) >= 0) { process.setStatus(ProcessStatus.FINISHED); } else { process.setStatus(ProcessStatus.WORKING); } orderProcessMapper.updateById(process); // 4. 更新工单总完成量（这里可以异步或通过触发器实现，避免频繁更新大表） productionOrderMapper.updateCompletedQuantity(process.getProductionOrderId(), dto.getQualifiedLength()); // 5. 生成质量检验待办任务（如果该工序有质检点） if (process.hasQualityCheckpoint()) { qualityTaskService.createInspectionTask(process, report); } // 6. 记录物料消耗（从库存中扣减） materialConsumptionService.recordConsumption(process, dto.getReportLength()); return report; } }

注意事项：报工是一个典型的长事务，涉及多张表的更新。必须使用@Transactional确保一致性。同时，第4步“更新工单总完成量”在高频报工场景下可能成为性能热点。一种优化策略是：在工单表上设置一个last_updated_time字段，总完成量通过定时任务汇总其下所有工序的完成量来更新，或者使用Redis累加再异步持久化。

5.3 全流程追溯查询实现

当需要查询一盘成品电缆（批次号：FINISHED-LOT-001）的完整生产履历时，如何实现？

@Service public class TraceServiceImpl implements TraceService { @Override public ProductTraceVO getFullTraceByLot(String finishedLotNumber) { ProductTraceVO traceVO = new ProductTraceVO(); // 1. 获取成品批次信息 InventoryLot finishedLot = inventoryLotMapper.selectByLotNumber(finishedLotNumber); traceVO.setFinishedProduct(finishedLot); // 2. 递归查询原料消耗记录，构建追溯树 List<TraceNode> materialTree = buildMaterialTraceTree(finishedLot.getId()); traceVO.setMaterialTraceTree(materialTree); // 3. 查询生产过程记录（报工、质检） List<WorkReport> productionRecords = workReportMapper.selectByFinishedLot(finishedLot.getId()); List<QualityInspection> qualityRecords = qualityInspectionMapper.selectByFinishedLot(finishedLot.getId()); traceVO.setProductionRecords(productionRecords); traceVO.setQualityRecords(qualityRecords); return traceVO; } private List<TraceNode> buildMaterialTraceTree(Long currentLotId) { List<TraceNode> nodes = new ArrayList<>(); // 查询当前批次消耗了哪些原料批次 List<ProductionTrace> traces = productionTraceMapper.selectByFinishedLotId(currentLotId); for (ProductionTrace trace : traces) { TraceNode node = new TraceNode(); InventoryLot materialLot = inventoryLotMapper.selectById(trace.getRawMaterialLotId()); node.setMaterialLot(materialLot); node.setConsumedQuantity(trace.getConsumedQuantity()); // 递归：如果该原料本身也是半成品（由更基础的原料制成），则继续追溯 if (materialLot.getType().equals("SEMI_FINISHED")) { node.setChildren(buildMaterialTraceTree(materialLot.getId())); } nodes.add(node); } return nodes; } }

这个递归查询清晰地展示了“批次套批次”的追溯模型。在实际应用中，如果BOM层级很深，递归查询可能导致性能问题。可以考虑在production_trace表中增加root_finished_lot_id和trace_path字段，通过一次查询获取所有层级的追溯关系，或者使用图数据库来存储这类关系数据。

6. 项目部署、配置与二次开发指南

6.1 环境准备与初始化

基础环境：确保安装JDK 8或11、Maven 3.6+、MySQL 5.7+。根据热词提示，注意Java环境变量配置（JAVA_HOME,PATH）。
数据库初始化：运行源码包中/sql目录下的数据库脚本，创建表结构和初始化基础数据（如用户、部门、产品类别等）。

配置文件修改：打开src/main/resources/application.yml，修改数据库连接信息、服务器端口等。

spring: datasource: url: jdbc:mysql://localhost:3306/cable_prod_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: yourpassword servlet: multipart: max-file-size: 100MB # 处理大文件上传，如设计图纸 max-request-size: 100MB server: port: 8080

启动项目：在IDE中直接运行主启动类（通常名为Application或CableProductionApplication），或使用命令mvn spring-boot:run。

6.2 常见配置问题与解决

端口冲突：如果8080端口被占用，在application.yml中修改server.port。
数据库连接失败：检查MySQL服务是否启动，用户名密码是否正确，以及数据库名是否对应。注意MySQL的lower_case_table_names配置，如果脚本中表名是大写的，而MySQL配置为忽略大小写，可能导致问题。
时区问题：确保数据库连接URL中设置了serverTimezone=Asia/Shanghai，避免时间差。
文件上传大小限制：如上配置所示，如果需要上传较大的文件，需要调整spring.servlet.multipart的相关参数。

6.3 二次开发扩展建议

这个毕业设计源码提供了一个坚实的核心框架，但要用于真实生产环境，通常需要在以下方面进行增强：

权限系统强化：源码自带的权限控制可能比较简单（如基于角色的访问控制RBAC）。需要细化到数据权限和操作权限。例如，A车间的主任只能看到和操作A车间的工单。可以集成Spring Security或Shiro，并设计更复杂的用户-角色-权限-数据范围模型。
报表与数据分析：增加丰富的统计报表，如“生产效率分析（OEE）”、“质量合格率趋势图”、“物料消耗成本分析”。可以集成报表工具（如JasperReports、EasyExcel）或BI工具。
移动端支持：车间工人更习惯用手机或PDA扫码报工。可以开发一套简单的H5移动端页面，或集成企业微信/钉钉的工作台。
接口集成：与金蝶/用友等财务系统对接（传递成本、应收应付数据），与SRM系统对接（传递采购需求），或与设备PLC接口（自动采集产量、停机时间）。
性能优化：
- 数据库层面：为频繁查询的字段（如order_no,status,product_code）添加索引。对大数据量表（如报工记录、追溯记录）进行分库分表或历史数据归档。
- 应用层面：使用Redis缓存热点数据（如产品信息、BOM结构）。对复杂的MRP计算、报表生成采用异步任务（如Spring的@Async或集成消息队列）。
- 前端层面：如果前端是单页面应用（SPA），注意路由懒加载、组件按需加载、大数据列表的虚拟滚动。

6.4 从开发到生产部署

开发完成后，需要打包部署到生产服务器（通常是Linux系统）。

打包：使用Maven命令mvn clean package -DskipTests生成可执行的JAR文件（位于target目录下）。
传输：将JAR包和外部配置文件（如application-prod.yml）上传到服务器。
运行：在服务器上使用nohup java -jar your-project.jar --spring.profiles.active=prod > app.log 2>&1 &命令后台启动应用。这里--spring.profiles.active=prod指定使用生产环境的配置文件。
进程守护：建议使用systemd或supervisor来管理SpringBoot进程，实现开机自启、自动重启。
日志管理：配置Logback或Log4j2，将日志按级别和日期滚动输出到文件，便于问题排查。生产环境务必关闭Swagger等调试接口。

踩坑实录：有一次在部署后，系统运行几天后突然变慢。排查发现是Nginx代理配置中没有设置合理的超时时间，导致一些长时间运行的报表查询请求被中断，连接没有正确释放，最终拖垮了Tomcat线程池。后来在Nginx配置中增加了proxy_read_timeout 300s;并对慢查询接口做了异步化改造。所以，上线前的压力测试和运行时的监控（如使用Spring Boot Actuator或Prometheus）非常重要。

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