严格状态机已经能拒绝部分非法操作但距离“工站唯一状态来源”和工业级架构还有以下问题。高优先级问题状态仍然不是唯一来源当前同时存在多套状态StationWorkflowStateMachineStationRuntimeIsBatchOpen_isWorkflowRunning_isResetting_isBatchClosingRunModeEnvironmentData.StationStatusEnvironmentData.ElectricalTestStateAutomaticPipelineActivity例如正式测试开始时StationControlViewModel.cs 设置_isWorkflowRunning true同时调用状态机进入WorkflowRunning但测试结束时只设置_isWorkflowRunning false并没有同步更新状态机。可能出现_isWorkflowRunning false WorkflowState WorkflowRunning因此状态机和实际业务状态可能不一致。建议后续由状态机统一维护生命周期状态StationRuntime只维护运行数据不能再让业务直接修改多个布尔字段。命令准入不是原子操作当前命令大致是检查状态 进入业务方法 业务方法再次进入邮箱 再次检查状态 执行具体业务虽然已经增加了邮箱内二次校验但“状态检查”和“业务占用”仍不是一个原子过程。例如StartLot 检查通过 Stop 命令改变状态 StartLot 继续进入业务目前只能依赖后续业务再次判断不能从架构上保证命令已经成功占用工站。建议增加CommandContext ExpectedState StateVersion OperationId命令必须携带状态版本执行时使用当前版本未变化 且状态符合预期 才允许占用并执行停止状态与实际流水线状态含义不完全一致当前停止按钮只停止电学测试之后仍然要继续吹扫 下料搬运 人工取料但是停止流程可能很快将状态设置为StoppedAwaitingReset此时实际上流水线可能仍有产品在吹扫或等待人工取料。因此StoppedAwaitingReset不能简单表示“所有生产流程都已经停止”它实际表示测试已停止流程正在收尾等待复位建议增加明确的状态或状态组合TestingStopped Draining WaitingForUnload StoppedAwaitingReset或者保留生命周期状态同时通过PipelineActivity明确区分“测试停止”和“流水线收尾”。状态机允许 Offline 从任意状态进入当前迁移规则允许任意状态 - Offline但软件状态进入Offline不代表硬件已经停止也不代表器件已经离开设备。如果将来某个异常分支直接调用ApplyButtonState(StationButtonState.Offline);可能出现界面显示离线 后台 Worker 仍在运行 PLC 仍有器件 主控板仍在测试建议Offline只能由生命周期服务在完成以下动作后进入停止测试停止自动上料等待流水线退出关闭主控输出PLC 复位或安全释放确认硬件状态。中优先级问题StationControlViewModel 仍然承担过多业务职责虽然已经拆分为多个.partial.cs但本质仍然是一个巨大类仍包含测试流程自动上料自动化 SOTEAP Host 放行复位停止结批PLC 判断窗体弹窗按钮状态数据文件日志设备状态。例如自动化方法仍在StationControlViewModel.Automation.cs后续应将HandleEapStartLotAsync、HandleEapSOTAsync等方法迁移到StationAutomationService StationEapService StationLifecycleService StationMaterialService StationTestServiceViewModel 最终只保留命令转发和界面属性更新。Automation 和 EAP 仍共用过于靠近协议的服务当前 EAP 网关和 Automation 服务最终都依赖StationAutomationService共享底层工站业务是合理的但不应让 EAP 直接依赖名称带有 Automation 语义的服务。当前容易造成误解EAP - StationAutomationService Automation - StationAutomationService建议调整为Automation - StationWorkflowFacade EAP - StationWorkflowFacade协议层分别独立AutomationTcpProtocolAdapter AutomationCommandRouter StationAutomationService SecsGemService EapCommandMapper StationEapService二者只在领域业务层汇合不共用协议语义。命令名称仍使用字符串映射StationAutomationService.cs当前通过字符串判断StartLot SOTReady SOT EQPUnload存在风险拼写错误时无法被状态机拦截新增命令容易忘记加入映射未识别命令可能绕过状态准入重命名命令时编译器不会提示。建议将EnqueueCommandAsync改为接收强类型StationWorkflowCommand.StartLot StationWorkflowCommand.Sot StationWorkflowCommand.EndLot不要让核心业务依赖字符串命令名。硬件资源锁还不是完整的工站级互斥StationDeviceContext.cs当前 PLC、主控板、负载板各自有独立锁。这可以防止同一设备同时访问但不能保证一个完整工艺动作的原子性。例如先写主控板 再写 PLC 再写负载板如果中途插入复位命令可能出现主控板已配置 PLC 尚未配置 复位已经开始建议增加两种锁设备级锁保护单个设备通讯 工站级事务锁保护跨多个设备的完整动作涉及多个设备的初始化、复位、测试启动、结批动作必须持有工站级锁。PLC 快照和实时读取仍未完全统一当前项目中同时存在ReadSignal() ReadSignalFresh() AutomaticRealtimeSnapshot PLC 直接读取这会造成不同业务看到不同时间点的数据。例如实时服务看到允许上料 1 SOTReady 直接读取到允许上料 0建议统一为PlcSnapshot SnapshotSequence CapturedAt IsCommunicationValid SignalValues业务只消费带时间戳的快照只有必须确认最新硬件状态的安全动作才使用明确标注的 Fresh Read。状态变化事件缺少异常隔离TryTransitionStrict更新状态后触发StateChanged?.Invoke(...)如果后续订阅者抛出异常可能出现状态已经改变 调用方却收到异常 按钮未刷新 业务认为转移失败建议状态变更事件内部独立捕获异常状态提交和 UI 通知分离UI 通知失败不能回滚状态日志记录订阅者异常。运行态字段仍可能组成矛盾状态StationRuntime.cs当前多个字段分别使用Volatile读写例如Resetting StopRequested WorkflowRunning BatchClosing AutomaticInitializationCompleted单字段读写是线程安全的但多个字段组合不是原子的可能读到Resetting false StopRequested true BatchClosing false WorkflowRunning true建议改成不可变快照整体替换StationRuntimeSnapshot所有运行态变化通过一个原子方法更新避免读到半更新状态。操作日志数据库写入方式会阻塞业务StationOperationJournal.cs当前每次记录都同步打开数据库、建表、插入并且数据库异常被直接吞掉。风险PLC 等待线程可能被数据库阻塞高速阶段变化产生大量 SQLite 操作数据库异常时不容易被发现日志事实可能丢失。建议业务线程 - 内存日志队列 后台日志 Worker - SQLite同时保留文本日志作为故障兜底并记录数据库写入失败次数。建议优化顺序增加状态机转移矩阵单元测试将StationWorkflowStateMachine移到Services.Workflow用StationRuntimeSnapshot替换多个独立布尔字段所有控制命令改成强类型命令将状态检查和命令占用合并为原子操作增加工站级事务锁统一 PLC 快照和 Fresh Read 规则将停止、收尾、复位状态重新定义清楚继续迁移 ViewModel 中的测试、生命周期和协议业务最后完善操作日志队列、恢复机制和统一释放流程。目前最需要优先处理的是前三项状态唯一来源、命令原子占用、停止状态语义。这三项如果不先解决继续拆分文件只能降低代码长度不能彻底解决状态错乱和并发竞态。