做MES/ERP的人应该都体会过一种窒息感这类系统的业务复杂程度不输给任何互联网产品甚至更缠人。你面对的不是一个逻辑统一的页面而是一个接一个的俄罗斯套娃——生产工单套着工序明细工序明细套着设备工装报工记录又套着合格与返工返工单还要再关联原工单、不合格品记录、返工路径、质量复审。字段动辄几十上百个状态互相牵制不同车间、不同产品类型的页面还长得不一样。早年我处理这种需求的方式很笨页面里堆字段代码里堆 if/else一套代码适配所有工厂。结果就是每次来个新客户、新工艺都得在原有逻辑上打补丁代码越来越厚谁也不敢碰。后来我换了一套思路不再把工单详情返工单当成一个整体来做而是把业务拆成功能段落把段落做成独立组件再按不同的业务结构去组装。这套复杂多结构组件的做法让后面几个项目的交付速度快了不少也终于让我敢去动老代码了。这篇就展开聊聊这套方法的设计思路、落地步骤和我踩过的坑适合正在做MES/ERP产品、或者天天被工厂复杂业务折磨的同学参考。1. 先把复杂多结构组件这个词拆开说透这个概念听起来有点拗口但如果把它拆成业务功能段落多结构组件三个部分很多问题就清楚了。1.1 业务功能段落一个容易被低估的概念我做组件化改造时第一件事就是重新审视需求文档里的页面两个字。一个标准的工单详情页其实可以拆成好几个语义独立的段落基本信息段、物料清单段、工艺路线段、执行记录段、质量记录段、返工返修段、附件段。每个段落回答一个独立业务问题——这批物料够不够、这道工序走了没有、这个批次合不合格。段落之间虽然有业务上的先后和依赖但各自内部是高内聚的。关键是段落与页面有着本质区别。页面是个壳段落才是真正会变化和复用的东西。很多团队做需求评审、排期、开发仍然以页面为单位结果一个页面只要有一个新需求整个模块都要动而以段落为单位之后需求变更可以被限制在局部客户说成本分摊这块要改那就只动成本分摊组件其他段落一概不碰。这一点是整套方法论的起点所以我把它放在第一位。理解了段落后面的组件划分才有依据。页面是壳段落是核。MES/ERP里的需求变更大部分是段落级别的变更而不是页面级别的变更。1.2 多结构到底指哪几种结构多结构不是玄学在MES/ERP里可以明确归纳成几种常见结构形态结构类型典型场景组件组织方式主从结构工单头 工单行订单头 订单行主组件嵌套从表组件树形结构多层BOM、组织架构、料品分类树组件递归渲染流程结构工艺路线、审批流、返工路径步骤条组件、流程图组件条件结构按产品类型、车间、客户显示不同段落动态组件容器按条件装载实际项目里很少有单一结构更多是复合结构。比如一个工单主从结构承载单头和明细流程结构承载工序流转条件结构决定不同角色看到的内容差异。这就是为什么把它叫复杂多结构——不是一种结构搞定而是好几种结构叠加在同一个业务对象上。1.3 为什么复杂场景必须走组件化这条路传统做法是页面即应用一个页面一个超大类表单逻辑、表格逻辑、校验逻辑、权限逻辑全写在一起。初期开发确实快但三个问题很快暴露。第一代码越长越不敢改改一个字段要顺着几十个函数找影响面。第二新需求只能叠床架屋今天加个标志位明天加个条件分支界面越来越臃肿。第三不同工厂、不同产线的差异无法隔离A工厂的需求很容易影响B工厂。组件化的思路则不同以业务段落为粒度拆组件数据结构与展示各自独立通过编排层组装。好处是差异被隔离在组件内部改动半径变小可以按角色、按配置组装不同页面。举个生活化的类比组件化像乐高积木底座、轮子、驾驶室是固定模块今天拼消防车明天拼卡车换的是模块本身传统做法像捏橡皮泥一开始方便成型之后想改就得全揉碎重来。需要说明的是这里说的组件化不代表必须上微前端、低代码平台。它本质上是工程上的模块化加上结构上的可组装。先把这个认知对齐后面所有设计才有基础。2. MES/ERP里最典型的组件拆分场景工单与订单工单和订单是MES/ERP里最核心的业务对象也是复杂多结构组件的最佳试验田。把它们拆明白其他模块委外、检验、返工基本都是同一套方法的迁移。2.1 工单/订单的数据结构天然就是多层次的ERP侧的生产订单通常是这样一层层套下来的订单头单号、物料、数量、交货期、状态→ 订单行 → 组件物料清单 → 工艺路线 → 生产版本。到了MES侧工单的结构更偏执行工单头单号、物料、数量、计划起止、优先级、状态→ 工序分配 → 资源设备、工装、人员→ 生产批次/序列号 → 报工与完工记录 → 质量检验记录 → 返工返修记录。两边为什么都要有一套单子ERP管计划、物料、成本MES管执行、设备、质量。很长一段时间我的对接方案是ERP下发生产订单MES生成执行工单用订单号行号做关联键进度和结果回传ERP。这里不展开集成细节只想说明一点数据结构的天然多层决定了展示层也是多层的。一个页面要同时承载单头字段、多行明细、多级嵌套而且行与行之间还存在顺序和依赖关系。别想着用一个大表单或者一个大表格来塞下所有东西那样交互一定会失控。这个天然多层次就是多结构组件的源头。2.2 按业务段落拆分组件一个工单详情页是怎么拆出来的实操时我很少从组件这个词入手反而先问自己一句话这段业务是否在不同的页面、不同的工厂、不同的单据上被复用或替换答案是有就值得拆成一个独立组件。一个标准工单详情页我通常会拆成下面这些段落组件工单基本信息组件表单型单号、物料、数量、计划时间、优先级、状态、责任部门物料清单组件表格型子件、单位用量、应领数量、实领数量、批次信息工艺路线组件步骤型工序号、工序名称、先后顺序、标准工时、设备要求、工装要求生产执行组件操作型报工、完工、异常上报、暂停/恢复质量记录组件列表型检验项、检验结果、缺陷代码、处置方式返工返修组件联动型返工次数、返工单号、返工状态、复审结果附件组件通用型图纸、作业指导书、质检报告每个组件只做自己那一段业务。比如物料清单组件只管应领/实领/超领的展示和领料操作不去管工序完成没有工艺路线组件只维护工序和资源不负责报工录入。这样划分之后改动面就非常清楚客户想改领料规则进物料清单组件想改工艺审核流程只动工艺路线组件。2.3 不同角色看到的是不同组件集合组件拆分完成后自然就带出一个好处页面可以按角色组装。计划员打开工单看到的是基本信息、物料清单、工艺路线关心的是能不能按期开工、料够不够车间操作工打开工单只需要生产执行组件和异常上报组件关心的是我现在该干哪道工序质量员打开工单看到的是质量记录、返工返修组件设备管理员关心的是工单占用了哪些设备、工装状态怎么样。这个按角色看不同组件集合的需求传统的一页写死做法很难优雅支持。而有了段落组件之后页面容器只需要根据后端返回的展示配置把组件按顺序装出来就行。权限控制、工厂差异、产品类型差异都变成了配置问题而不是代码问题。3. 组件内部与外部的数据流转通信、状态与联动组件拆好了真正的难题才开始组件之间怎么通信业务状态怎么共享跨组件联动怎么做。这里面有不少容易想当然的地方。3.1 父子组件通信与业务段落联动一个工单详情页本质上是一个父组件页面容器管理多个子组件段落组件。父组件负责整体编排子组件各自维护自己的数据和交互。最常见的联动场景工单基本信息里改了物料物料清单组件要跟着刷新工艺路线组件里最后一道工序完工了生产执行组件的按钮状态要跟着变化质量记录组件标记了不合格返工返修组件要立即出现可创建的返工单入口。前端技术选型上Vue 或 React 的老三样依然是最可靠的父传子用 props 下发数据子传父用 emit/回调上抛事件跨多层低频共享数据用全局状态管理Vue 里的 PiniaReact 里的 Zustand/Redux。我的实践原则是先把页面内的数据依赖图画清楚再决定用通信还是用 store。依赖图简单直接就用 props/emit依赖确实复杂了再引入 store。很多团队的 store 越用越失控就是因为把不该放的数据全放了进去。工单基本信息、当前用户、当前工厂、当前语言这类跨组件低频数据放 store 是合理的但实时报工数量、物料清单刷新状态这种段落内部数据就应该留在组件内部用 props/emit 和父组件通信。3.2 状态机不应该散落在页面里MES/ERP 系统的业务状态多且相互制约这是让很多前端同学崩溃的地方。工单状态有未开始/已下达/生产中/已完工/已关闭返工状态有待返工/返工中/待复审/完成/报废质量状态有待检验/合格/不合格/待评审。这些状态之间还有前置关系工单不是已下达状态执行组件不能报工不合格记录没到待评审返工单不能创建返工单在审核中时返工工时不能锁定。如果状态判断逻辑散落在各个组件里会出现两个典型问题。第一组件 A 和组件 B 对可返工的判断不一致同一个按钮在不同页面行为不一样。第二新增一个状态时所有组件的 if/else 都要改一遍改漏了就出 bug。我的做法是前端组件只负责根据当前状态显示对应的按钮和字段把能不能做这个动作的判断交给后端。后端领域层统一维护状态机每次操作通过接口返回最新状态和对应的可执行权限集合。前端从接口拿到这些权限码再去渲染按钮显隐。这样组件结构能保持稳定因为状态逻辑不在组件里。哪怕状态机增加几个状态、调整几条流转规则前端组件基本不用动只需要跟着接口返回的权限码走就行。3.3 动态组件加载与管理一个页面承载N种组件MES/ERP 是典型的一套产品打天下场景同一个位置在不同工厂可能挂不同的段落组件。A 工厂的返工单需要成本分摊段落B 工厂的返工单需要客户让步接收段落。如果每个场景都改一次页面容器容器又会变成一个大杂烩。这时候需要的是动态组件加载。核心思路是页面容器不写死渲染哪些段落组件而是根据配置中心下发的模板动态匹配组件注册表里的组件。组件注册表维护一个标识到组件的映射配置中心返回的模板里每个段落都有一个标识前端按标识找到组件并渲染。用 Vue 3 写大致是这样的思路template div classpage-container component v-forsection in pageSections :isgetSectionComponent(section.key) :keysection.key :section-datasection.data :section-configsection.config section-changehandleSectionChange / /div /template script setup import { computed } from vue import { usePageTemplate } from ./usePageTemplate import { componentRegistry } from ./componentRegistry const { pageSections, reloadTemplate } usePageTemplate() function getSectionComponent(sectionKey) { return componentRegistry.get(sectionKey) || NotFoundSection } /script有几个细节必须注意。组件注册表里没有匹配到的段落要渲染一个未实现组件占位不能静默失败。切换组织、切换角色、切换工厂时必须重新拉取页面模板不能直接用缓存否则容易出现 A 车间的配置显示在 B 车间界面上。每个段落组件最好加上数据源配置让后端决定段落数据从哪个接口读前端组件内部只做展示和交互。这些细节是组件化落地和组件化 PPT的区别。前者要在生产环境里处理脏数据、权限切换、异常兜底后者只是画架构图。4. 实战复盘返工返修模块的多结构组件落地全过程前面聊的都是方法论这一章用一个真实场景把整个流程串起来。我选返工返修模块因为它复杂度足够高又足够典型是检验组件化设计能力的好题目。4.1 业务规则梳理返工返修为什么难做先澄清一个概念返工Rework和返修Repair在系统里应该分开。返工是重新经过工艺路线里的全部或部分工序回到合格标准返修是不经过完整工艺流程用特殊手段把产品修复到可接受状态。比如汽车水冷板这类产品工序长、批量大、还要 SN 追溯返工返修逻辑特别复杂。返工可能要走多道机加工序再重新检测返修可能只是补焊、清洗、重新密封。成本归集、质检流程、追溯路径完全不同。很多团队图省事把返工返修做成一张表后面成本核算、质量追溯都出了乱子。我的经验是一开始就必须分成两条业务链返工链走完整工序重做返修链走独立修复记录两条链可以共用质量复审环节但单据模型必须分开。返工单要关联原生产记录、不合格品记录、返工工序、操作人员、返工工时、成本、质量复审结果。业务规则也不少返工数量是全部还是部分返工是走完整工序路线还是只挑几道工序返工后的 SN 要不要重新追溯返工导致的生产计划调整由谁负责。4.2 组件结构设计返工单头/返工路径/返工执行/质量复审基于上面的规则我设计返工模块时拆成了这样几个段落组件组件职责关键数据返工单头组件返工基础信息维护返工单号、原工单号、物料、数量、触发原因、发起人、状态失效批次组件不合格品与受影响SN管理不合格记录、受影响SN列表、隔离位置返工路径组件从原工艺路线派生的返工工序集合工序、顺序、是否复制原工艺、可编辑范围返工执行组件逐工序报工与工时登记报工数量、工时、设备占用、消耗物料质量复审组件返工结果判定复审结论合格/报废/再返工、检验报告、签字确认成本分摊组件可选返工成本归集工时费、材料损耗、分摊规则组件之间不是简单平铺而是有依赖链的失效批次组件决定要返工哪些 SN返工路径组件决定走哪些工序返工执行组件按路径逐步报工全部完工后进入质量复审组件复审通过则关闭返工单并回流原工单复审结论是再返工时返工路径组件自动派生一份新路径并编号。返工单不是工单的复制品。很多团队图省事直接把原工单拷贝一份改几个字段结果原工单和返工单的语义关联断了追溯链彻底断开。正确做法是返工单只保留原工单的引用关系返工路径从原工艺路线派生但独立维护。4.3 关键实现细节从列表页到详情页的组件组装方式返工模块的前端页面组装我是这样做的。列表页是一个标准返工单列表组件查询条件、表格、分页。每行有打开详情的操作点击后进入详情页。详情页就是一个页面容器组件接收返工单模板配置按序渲染段落组件。详情页的工序行内还嵌了一层子组件返工路径组件里每一行工序可以展开执行记录显示这道工序在返工过程中的报工明细、工时、操作人员。这是行内多级组件的典型形态父组件只负责行展开/收起状态子组件负责自己的数据加载。状态联动是关键功能。返工路径组件里所有工序完成后返工执行组件才允许提交质量复审组件标记为再返工返工路径组件要自动生成一份新的返工路径并编号返工单关闭后页面容器要带着结果刷新原工单的执行记录。这些联动在设计时就要定义清楚。我的习惯是每个人物组件在自己的数据契约里把对外事件写明白页面容器统一处理事件路由。比如返工执行组件上抛execution-completed事件页面容器收到后通知质量复审组件更新状态。这样组件互相不认识但流程照样能串起来。5. 组件化之后真正的考验在维护和演进组件拆好了、页面跑通了只算完成一半。MES/ERP 是超长生命周期的系统一个工单页面可能用五年、十年。组件化能不能持续受益关键在后续维护和演进。5.1 复用与抽象之间的平衡组件化最怕的一件事就是为了复用而复用。有些人做组件化就喜欢搞大而全的万能组件把工单、返工单、采购单合并成一个单据公共组件props 设计了几十个参数里面塞满条件渲染。结果组件不仅没有复用反而比原来的大页面还要难维护。我自己的做法是分三级做复用。第一级是展示层复用字段展示、表格列配置、按钮组件、弹窗组织这些是纯 UI 层面的公共件可以放心抽。第二级是逻辑层复用通用状态机校验、通用审批流程、通用附件上传预览这些是业务逻辑组件抽象时要谨慎需要明确适用的业务边界。第三级才是组件级复用只有业务段落语义完全相同时才复用一个完整组件。每个组件对外暴露的接口要刻意收敛。能用一行 status 字段表达的不传一个配置对象能用一个回调事件表达的不暴露整个 store。组件边界一旦模糊后续维护就会越来越难受。组件注册表、前端组件库是长期资产但不要一步到位。先让组件在真实项目里被用起来重复出现两三次之后再考虑沉淀到公共库。5.2 组件级版本演进与老页面兼容MES/ERP 最怕的不是没有新功能而是老功能不敢动。组件化之后老页面的兼容问题变得更具体一个在产线上跑了三年的工单页面配置中心下发的还是旧模板里面引用的还是旧版本组件。这时候如果新组件改了接口、改了字段名老页面就废了。我的版本演进原则有三条。第一数据契约向后兼容后端接口新增字段默认可选不删旧字段不改变旧字段的语义。第二组件语义恒定组件名叫返工路径就永远表示返工路径哪怕形态相似也不要让它兼任委外工序路径。语义变了就新建组件不要改老组件。第三配置中心做灰度切换旧模板里的段落标识在前端保留映射别名新模板用新标识切换时先灰度一部分工厂确认稳定再全量。这三点看着简单实际项目里执行时很容易被顺手改一下带偏。我见过太多案例因为新需求顺手改了一个老组件的接口导致另外三个工厂的页面全部报错。组件化之后的改动尤其要遵守纪律。5.3 特殊组件打印、图形、可视化组件的取舍MES/ERP 里有些特殊组件容易被忽略但实际项目每天都在用必须单独考虑。第一类是打印组件。工单流转卡、条码标签、批次追溯单、返工单这些都是工厂的刚需。打印组件要独立不要跟业务页面耦合。业务组件负责把数据组装好打印组件只负责把数据映射到模板并输出。前端可以用独立的打印设计器或模板引擎维护一套打印模板跟页面组件互不影响。第二类是图形组件。工艺流程图、设备布局、组态画面、冷却循环管道流向这类可视化组件在 MES 里一般用于车间监控大屏或特定页面。它们的渲染复杂度高数据通常只进不出适合做成独立组件按需加载不要放进核心页面默认包里否则首屏性能会有明显压力。第三类是图表组件。质量统计分析、产量趋势、设备稼动率这些用 ECharts 这类开源库封装成业务组件即可。注意控制图表的数据量和刷新频率不要所有图表都实时刷新MES 的现场网络环境未必稳定。我早期犯的错是把所有特殊组件全塞进核心组件库里结果一个工单页面的首屏体积大得离谱。后来改成按需加载核心页面只保留表单、表格、流程步骤三类基础组件其他全部动态引入体验立刻好了很多。6. 实践踩坑记录与我的建议最后分享一些我在组件化改造过程中真实踩过的坑以及现在回头看觉得值得坚持的做法。6.1 最常见的五个坑第一个坑一上来就做万能组件。早期我总想着做一个所有单据通用的组件参数和条件分支越加越多最后连自己都不想用它。现在的原则是先做单一段落组件确实出现两处以上重复时再抽象不要让未来的需求绑架现在的设计。第二个坑状态判断写在前端。早期很多按钮的置灰、显隐全靠前端判断后端不校验。结果有操作员绕过界面直接调接口把工单状态从生产中改成了已完工后面排产和成本全乱了。前端只做体验后端做权威校验这个原则任何时候不能丢。第三个坑组件间通信全靠 store。项目初期图省事父子组件传值不用 props/emit全部塞进全局 store。半年以后没有任何一个人能说清楚某个字段到底是谁在什么时候改的。数据流必须有方向父传子用 props子传父用 emitstore 只放跨组件的低频共享数据。第四个坑不处理动态组件的缓存与权限脏数据。用户从车间 A 切到车间 B界面还显示 A 车间的段落配置角色变更后旧组件还挂在页面上。切换组织或角色时必须强制刷新页面模板动态组件上要加业务维度的 key。第五个坑数据契约不一致。前端认为某个字段是返工次数后端认为是返修次数两边对不上。后来我强制要求每个段落组件必须有明确的段落数据契约接口字段和前端类型定义一一对应字段命名统一。这个问题靠文档约定解决不了必须靠工程手段比如前后端共享类型定义。6.2 组件落地节奏建议不要大拆大建。我的落地路径是这样的。第一步选 1 到 2 个最高频、变更最频繁的模块做试点生产报工、返工返修这类最合适。因为它们的业务足够复杂组件化的收益最容易体现出来也最容易说服团队和业务方。第二步前后端一起定义段落数据契约每个段落组件需要什么输入数据、触发什么事件、向后端提交什么字段。先对齐契约再开发比代码写完再对齐要省力气得多。第三步组件结构稳定后再考虑配置中心、可视化编排、低代码这类上层能力不要一上来就搭平台。第四步做一张组件地图定期维护哪个页面由哪些段落组件组成每个月或每个季度清理一次废弃组件。这套节奏是我经过几次项目迭代后总结出来的。照着这个顺序走组件化改造的阵痛期会短很多。最后分享一个小习惯。我现在每写一个组件会在文件头部留一行注释这个组件对应哪个业务段落、解决什么问题、不解决什么问题。别小看这一行字它决定了组件的边界不会随着需求膨胀而模糊也决定了后来接手的人敢不敢去动这块代码。比如返工路径组件的注释!-- 组件返工路径 业务段落从原工艺路线派生的返工工序集合 解决返工工序的增删、排序、状态跟踪 不解决返工报工录入见返工执行组件、成本归集见成本分摊组件 --有了这行字讨论需求时也很高效——这段是返工路径的事不要塞到执行组件里。MES/ERP 的复杂业务本质上是无数个边界明确的小段落互相协作组件只是把这种边界用工程手段固定下来。边界清晰了复杂系统才有长期演化的可能。