企业官网建设流程全解析

简介：本资源是一套完整的基于SSM框架（Spring + SpringMVC + MyBatis）开发的生产管理系统毕业设计项目，面向计算机专业本科生及Java初学者，解决企业级生产管理场景下的订单跟踪、物料调度、工单分配与数据统计等核心业务需求，适合作为课程设计、期末大作业或毕业设计参考。压缩包共822个文件，涵盖127个Java后端逻辑类、156个JavaScript前端交互脚本、48个Vue组件、46个HTML页面、46个CSS样式文件、32个PNG/JPG图标资源、22个XML配置文件及2个SQL建库脚本（含db.sql），完整呈现前后端分离架构与SSM整合实践；包体大小为14.37MB。资源附带详尽的说明文档.txt，系统阐述架构设计、模块划分、事务管理实现及常见问题解决方案，并包含多个.bat部署脚本与备份文件，便于快速本地运行与二次开发。 做了几年Java后端，经手了不少传统企业的管理系统，去年帮一家做机械零部件加工的工厂搭了一套生产管理系统，技术栈选了很经典的SSM——Spring + SpringMVC + MyBatis。说实话，现在很多人一听到SSM就觉得是老古董，但真到了生产制造这类企业内部系统里，SSM的存量市场和实用价值依然很大。这篇文章就把这个“基于SSM的生产管理系统”从设计思路、数据库建模、核心实现到Vue3联调的完整过程拆开讲清楚，重点说说哪些地方容易踩坑，以及为什么这么选。

这套系统要解决的核心问题，是工厂里最让人头疼的几件事：销售订单来了怎么排产、车间领料怎么控制、生产进度怎么跟踪、库存账怎么做到和实物一致、出了质量问题怎么追溯。很多小工厂还在用Excel管这些事，单子一多、工序一复杂，账就对不上了。SSM这套组合正好适合这种业务逻辑复杂、流程相对固定、又需要强数据管控的场景。

1. 项目整体设计与技术选型

1.1 为什么生产管理系统还在用SSM

先说一个很多人会问的问题：既然Spring Boot这么方便，为什么还要选SSM？这里头有几个非常现实的原因。

第一是存量系统兼容。很多中型制造企业现有的MES、ERP、WMS老系统就是SSM架构，新上的生产管理系统要和老系统做数据对接，比如同步物料主数据、回传生产报工结果。如果新系统用Spring Boot，虽然也能对接，但老团队维护起来要同时维护两套技术栈，成本立刻翻倍。SSM框架在企业内部的存量太庞大了，搞了这么多年，积累的业务代码和运维经验都在上面。

第二是部署环境限制。工厂的服务器环境普遍比较保守，很多客户明确要求部署到已有的Tomcat容器里，甚至还要兼容WebLogic。Spring Boot内嵌Tomcat的jar包方式虽然省事，但碰上这种环境反而别扭。SSM打成war包往容器里一扔，规矩又稳妥，麻烦最少。

第三是团队技术栈匹配。工厂的信息科或者外包维护团队，很多人干了七八年SSM，你说Spring Boot自动配置多爽，他觉得那是黑盒，出了问题不知道从哪排查。SSM这种显式配置反而让他们心里有底——每个Bean怎么装配、每个SQL写在哪，一眼就能看明白。

所以，抛开“新项目必须用新框架”的惯性思维，SSM在生产管理系统这个领域根本不是退路，而是务实的选择。技术选型这件事，业务场景和团队能力比框架的新旧重要得多。

1.2 SSM三件套的职责划分

SSM是三个框架的组合，分别管不同层面的事。我习惯用一个生活化的类比来解释它们的分工：Spring是公司HR，统一管理所有员工（Bean）的创建、装配和生命周期；SpringMVC是前台，负责接待客户请求，把每一单派给对应的部门处理；MyBatis是仓库管理员，你有什么需求必须写清楚单子（SQL），他照单去数据库取货。

用这套系统里的实际操作来说：用户在前端点了一个“查询生产订单”，请求先被SpringMVC的DispatcherServlet截住，然后根据URL映射找到对应的Controller；Controller调Service层，Service里通过Spring注入的Mapper接口，最终让MyBatis去执行那条动态拼出来的SQL。三层各司其职，链路上的每一步都清晰可控。

很多人刚接触SSM时容易搞混分层职责，把业务逻辑写在Controller里，把SQL拼在Service里，最后代码烂成一锅粥。这套架构之所以经典，就是因为它用硬性的分层规范逼着你把代码条理化。生产管理系统业务复杂，订单、排产、领料、质检、库存环环相扣，分层不清的话，后面加需求改Bug全是灾难。

1.3 SSM项目的基本目录结构

一个规范的SSM项目，目录结构从第一行代码开始就要立好规矩。我这边习惯按功能包划分，而不是按技术类型划分。所谓按功能包划分，就是先建controller、service、mapper这些横向层次，但controller里再按业务模块分子包，比如controller/order、controller/inventory、controller/quality，这样代码多了以后不会全都堆在一个包下面找不到。

实际项目中我还会加一个common包放统一返回结果、异常处理、分页对象，一个config包放配置类。生产管理系统里涉及大量的参数配置和字典项，专门放一个constant或enums包管理状态枚举和业务常量，比如订单状态、质检结果类型这些。这类代码看起来不起眼，但到后面排Bug、做统计报表的时候你就知道有多省事了。

2. 核心业务模块设计与数据库建模

2.1 生产管理系统必须覆盖哪些业务

拿到需求后我习惯先把业务流程画一遍。工厂的核心流程绕不开这几步：销售订单进来，计划员根据订单交期和车间产能排产，生成生产计划单；生产计划单下发到车间，车间做领料；领料后进行工序加工，每道工序完工要报工；全部工序完成后流转到质检，质检合格做生产入库；同时，材料和半成品的库存账要实时更新。

听起来好像不复杂，但真正落地的时候，每一个环节都有大量细节。比如排产时要不要考虑设备负荷？领料是按订单领还是按批次领？报工是个人报还是班组报？质检不合格是返工还是报废？这些业务规则都需要在数据库层面设计好对应的表和状态字段，否则开发到一半就会发现数据模型撑不住业务。

我在这个项目里把模块拆成：基础资料（物料、BOM、工艺路线）、销售订单管理、生产计划与排产、车间领料与报工、质量检验、库存管理、报表统计，一共七大块。每一块都做成独立的模块，模块之间通过单号关联。这个单号关联非常重要，是后面做生产追溯的线索。

2.2 核心数据表设计要点

数据库设计是生产管理系统最见功力的一环。我挑几张核心表展开讲讲设计思路。

物料表是所有业务的地基。物料编码必须全局唯一，建议用纯数字或字母数字组合，不要用中文。字段要有物料名称、规格型号、计量单位、默认仓库、安全库存、是否启用。特别注意加一个状态字段，物料停用后旧订单还是要能查询到历史信息，所以不能物理删除，只能做停用标记。

BOM表是生产系统的灵魂。BOM记录一个成品由哪些原材料或半成品组成、各需要多少用量。我设计的时候加了版本号字段，因为BOM变更非常频繁，客户今天说换个螺丝规格，明天说要加一道工序。加了版本号之后，历史订单可以从生产订单表里反查出当时使用的是哪个版本的BOM，实现产品档案的完整追溯。BOM表还需要有损耗率字段，比如10%的损耗率意味着生产100个成品需要准备110个物料。

生产订单表是贯穿全流程的主线。核心字段包括订单号、物料编码、计划数量、已完成数量、计划开始日期、计划结束日期、状态。状态字段建议用整型枚举而不是字符串，比如0=创建，1=已下发，2=生产中，3=已完成，4=已取消。整个系统的业务操作，说白了都是在驱动这张表的订单状态按规则流转。状态机设计得好，业务流程就顺；设计得不好，业务根本跑不通。

库存交易流水表是容易被忽略但极其重要的一张表。很多新手设计库存系统只关注当前库存数量，但生产管理系统的审计要求是每一笔库存变动都必须有迹可循。我这边要求所有库存变化必须写流水表，字段包括流水号、物料编码、变动类型（采购入库、生产入库、领料出库、盘点调整等）、变动数量、变动前库存、变动后库存、关联单号、操作人、操作时间。有这张表在，库存对不上账的时候才能回溯到具体是哪一张单据出了问题。

2.3 数据库设计的三条军规

第一，状态机驱动，禁止随意改数据。业务数据的状态变化只能通过规定的接口和操作触发，比如订单从“已下发”变成“生产中”必须经过“开工”操作，不能直接UPDATE数据库改状态。否则系统跑半年之后，数据乱到没法看。

第二，流水必留痕。上面说的库存流水表是底线，生产报工记录、质检记录也一样。所有核心业务操作必须有操作人和时间戳。生产管理系统遇到质量事故查追溯的时候，没有流水数据根本说不清楚。

第三，版本化保存历史。BOM版本、工艺路线版本、订单变更记录都需要版本化。生产制造行业对历史追溯的要求很高，版本化不只是为了避免并发冲突，更是为了回答“某个时刻这台设备做的这批货到底用的什么标准”这种审计问题。

3. 关键技术实现与核心代码分析

3.1 SpringMVC请求流转与接口设计规范

生产管理系统的接口设计，我坚持RESTful风格，用HTTP方法表达操作语义。查询用GET，新增用POST，修改用PUT，删除用DELETE。URL里用名词复数，比如/api/orders、/api/materials，资源的层级关系用路径表达，比如GET /api/orders/{orderId}/items表示查询某个订单的明细。

SpringMVC的请求流转可以简单理解为：请求到达DispatcherServlet，通过HandlerMapping找到对应的Controller方法，方法执行前经过拦截器（登录校验、参数校验），方法里注入参数并返回结果，结果通过HttpMessageConverter转成JSON响应给前端。我用@RestController替代@Controller加@ResponseBody的组合，这样每个方法返回的对象都会自动序列化为JSON，省去一堆重复代码。

生产管理系统的接口需要统一返回结构，我定义了Result类，包含code、message、data三个字段。code为200表示成功，401表示未登录，500表示服务器异常。这样的好处是前端Axios可以在响应拦截器里统一处理错误码，而不是每个接口单独判断。分页查询统一返回PageResult对象，包含total、pages、records三个字段，前端拿到直接渲染表格和分页器。

3.2 MyBatis动态SQL是查询灵活的关键

生产管理系统的查询条件非常复杂，物料编码、订单号、状态、日期范围、车间，用户可能任意组合查询。这些查询条件如果写死SQL，得写几十个方法。MyBatis的动态SQL完美解决了这个问题。

我用<where>配合<if>标签动态拼接条件。比如查询生产订单，用户可能输入了订单号但没有输状态，那SQL就只拼订单号条件；用户可能只选了日期范围，那SQL就只拼日期条件。动态SQL就是解决这种“条件不确定”的场景。实际使用的时候有几个细节：

第一，<where>标签会自动去掉第一个多余的AND，但如果条件写在<where>外面就要自己处理。第二，时间范围查询时建议用>=和<配合次日零点，避免用BETWEEN导致边界数据丢一天。第三，模糊查询的LIKE CONCAT('%', #{keyword}, '%')写在MyBatis里，不要在前端自己拼好再传过来，否则有SQL注入风险。

MyBatis的另一个优势是支持自定义SQL，因为生产管理系统的报表统计SQL往往很复杂，关联五六张表、用CASE WHEN做条件统计，这些在MyBatis里写起来很顺手，可读性强，也方便DBA审核。相比JPA这类全自动ORM，MyBatis这种半自动方案在复杂业务场景下反而效率更高，因为SQL的执行路径完全可控。

3.3 事务管理在生产入库和领料出库中的应用

生产管理系统里事务是最不能出问题的环节。举一个典型场景：生产报工完成后，系统要做三件事——更新生产订单的完成数量、增加产成品库存、扣减原材料库存，这三步必须在一个事务里，任何一步失败都要回滚，否则库存账和订单数据就对不上。

Spring的@Transactional注解可以声明式管理事务。我习惯在Service层的业务方法上加这个注解，而不是在Controller层。因为事务的粒度应该和业务用例保持一致，一个业务用例对应一个事务边界。加注解的时候还要注意事务的传播行为，默认的REQUIRED就够了，不需要特殊配置。

有一个需要特别小心的点：@Transactional注解默认只在运行时异常时回滚，如果方法里catch住了异常但没有抛出，事务不会回滚，数据就悄悄错了。我见过不少线上事故就是这种“异常被吞”导致的。经验是业务方法里尽量不要catch异常，让异常向上抛到统一异常处理器处理，这样事务回滚才有保障。

3.4 并发控制：防止超领和库存超卖

生产管理系统是多人同时在用的系统，车间工人报工、仓库管员发料、计划员排产，同时操作同一份数据的情况很常见。并发控制设计不好，就会出大问题。最典型的是超领：库存只剩100件原材料，两个工单同时要领80件，如果两边同时读到库存100，都判断可以领，最终就会发出去160件，负数都出来了。

我在这个项目里的解决方案是乐观锁加数据库唯一约束双保险。具体操作是在库存表加一个version字段，执行扣减库存的UPDATE语句时，带上WHERE version = #{oldVersion}条件，MyBatis更新后检查受影响行数，如果为0说明数据被别人改过了，就提示用户刷新重试。这种方式不加数据库锁，性能开销小，适合生产管理系统这种冲突不频繁但必须防止超卖的场景。

还有一个容易忽略的点是生成单号。生产订单号、领料单号这类业务单号，如果直接用数据库自增主键，业务人员看了一头雾水。我在这套系统里实现了单号生成器，规则是前缀加日期加流水号，比如PD20250601001。单号生成用数据库表加行锁来实现，避免并发时生成重复单号。这个细节直接决定了系统上线后单据有没有可读性。

4. Vue3与SSM的前后端联调

4.1 前后端分离架构与工程目录规划

传统SSM项目常直接用JSP做页面，但新项目我强烈建议用前后端分离。前端用Vue3 + Vite + Element Plus，后端只出JSON接口，两者通过HTTP通信。生产管理系统的界面交互复杂，表格、表单、弹窗、树形控件非常多，Vue3的组合式API写起来比JSP爽太多，维护成本也低。

前端工程的基本结构我按模块划分：src/api目录下按后端接口模块建文件，比如order.js、inventory.js、quality.js；src/views目录下按页面建文件夹；src/store用Pinia管登录状态和全局字典数据。一个核心原则是API请求统一封装，不要在组件里到处直接写axios调用。我封装了一个request.js，设置好baseURL、超时时间、请求拦截器和响应拦截器。

工程目录这个问题看着简单，实际很影响协作效率。前后端如果约定不好，后端接口改了前端不知道，前端传参少了后端报错，全在联调阶段浪费时间。我在这套系统里把接口文档也纳入规范流程，接口数据结构变了，前端同步更新，避免了“接口黑洞”问题。

4.2 Axios封装与开发环境代理配置

Vue3项目里用Axios发请求，第一件要做的事就是配置开发环境代理。因为前端开发服务器地址是http://localhost:5173，后端Tomcat地址是http://localhost:8080，直接发请求必然跨域。我在vite.config.js里配置了代理，所有以/api开头的请求转发到后端服务地址。

// vite.config.js export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } });

配置好代理之后，前端的baseURL直接写/api就够了，不需要写完整的后端地址。这样在开发环境、测试环境、生产环境可以保持前端代码一致，只在部署时通过Nginx做转发。生产环境我用的方案是Nginx把/api的请求location转发到后端Tomcat，前端只负责静态文件，避免了跨域问题。

Axios实例的封装我放在了src/utils/request.js里，请求拦截器里从Pinia或localStorage取token加到请求头，响应拦截器里统一处理code不为200的异常。生产管理系统的用户权限比较严格，所有接口都要校验登录状态，放拦截器里统一处理最稳妥。

// src/utils/request.js import axios from 'axios'; import { ElMessage } from 'element-plus'; const service = axios.create({ baseURL: '/api', timeout: 10000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers['Authorization'] = 'Bearer ' + token; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code !== 200) { ElMessage.error(res.message || '请求失败'); return Promise.reject(new Error(res.message)); } return res.data; }, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token'); window.location.href = '/login'; } ElMessage.error(error.message || '网络异常'); return Promise.reject(error); } ); export default service;

4.3 跨域处理方案对比

前后端分离联调时，跨域是绕不开的话题。我整理一下几种方案的实际选择：

后端全局CORS配置是我在生产环境里的首选。在后端加一个CorsFilter或配置类，允许指定来源的跨域请求。要注意的是allowedOriginPatterns不能用*通配符的同时又允许携带凭证，否则浏览器会拒绝。跨域配置的代码比较简单，关键是理解原理：浏览器会在发起非简单请求前发送OPTIONS预检请求，后端需要正确处理这个预检。

@CrossOrigin注解也能解决跨域，但缺点是只能加在单个Controller或方法上，系统里Controller多了就要到处加，非常散。我建议在少数特殊接口上才用注解方式，比如某些需要被第三方系统直接调用的开放接口。

Nginx转发是生产环境最省心的方案。后端不需要关心跨域问题，前端请求发到同源地址，Nginx通过location规则代理到后端服务。这样做还有一个好处是Nginx可以做反向代理负载均衡，后面后端服务多开几台就能无缝扩展。

4.4 前端调用SSM接口的实战细节

Vue3连接SSM框架的接口调用，有几点必须注意，否则联调阶段会被折磨到怀疑人生。

第一，后端接口的定义要和前端调用方式严格对应。GET请求用@RequestParam接收参数，前端Axios用params传参；POST请求用@RequestBody接收JSON，前端必须用data传对象。还有@PathVariable用于接收URL路径参数，这个在RESTful风格接口里用得最多。三种方式混用的时候一定要在接口文档里写清楚，否则前端大量时间都花在猜测参数怎么传上。

第二，时间格式统一用字符串。Java后端如果用Date类型直接返回给前端，序列化出来是一串时间戳或复杂格式，前端处理起来很痛苦。我在项目里统一用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")注解指定格式，或者干脆在DTO里用String类型接收和返回时间字段。生产管理系统的报表查询时间范围很常见，时间格式统一能让前端少写一大堆格式化代码。

第三，分页参数和后端PageHelper要配合好。前端传pageNum和pageSize，后端接参后传给PageHelper，查出来的数据封装成PageResult返回。这里有坑：PageHelper的分页是紧跟着第一条SQL生效的，如果你在分页查询前先执行了别的查询，分页就会错乱。我的经验是分页查询的Mapper方法里只写这一条查询SQL，不要在里面做其他查询操作。

第四，文件上传接口。生产管理系统里会有导入Excel物料清单、上传质检报告附件这类需求。前端用FormData格式上传，后端用MultipartFile接收，同时把其他业务参数一起传过来。这个场景下不能再要求后端接口用@RequestBody，因为FormData格式的数据后端要用@RequestParam接收。

5. 常见问题与排查技巧实录

5.1 中文乱码问题

SSM项目里中文乱码是高频问题，我在这套系统里也踩过。乱码一般分两类：一类是请求参数乱码，一类是响应数据乱码。

请求参数乱码的排查思路：确认Tomcat连接器的URI编码设置为UTF-8，确认后端写了CharacterEncodingFilter过滤器。Tomcat 8以上版本默认URI编码已经是UTF-8，但POST请求的body编码还得靠过滤器来保证。CharacterEncodingFilter要配置在web.xml的最前面，并且设置forceEncoding为true。

响应数据乱码相对少见，如果出现，排查SpringMVC的HttpMessageConverter编码，检查是否引入了fastjson或jackson并正确配置了UTF-8。还有一个隐蔽的坑是MySQL连接参数里的characterEncoding=utf8，如果数据库连接串没配这个，从数据库读出来的中文就是乱码，前端怎么改都白搭。

排查乱码的思路不要死记硬背，而是要沿着“请求进入容器—参数解析—数据库读写—响应返回”这条链路，逐步定位是在哪一环出了问题。最快的定位方法是分别在前端、Controller、数据库三个位置打印日志，看到底是哪一层就已经乱了。

5.2 事务不生效的三个典型场景

@Transactional注解不起作用，这类问题我见过太多次了。有三种场景最容易出事。

第一是同类内部调用。同一个Service类里的方法A调方法B，B上面加了@Transactional，实际上B是在this引用上直接调用的，没有经过Spring代理，事务注解完全没生效。解决方案是把B方法挪到另一个Service类里，或者通过AopContext.currentProxy()获取代理对象再调用。

第二是方法非public。Spring默认只用@Transactional管理public方法的事务，private、protected方法加了注解不会报错但也不生效。这个坑看代码不仔细根本发现不了。

第三是异常被catch吞掉。方法里catch住异常没重新抛出，事务判断逻辑看到的是“方法正常完成”，于是提交了事务，但实际业务执行到一半失败了。这个前面也提到过，生产管理系统里影响最恶劣的就是这种场景，库存扣了但订单没更新，数据就全乱了。

排查事务问题的时候，我习惯在applicationContext.xml或配置类里开启事务管理日志，把事务边界打印出来看。Spring的事务日志会明确指出哪个方法开始了事务、哪个方法提交了事务，对比看就知道哪个环节出了问题。

5.3 MyBatis属性映射和参数占位符误区

MyBatis里实体属性名和数据库字段名不一致，是新手最容易踩的坑。数据库习惯用下划线命名，比如order_no、created_time，Java实体习惯用驼峰命名，比如orderNo、createdTime。不配置的话，查询结果映射到Java对象时这些字段会全部为null。

解决方案有两种：一种是在mybatis-config.xml里开启驼峰映射mapUnderscoreToCamelCase=true，这种最省事；另一种是在resultMap里手动映射。我建议开启了驼峰映射之后，仍然为核心查询用resultMap显式定义映射关系，因为生产管理系统报表涉及大量关联查询，字段重名的情况很常见，显式映射更可控。

还有#{}和${}的区别必须搞清楚。#{}是预编译参数占位符，会生成?占位符再传值，不会有SQL注入风险；${}是字符串拼接，直接把值拼进SQL里。生产管理系统的排序字段和动态表名需要用到${}，但其他地方一律用#{}。涉及用户输入的内容用了${}，等于把数据库裸奔给攻击者了。

5.4 PageHelper分页插件使用时的坑

PageHelper是SSM项目最常用的分页插件，用起来简单但不注意细节会出各种诡异问题。

最大的坑是分页错乱。PageHelper的原理是拦截下一条SQL自动拼接LIMIT，如果你在PageHelper.startPage()和Mapper查询之间执行了其他SQL，分页就拼到了错误的SQL上。比如先查了一条日志再查列表，日志查询被分页了，列表反而没有分页。我的经验是startPage()和Mapper查询要紧紧挨着写，中间不要插入任何其他数据库操作。

第二个坑是嵌套查询分页不准。如果Mapper里的SQL包含子查询，PageHelper只对最外层SQL做分页，结果是分页对了但统计总数可能不对。生产管理系统的列表查询经常关联多张表，我建议复杂度高的查询不要依赖PageHelper自动count，而是手写count SQL，使用PageHelper的countSuffix参数指定自定义的count方法。

第三个坑是PageHelper和动态SQL结合时，如果SQL标签里有<if>条件导致SQL无法预编译，PageHelper的count语句也会出错。遇到这种情况，日志里会报SQL解析异常，排查思路是先把动态SQL生成的完整SQL打印出来，手动执行看看是否正常。

5.5 SQL慢查询与连接池参数调优

生产管理系统跑一段时间后，会积累大量历史数据。生产订单表、库存流水表这种核心业务表，半年就可能到几十万甚至上百万行。系统最容易出现的性能瓶颈就是SQL慢查询。

排查慢查询的第一步是开启MyBatis的SQL日志。在application.properties里配置mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl，控制台会把每条SQL的执行时间打印出来。然后针对执行时间超过200ms的SQL，用EXPLAIN看执行计划，重点检查是否走了索引。

生产管理系统的慢查询高发区我总结过：一是物料编码、订单号这类查询条件字段没建索引，二是订单明细表按订单状态做统计的聚合查询，三是库存流水表按物料编码和时间范围的大范围扫描。解决方式很简单，给核心查询条件加联合索引。比如库存流水表我建了(material_code, created_time)联合索引，查询效率提升非常明显。

连接池参数也要注意。我用的是Druid连接池，initialSize设为5，minIdle设为5，maxActive设为50。生产管理系统并发量不大，50个连接足够。但要注意maxWait设长一点，防止高并发瞬间打满连接池导致获取连接超时。Druid的监控页面也很方便，可以实时看SQL执行次数和耗时，上线初期我每天都会盯一遍。

6. 这套系统的后续扩展方向

如果这个项目要继续演进出更完善的版本，几个方向值得考虑。第一是引入规则引擎处理排产逻辑，把人工排产变成系统自动排产，根据交期、产能、物料齐套情况自动计算排产方案。第二是加入消息队列做异步处理，比如生产完工后推送消息给下游质检和仓库环节，减少用户等待时间。第三是增加移动端场景，现在车间工人普遍用手机，手机报工、手机领料能大幅提升现场效率。

但这些都是锦上添花的事。打牢地基才是核心。生产管理系统的复杂点从来不在框架本身，而在于业务流程梳理得是否清晰、数据模型建得是否合理、状态流转是否严密。框架只是工具，SSM这个工具足够成熟稳定，配合Vue3做前端，完全能撑起一套中型制造企业的生产管理需求。如果你现在正准备做类似的系统，建议集中精力把业务模型和数据处理流程想透彻，不要纠结于技术栈够不够新——能把复杂的制造业业务跑稳，就是好系统。

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