企业官网建设流程全解析

这两个枚举应保持为两个独立维度：

• AutomaticPipelineRecoveryAction：产品和流水线接下来怎么走。
• AutomaticPipelineFailureNotificationPolicy：何时、是否由通用调度器弹窗。

不要让“是否弹窗”隐含在恢复动作里。比如同样是RequireReset，有时需要立即弹窗，有时设备已有专用告警界面，只需等待复位。

恢复动作的职责则可以明确为：

核心判定可以压缩为一个明确的入口，避免在各阶段散落if：

staticboolShouldShowPopup(AutomaticPipelineFailureNotificationPolicypolicy)=>policyisAutomaticPipelineFailureNotificationPolicy.ImmediatePopuporAutomaticPipelineFailureNotificationPolicy.AfterSafeUnload;

但这里的AfterSafeUnload不能在失败当下直接调用弹窗。建议把它转换为“待通知”状态：

switch(handling.NotificationPolicy){caseImmediatePopup:ShowFailurePopup();break;caseAfterSafeUnload:product.PendingFailurePopup=true;break;caseSilent:caseStatusOnly:caseAlreadyNotified:break;}

在“产品已安全下料/产品流程已结束”的统一事件中处理：

if(product.PendingFailurePopup){ShowFailurePopup();product.PendingFailurePopup=false;}

优化计划：

1. 定义统一策略对象，例如AutomaticPipelineFailureHandling，包含通知策略、恢复动作、失败码和失败原因。
2. 按“阶段 + 失败类型”建立策略表，而不是让每个catch或 PLC 分支各自判断。
3. 将通知处理集中到HandleNotification，将产品流转集中到ApplyRecoveryAction。
4. 以产品状态保存“待安全下料后提示”标记，不能只依赖内存中的一次性回调。
5. 对不合理组合增加校验。例如AfterSafeUnload + RequireReset需要业务明确说明：若无法安全下料，就不能等待下料后再提示。
6. 为每种策略组合测试三件事：是否产生弹窗、弹窗时机、产品是否进入了正确的后续路径。

建议保留现有枚举，不用布尔值替代。它们表达的是业务语义，而不是简单的“弹/不弹”；通过集中映射和统一处理入口，阅读与后续新增策略都会更稳定。