基于SpringBoot的光伏组件MES系统设计与追溯链路实现

1. 项目概述与核心价值1.1 光伏组件生产场景下的MES系统定位先聊一个很多计算机专业同学都有的困惑为什么偏偏选“光伏组件生产”这个场景来做MES系统毕业设计我见过太多同类项目要么做个泛泛的“生产管理系统”要么直接套用某个开源ERP模板做出来的东西既没有行业辨识度答辩时也讲不出深度。光伏组件生产其实是一个非常聪明的切入点因为它的工艺流程足够长、质量追溯要求足够高、数据采集点足够多正好能把MES系统最核心的“排产→执行→采集→质检→追溯”全链路跑通。光伏组件制造不是单机加工它的典型工艺流程是划片→串焊→层叠→层压→装框→固化→测试→包装每个工序之间是连续流转的而且每一块组件的身份信息比如组件条码、电池片批次、玻璃批次、EVA批次、背板批次必须伴随生产全程记录。这类需求放在MES系统里就自然衍生出几大核心模块工单管理、物料批次管理、工序流转与报工、设备数据采集、质量检验、产品追溯——恰好是MES的标准功能域。说白了这个选题的竞争力在于“行业纵深”而不是“技术炫技”。SpringBoot本身是主流Java后端框架用它的同学非常多但大部分人只是做了一个平平无奇的“增删改查系统”。如果把生产执行和追溯逻辑做扎实配合清晰的数据建模这个项目的技术含量和答辩说服力能明显高出一个档次。1.2 这套系统能解决什么实际问题站在光伏工厂生产管理的视角车间最头疼的问题通常是这几个纸质工单流转速度慢生产计划员排好的工单要打印、分发、回收工序之间交接全靠签名数据要隔天甚至隔周才能统计出来。物料批次追溯靠翻表格一旦成品组件出现功率衰减或者外观不良想找出用了哪一批电池片、哪一批EVA往往要在Excel和纸质记录里翻半天。设备状态不透明层压机、串焊机有没有故障、当前效率如何只能靠人工巡检。质量数据散落检测数据记录在纸质的测试报告中无法快速分析某个时段、某个机台的良率趋势。这套基于SpringBoot的光伏组件MES系统目标就是把“计划→生产→检验→追溯”这条链路上最关键的信息统一收口到一套系统里。对于毕设来说不需要覆盖MES的全部功能域但把上述这几条核心链路走通、走完整就已经是一个很有说服力的作品了。1.3 适合谁来参考这套设计如果你是计算机相关专业的毕业生正在为选题和开题发愁这个方向可以参考。这个设计的技术难度适中——SpringBoot MyBatis Plus MySQL这套组合是绝大多数高校Java方向课程里都有覆盖的业务模型又不至于像电商系统那样“烂大街”光伏制造背景天然带了一层专业属性。如果你的导师比较看重“业务闭环”和“工程实践”这套系统的“从工单下发到成品追溯的可验证数据链路”能很好地呼应这一点。甚至你可以把前端的部分简化用Vue或Thymeleaf都可以核心精力放在后端的数据建模和执行逻辑上——这一点很重要MES项目的灵魂在后端而不是前端。2. 技术选型与核心架构拆解2.1 为什么选SpringBoot而不是SSH或SpringCloud很多同学毕设选型时喜欢纠结我直接说结论单体SpringBoot完全够用没必要上微服务。光伏组件MES属于典型的工厂内部管理系统用户量级通常在几十到几百人之间核心诉求是数据准确性、业务闭环和追溯效率而不是高并发。SpringBoot在Java技术栈里生态成熟、资料丰富、部署简单对毕设来说能省掉大量环境折腾的时间。有一个很现实的原因是SpringBoot的自动配置和起步依赖能让你快速把Web层、持久层、参数校验、异常处理都串起来你可以把精力集中在业务逻辑上——而业务逻辑才是这个项目真正值得展示的地方。曾经有同学用SpringCloud Alibaba微服务做MES结果网关、注册中心、配置中心三个组件就把思绪搅成一团最终核心的追溯功能反而没做完整。这样的代价实在不值得。对比方案也很清晰技术方案优点缺点适配度本场景SpringBoot单体开发快、部署简单、调试方便不适合极大规模并发非常适合SpringCloud微服务扩展性强、模块隔离架构复杂、答辩易被追问深挖不适合毕设Django或FlaskPython语法友好团队或导师Java导向时不利视情况自研ServletJDBC底层理解更直接开发效率低、代码量大不推荐2.2 后端核心组件结构我建议按“模块化分包”的方式来组织项目结构不要把所有controller堆在一起。一个比较成熟的MES后端包结构如下com.pvmes ├── controller // 接口层工单、物料、工序、质检、追溯 ├── service // 业务逻辑层 │ ├── impl │ ├── workorder // 工单相关逻辑 │ ├── process // 工序流转逻辑 │ ├── quality // 质检逻辑 │ └── trace // 追溯逻辑 ├── mapper // MyBatis-Plus数据访问 ├── entity // 实体类 ├── dto // 入参出参对象 ├── vo // 视图对象 ├── config // 配置MybatisPlus、Swagger、跨域 ├── common // 统一返回、全局异常、枚举 └── utils // 工具类例如条码生成、时间处理这种结构下业务边界非常清楚。比如将来想在层压工序接入实时的温度参数采集直接在process包下面扩展对应的采集接口不会影响到质检和追溯模块。2.3 前端与交互层选型前端有两种走法各有利弊方案AThymeleaf服务端渲染。最大优势是写起来简单SpringBoot天然支持不用搞前后端分离适合开发时间紧张、以Java后端为主的同学。缺点是页面交互手感一般多工序数据看板类的视图会比较朴素。方案BVue Element UI / Element Plus前后端分离。效果更专业特别是做车间看板、追溯链展示这类页面时前端组件化优势非常明显。但需要处理跨域、Token、路由守卫这些额外工作。如果时间有限推荐方案B里面只做“单页面应用”把工单管理、工序报工、批次追溯三个核心页面做好比盲目铺很多粗糙页面更有说服力。答辩时演示一条“新建工单→PCBA投料→层压报工→质检完成→扫描组件码追溯全部批次”的流程展示效果远比十几个毫无亮点的页面好。3. 光伏组件生产业务模型与数据库设计3.1 核心业务对象梳理数据库设计是这个项目真正拉开差距的地方。光伏组件MES有别于普通进销存系统的地方在于——它需要同时建模**“工单-批次-序列号”**三层身份关系。先理一下实体关系生产工单来源于生产计划是工厂下达生产任务的依据规定了产品型号、数量、计划开工和完工时间。批次同一工单下按投入物料批次和生产时间划分的组。比如一个工单200块组件可能分4个批次各50块每批的电池片批次、玻璃批次可能不同。组件序列号每一块成品组件都有一个唯一的条码是追溯的最小单位。通常是“生产日期线别流水号”的组合编码。同时生产过程还涉及物料批次电池片批次、EVA批次、背板批次、玻璃批次、接线盒批次等属于受追溯管理的来料信息。工序流转记录每道工序划片、串焊、层叠、层压、装框、固化、测试的进出站时间、操作人、设备、工艺参数。质检记录外观检验、EL测试、功率测试等结果数据。搞清楚这个关系之后数据表到底怎么建心里就有底了。3.2 核心数据表字段设计下面我列几张最核心的表及其关键字段设计思路。这些表一旦设计好整个系统的骨架就稳定了。生产工单表work_order字段名类型说明idbigint主键work_order_novarchar(64)工单编号格式例如WO202506001product_modelvarchar(64)产品型号例如M10-550Wplan_qtyint计划数量actual_qtyint完成数量statustinyint0未开工、1生产中、2已完工、3已关闭plan_start_timedatetime计划开始时间plan_end_timedatetime计划结束时间created_byvarchar(32)创建人组件序列号表component_sn字段名类型说明idbigint主键sn_codevarchar(64)唯一序列号work_order_idbigint关联工单batch_idbigint关联批次statustinyint在制/成品/不良/报废current_processvarchar(32)当前工序created_timedatetime生成时间finished_timedatetime完工时间工序流转记录表process_record字段名类型说明idbigint主键component_sn_idbigint组件序列号IDprocess_codevarchar(32)工序编码LAYUP、LAMINATION等inbound_timedatetime进站时间outbound_timedatetime出站时间operatorvarchar(32)操作工device_codevarchar(32)设备编号statustinyint记录状态物料批次投料记录表material_input_record字段名类型说明idbigint主键work_order_idbigint关联工单batch_idbigint关联生产批次component_sn_idbigint关联组件如需组件级追溯material_typevarchar(32)物料类型电池片、EVA等material_batch_novarchar(64)物料批次号qtydecimal投入数量input_timedatetime投料时间质量检验记录表quality_inspection_record字段名类型说明idbigint主键component_sn_idbigint关联组件inspection_typevarchar(32)检验类型EL、外观、功率resulttinyint合格/不合格defect_codevarchar(64)不良代码inspectorvarchar(32)检验员remarkvarchar(255)备注inspection_timedatetime检验时间3.3 为什么需要批次与序列号两层追溯粒度有同学可能会问既然每块组件都有唯一序列号那物料批次直接挂在序列号上不就行了理论上是但实际工厂操作不这么做。光伏组件生产中电池片是整盒整托投入的操作工在串焊环节不可能逐一扫描每片电池片的条码事实上很多电池片来料只到批次级所以在每个工序阶段实际生产中是按“批次”记录投料而非按“单片/单块”记录。如果把粒度强行细化到每一块组件绑定每一片电池片数据采集的成本和错误率都会飙升。所以设计上要保存两条追溯粒度批次级追溯按生产批次记录电池片批次、EVA批次等信息满足大体量追溯场景。序列号级追溯对每一块成品组件记录其关键工序的流转明细。需要精确到单块时例如EL检测异常追该组件的全部工序履历可以直接定位。这样既尊重工厂实际作业习惯又能满足“正向从料追到成品、逆向从成品追到料”的追溯需求。设计完成后答辩时可以这样来表达系统支持批次级和序列号级两种粒度的追溯这种双轨设计的本质是用最合理的成本实现合规追溯。4. 核心业务流程与接口设计4.1 工单下发与生产的业务状态流转MES里最核心的一条路径就是“工单如何一步步走向完工”。我把它拆成了清晰的状态机计划员创建工单系统生成工单号状态“未开工”。仓库/车间根据工单进行领料/投料系统记录物料批次投入信息。此时工单状态变为“生产中”。生产班组按工序流转报工。每道工序完成后工序流转记录写入组件序列号的“当前工序”前推。质检人员对完工组件或工序中检组件进行检验检验结果写入质量记录。当工单下所有计划数量完成且质检合格工单状态置为“已完工”同时序列号置为“成品”。这套状态机在代码层面落实时应该放在Service层统一处理用枚举来定义状态保证非法状态跃迁直接报错。比如一个“已完工”的工单系统不应允许再新增投料记录。4.2 核心接口参数约定接口设计不需要做到“高端大气”但必须做到“语义清楚、可复用”。下面给几个核心接口的示例。创建工单POST /api/workorder/create 参数 { productModel: M10-550W, planQty: 200, planStartTime: 2025-06-10 08:00:00, planEndTime: 2025-06-12 20:00:00 } 响应 { code: 200, data: { workOrderNo: WO2025061001 } }工序报工POST /api/process/report 参数 { snCode: PV20250610010001, processCode: LAMINATION, operator: 张三, deviceCode: LAM-DEV-02 }这里报工接口背后真的不只是“insert一条记录”而是要校验该组件的当前工序是否等于传入工序的前置工序该组件是否处于“在制”状态设备编号是否存在操作人是否有该工序的操作权限。这套校验逻辑写下来业务严谨性立刻体现出来。组件条码追溯查询GET /api/trace/queryBySn?snCodePV20250610010001 响应中的追溯链路设计如下 { snCode: PV20250610010001, productModel: M10-550W, workOrderNo: WO2025061001, createdTime: 2025-06-10 09:23:15, processRecords: [...], materialRecords: [ {materialType: 电池片, materialBatchNo: CELL-20250512-B03, qty: 132}, {materialType: EVA, materialBatchNo: EVA-20250501-A01, qty: 1.8} ] }这个返回结构可以很自然地把“工单-工序-物料-质检”四大块信息全部串联起来也是答辩时最重要的演示数据。4.3 前端页面如何配合后端联动如果是做前后端分离核心页面建议优先做工单管理页工单列表 新建工单弹窗 工单详情抽屉关注工单下所有组件序列号的状态分布。生产报工页通过扫码枪或手动输入组件条码自动带出当前工序、工单号操作员点击“开始/结束”完成一道工序的进出站记录。追溯查询页输入组件序列号展示一条完整的生命周期时间线和对应物料批次信息。这些页面之间用路由关联配合刷新和多条件筛选列表已经能覆盖系统主要使用逻辑。扫码功能用普通输入框模拟即可答辩时可以准备一个扫码枪演示也可直接用键盘输入条码。4.4 批量操作与事务边界MES开发和普通管理系统开发还有一个明显不同——大量批量操作必须考虑事务边界。例如“工单报工批量完工”的接口如果100块组件依次更新状态中途有一块更新失败总不能前面99块成功、最后1块失败导致数据不一致。因此需要加事务控制Transactional(rollbackFor Exception.class) public void batchCompleteSn(ListString snCodes) { for (String snCode : snCodes) { componentSnService.completeSn(snCode); } }同时对于批量导入的投料记录一定要做“全有或全无”的校验。曾经出现过一种情况Excel导入的200条投料记录中有3条物料批次号在系统中不存在导入程序仍然把成功的数据提交了结果追溯时这3块组件查不到物料信息。最终的修复方案就是在入库前做整单批次校验有任何一条不合法全部拒绝导入并提示错误行位置。这是一个很小的点但能直接体现项目的工程严谨度。5. 历史追溯链路的设计与实现5.1 正向追溯与逆向追溯光伏行业的追溯需求一般有两条路正向追溯从“物料批次/来料批次”出发查出所有用到该批次的组件。比如某批EVA胶膜被厂家通报存在质量隐患工厂需要紧急锁定所有使用了该批次EVA的组件。逆向追溯从“成品组件条码”出发反查它用到的所有物料批次以及各工序的流转参数和质检情况。实现方法上正向追溯的核心是查物料投料记录表material_input_record根据material_batch_no关联到对应的组件SN或生产批次逆向追溯的核心是先查组件序列号再按节点关联工单、物料、质检、工序记录。5.2 追溯详情的时间线设计在实现追溯页面时不要简单堆列表最好按时间正序组装成“生命周期时间线”每个节点包含时间节点进站、出站、质检完成、入库。节点类型工序、质检、物料投入。关键数据操作人、设备、结果等。成品组件追溯时间线示例2025-06-10 08:30:00 投料电池片批次CELL-20250512-B032025-06-10 09:00:15 串焊进站2025-06-10 10:20:33 串焊出站2025-06-10 10:45:22 层叠进站2025-06-10 14:30:10 层压出站2025-06-10 16:05:47 EL检测合格2025-06-11 09:10:00 功率测试合格2025-06-11 10:00:00 成品入库这种时间线展示比普通字段罗列更能直观地说明系统的业务完整性。后期如果你想加亮点还可以输出一份PDF格式的追溯报告用模板引擎如Thymeleaf或开源的Itext来生成。5.3 条码生成与解析规则组件序列号的编码格式建议有业务含义不要直接拿UUID来用。一个合理的设计是PV 生产日期(YYYYMMDD) 车间线别(2位) 工单尾号(4位) 流水号(4位) 示例PV202506100102100001规则说明第1-2位产品标识PV。第3-12位日期字符直接可读。第13-14位车间产线编码。第15-18位工单号后四位用于快速定位工单归属。第19-22位当日该工单流水号从0001递增。在代码里可以封装一个专门的“条码生成策略类”来处理这也是答辩中很实用的亮点。还可以将条码关联规则写入Redis用于快速判断条码归属。6. 关键技术难点的工程化落地6.1 工序防错与状态校验工厂里经常有这样的场景一块组件还没经过层压结果被人误报了“装框完成”。MES必须从逻辑上切断这种操作。我在实现时会在service层统一封装一个“工艺路线校验器”里面定义出合法前置工序的关系MapString, String nextProcessMap new HashMap() {{ put(SCRIBING, STRING_WELDING); put(STRING_WELDING, LAYUP); put(LAYUP, LAMINATION); put(LAMINATION, FRAMING); put(FRAMING, CURING); put(CURING, TESTING); }};当报工传入下一道工序时先校验该序列号当前工序是否等于前驱工序如果不是直接抛业务异常“当前组件工序不匹配禁止流转到该工序”。这个校验逻辑是MES系统的“魂”——没有它系统只是记录工具有了它系统就能真正管控生产流程。6.2 工序耗时统计生产管理中非常关注各工序在制时长。实现时可以利用工序流转记录里的inbound_time和outbound_time在工序记录表中冗余两个计算字段duration_minutes。每次报工出站时用当前时间减去进站时间自动写入。这个字段看似简单但在后续的效率和瓶颈分析中极为重要。答辩时你可以直接展示“某工序平均耗时Top5”的简易统计报表用一条分组查询就能算出来SELECT process_code, AVG(TIMESTAMPDIFF(MINUTE, inbound_time, outbound_time)) AS avg_minutes FROM process_record WHERE inbound_time #{startTime} AND outbound_time #{endTime} GROUP BY process_code6.3 数据权限与操作留痕MES系统涉及车间、仓库、质检、计划等多角色操作最简单的数据权限设计是基于角色的菜单和数据范围控制。例如质检员只能看到质检相关页面车间班组长可以查看本班组的生产报工记录。同时对关键业务操作建议写一套简易“审计日志表”用Spring AOP在关键service方法上打日志注解记录“谁、在什么时间、对什么数据、做了什么操作”。这样既方便追溯也能体现你对生产管理系统合规性的理解。审计表可以这样设计字段名说明id主键user_name操作人operation操作类型business_type业务类型工单/物料/报工/质检business_no业务编号detail操作详情JSONcreate_time操作时间6.4 不良品处理流程实际生产中EL检测或功率测试的不良品不能简单把组件状态改为“不良”就结束了必须有处理动作。毕设中可以设计一个简单流程不良登记 → 异常绑定当前组件、当前工序、不良代码→ 处置返修/降级/报废→ 记录处置结果这个流程实现起来不复杂但对生产场景来说非常真实。答辩时如果面试官/老师问“组件生产中的质量异常怎么处理”你就不会被问住。7. 数据库索引与性能优化细节7.1 常用查询索引设计MES系统属于“数据写入频繁、查询条件固定”的应用。拿到一张表后第一件事就是根据业务查询条件去设计联合索引而不是等慢查询出现后再补救。以process_record表为例常用的查询场景有按组件SN查流转记录索引(component_sn_id)按时间范围查某工序的所有记录索引(process_code, inbound_time)按设备编号查历史状态索引(device_code, inbound_time)。以material_input_record表为例反向追溯的查询条件是“按物料批次号”所以material_batch_no要建索引如果还经常带时间过滤则建成(material_batch_no, input_time)联合索引。以work_order表和component_sn表为例工单下查询组件序列号列表是非常高频的路径关联字段必须用索引。7.2 避免N1查询MyBatis-Plus的开发方式很容易让人写出循环查询for (String snCode : snCodes) { ProcessRecord record processRecordMapper.selectOne(...); // 处理逻辑 }如果SN数量是几百几千这种写法会酿成严重的性能问题。正确的做法是批量查询后按SN做内存分组ListProcessRecord records processRecordMapper.selectBySnCodes(snCodes); MapString, ListProcessRecord groupMap records.stream() .collect(Collectors.groupingBy(ProcessRecord::getComponentSnCode));这个优化思路在系统演示中可能看不出来但代码review时一定是个加分项。7.3 操作大数据量导出时的取舍如果在毕设里做了数据导出功能比如导出某个工单的所有追溯明细数据量大的时候要避免一次性加载全表到内存。使用流式查询MyBatis-Plus的selectList配合每次分页1000条循环写文件是更稳妥的做法。如果是一次性几十几百条的小工单反而没必要刻意流式化——性能提升不明显代码复杂度还上升了。8. 测试与部署交付的工程细节8.1 接口测试不要只写“能跑就行”。建议给核心业务链路准备一套接口自测清单创建工单成功重复创建相同编号工单被拦截非法的工序流转被拦截投料记录中不存在的物料批次被拦截质检合格后组件状态更新正确追溯查询能返回完整时间线批量完工时部分SN不存在会整体回滚。这套清单可以直接用于答辩演示也可以说明你具备基本的工程测试意识。8.2 部署包结构部署上建议采用最稳妥的形态后端Maven项目打包成jar。前端如果是Vuenpm run build生成静态文件。简单部署方式用Nginx托管前端静态页面同时反向代理后端API。数据库提供sql初始化脚本包含表结构、初始化基础数据产线、设备、工序、用户。初始化数据也很重要。很多毕设系统打开后一片空白演示效果大大打折。建议预置1条进行中的工单和若干已完成工单若干组件SN并完成部分工序典型物料批次及质检数据3-5个测试账号分别对应不同角色。8.3 演示数据要“真”演示数据要尽量接近工厂真实情况。比如产品型号生成“M10-550W”“M12-660W”日期用近期的日期操作人员用“张工”“李工”这类称呼设备编号用“LAM-DEV-02”“STRING-WELD-01”。数据看起来越真实答辩时说服力越强。不用纠结“这些数据是不是真从工厂拿的”关键在于数据之间要符合业务逻辑能自洽地串联起来。9. 常见问题与避坑经验实录9.1 工单状态和组件状态不同步常见坑工单已完成但下面还有组件处于“在制”状态。解决办法在“工单完工”接口中增加联动校验遍历该工单下所有组件序列号检查是否全部为“成品”或“报废”状态否则阻止完工并明确提示剩余组件数量。可以用一个事务将整个校验和状态更新包住避免出现并发时被绕过。9.2 EL检测结果更新了组件状态但追溯时间线没显示常见坑组件状态更新了但“质检记录”表和“追溯时间线”之间没有打通。原因通常是前端查询追溯时直接从process_record取状态没有关联到质检记录的结果。解决办法在组件表上冗余一个“最新质检结果”字段或者每次质检后同步更新组件状态。如果不冗余查询追溯时也要JOIN质量检验记录去补充展示避免两边数据出现认知偏差。9.3 生产报工后组件“当前工序”更新错误这个坑出现概率极高。原因通常有三类报工接口没有做“前置工序”校验跳工序也报成功并发场景下多个报工请求同时更新同一件组件导致工序覆盖组件状态为“不良”或“报废”后仍被继续报工。解决办法数据库中给组件SN加“乐观锁”或“行锁”更新前检查状态和当前工序同时把“报废/不良组件禁止再报工”作为业务规则在service层统一校验。这个经验在面试和答辨中会是很有价值的细节亮点。9.4 追溯页面查询很慢原因通常是联动查询时多张表都做了全表扫描。解决办法先按核心表component_sn主键定位目标记录再根据索引分步带出关联表数据能用一条SQL Join的尽量Join避免应用层多次往返。9.5 使用逻辑删除带来的追溯隐患熟悉MyBatis-Plus的人习惯用TableLogic做逻辑删除这个功能很方便但用在生产执行系统里要非常谨慎。如果对工序记录、投料记录这种“操作流水”表做了逻辑删除追溯数据一旦被“删”实际上是查不到了因为MP查询时自动过滤了deleted1的数据除非额外写SQL no过滤会给追溯带来隐患。我的建议是工单、组件SN这类基础档案可以用逻辑删除工序流转记录、质检记录、物料投料记录、审计日志这些流水表一律不做删除功能只允许“作废”操作并留下作废人、作废原因。这个设计思路在实际工厂审查中是很有说服力的点。10. 从毕设到项目亮点表达的几点建议10.1 项目亮点怎么提炼答辩时最忌讳只说“我用了SpringBootMyBatisPlus做了个系统”。建议梳理出几个真正经得起追问的亮点工序防错机制从状态机和工序约束的角度管控生产流转而不是单纯记录数据。双粒度追溯批次级和序列号级两层追溯兼顾效率和精细化。数据一致性的处理思路在工单完工、批量报工等关键操作上使用事务和并发控制。贴合行业实际的边界取舍比如物料采集颗粒度从批次开始而不是盲目细化到单片级。10.2 延展方向如果学有余力还可以在前面基础上补充设备参数实时采集模拟通过定时任务模拟读取层压机温度曲线写入工序记录扩展字段。看板统计按产线、型号、工序维度统计当日产量、良率用ECharts展示。消息通知工单排队超时、设备空闲超时等异常事件提醒。这些方向任何一个做扎实都能让整个项目从“管理页面”升级为“生产执行支持系统”在答辩和简历上都更有说服力。10.3 最后的实操建议做这类系统最忌讳一上来就写代码。我的经验是先用两三天时间把数据表模型画出来把“组件从投料开始到入库为止的状态流转路径”在纸上完整模拟一遍再动手写代码。数据模型稳定以后SpringBoot的实现其实只是体力活。反过来如果一边写代码一边改表结构后面所有模块都会受到牵连返工成本非常高。另外建议全程用Git做版本管理每完成一个模块就提交一次。这样无论是回溯问题还是展示工作量都会从容很多。我用这个方式带的几个项目平均开发周期都在五到六周左右最终效果基本都能达到中等以上的水平。我个人在做类似项目时还有一个体会先把最小可用闭环跑通再逐步加功能这种方式在心态上是最舒服的。第一版只需要做到“创建工单→组件生成→报工两三个工序→质检→追溯查询”就已经是一个能看懂的业务系统了。后面的功能都是在这个骨架上长出来的一块块肌肉。这也是这个项目最值得参考的地方——它不需要你懂多高深的技术但它会逼着你把业务流程想清楚、把数据关系设计严密、把每一条操作链路走通。而这些恰恰是做一个有价值的MES系统最核心的能力。