上位机篇三：插件化工序平台怎么管住扩展

工序扩展不能靠复制宿主工程。现场会持续增加设备、工序和客户差异，如果每次新增工序都允许改 Shell、改启动台、改公共页面，平台会很快失去统一性。IIoT.EdgeClient 用插件化把扩展点收窄：宿主负责平台，插件负责工序。

当前结构里，Shell 通过 DirectoryModuleCatalog 扫描插件目录。每个插件目录需要有 plugin.json，清单里描述模块 ID、入口程序集、入口类型、版本、依赖、启用状态等信息。入口类型创建后需要实现 IEdgeProcessModule，再通过 Configure(IEdgeProcessModuleBuilder builder) 向宿主声明能力。

flowchart LR PluginDir["插件目录"] --> Manifest["plugin.json"] Manifest --> Catalog["DirectoryModuleCatalog"] Catalog --> Descriptor["ModulePluginDescriptor"] Descriptor --> Module["IEdgeProcessModule"] Module --> Builder["IEdgeProcessModuleBuilder"] Builder --> Services["服务 / UI / 任务 / 上传器"]

插件只声明能力

IIoT.EdgeClient/docs/插件开发约定.md 把插件入口限定得很清楚：插件入口类型只能实现 IEdgeProcessModule，插件只在 Configure(IEdgeProcessModuleBuilder builder) 中向宿主声明能力。模块 ID、工序类型、显示名、服务注册、CellData 注册、运行时任务工厂、上传器、UI 注册都通过 builder 完成。

这条约定把扩展方式固定下来。插件不能绕过宿主自己启动后台线程，也不能私自接管 Shell 导航；它要把能力交给宿主注册。宿主统一接收这些声明，再把插件能力挂到标准化运行框架里。

这张工序选择页展示了插件化扩展在入口层的效果。Launcher 看到的是 profile 卡片，不是某个插件内部实现。叠片、注液、匀浆都可以出现在同一个启动台里；点击后启动的仍然是 Shell，只是注入不同的 MachineProfile，再由 Shell 加载对应插件和配置。

平台和工序的代码边界

平台宿主和工序插件的边界可以按职责划分：

• Launcher：本地登录、工序 profile、Shell 启动。
• Shell：窗口宿主、资源字典、导航框架、运行生命周期。
• Host.Bootstrap：模块发现、依赖注入、诊断、任务、上传基础设施。
• Shared/Application：公共契约、标准页面注册、上传基类、诊断接口。
• Modules：叠片、注液、匀浆等工序插件。

这个边界有利于限制改动范围。平台负责人可以控制 Launcher、Shell、Host.Bootstrap 和公共契约；工序开发人员主要修改 src/Modules 下的插件。GitHub 上通过目录权限或评审规则限制宿主改动后，新增工序就不再等于改平台核心。

匀浆是当前完整落地点

匀浆插件当前落地最完整，但它不是平台的全部。scripts/edge-runtime.publish.json 同时保留叠片、注液、匀浆三个 runtime 定义；模块目录里也存在对应插件工程。匀浆适合用来验证整套插件机制，因为它包含页面、数据模型、Cloud 上传、MES 通道、运行任务和诊断。

把匀浆写成“唯一工序”会误导平台定位。更准确的说法是：平台支持多工序插件化接入，匀浆是当前最完整的验证样本和落地工序。后续工序扩展沿用同一套 profile、MachineProfile、plugin.json、IEdgeProcessModule 和 builder 约定。

管住扩展靠契约，不靠口头约束

插件化的价值不只是“能动态加载”。真正有用的是它把扩展变成可检查的契约：有没有 plugin.json，入口类型是否实现 IEdgeProcessModule，模块 ID 是否匹配配置，是否通过 builder 注册 UI、任务和上传器，是否复用标准 Cloud/MES 通道。

这些检查点都能落到代码和配置上。平台不需要凭经验判断某个工序是否接得规范，只要检查清单、入口类型、注册声明和运行诊断，就能知道插件是否按约定接入。

插件化不是把代码拆成多个项目就结束

真正要管住扩展，需要同时管入口、宿主、插件合同和代码权限。Launcher 管入口，Shell 管宿主，plugin.json 和 IEdgeProcessModule 管插件接入，IEdgeProcessModuleBuilder 管插件能向宿主声明什么。开发人员只改插件，不直接改宿主，平台才能保持统一方向。

如果每个工序都可以随意改 Shell，最后宿主会被各种工序逻辑拖散。匀浆加一个特例，注液再加一个特例，叠片再加一组全局状态，几轮之后平台就退化成一堆硬编码。当前结构的重点就是把工序差异限制在插件边界内。

三类扩展不能混在一起

业务规则把客户端扩展拆成 UI 插件、电芯数据类型、业务组装插件三类。UI 插件定义怎么展示，电芯数据类型定义这个工序有什么数据，业务组装插件定义扫码、采集、装配、上传等流程。三类能力可以在同一个插件项目里协同，但概念上不能混成一坨。

匀浆当前落地最完整，说明平台链路已经跑通；注液、叠片存在 profile 和模块扩展位，但不能写成已经完整交付。后续新增工序时，先把业务字段、单位、采集来源、上传目标讲清楚，再在插件里补模型、页面、任务和上传映射。

标准化带来的控制力

标准化不是限制业务，而是让工序差异有固定落点。宿主只提供公共能力，插件只通过约定接入，Launcher 只展示 profile。这样后续出现问题时能快速判断应该改哪里：入口问题看 Launcher 和 profile，运行底座问题看 Shell/Bootstrap，工序流程问题看对应插件。

这种控制力对产线系统很实际。现场程序不能每接一个工序就换一种启动方式、换一套诊断页、换一种上传补偿逻辑。统一的平台骨架让后续扩展可控。

代码权限和架构边界是一件事

限制开发人员不能随意改宿主，不只是管理手段，也是架构约束。宿主承载公共运行方向，插件承载工序差异。如果每个工序都能改宿主，平台统一性很快会消失；如果插件完全不能表达差异，平台又会变成空壳。

当前结构把这两个需求放在一起处理。Launcher 用 profile 扩展入口，Shell 用 DirectoryModuleCatalog 发现插件，插件用 plugin.json 和 IEdgeProcessModule 声明能力。开发人员主要在插件目录里工作，宿主通过合同接收能力。这样既能扩展，也能管住扩展。

这条边界越早建立，后续越省事。新增工序、替换设备通信、调整上传字段，都能先判断属于插件差异还是平台能力。判断清楚后，代码改动范围自然收窄。