命令幂等与请求编号该方案的核心目标是在外部命令尤其是关键控制命令可能因网络抖动、超时重试、客户端重复发送等原因被多次投递时保证服务端处理结果的一致性和可预测性避免重复执行带来的副作用如重复开测、重复卸料、状态错乱等。1. 基本原理所有外部命令必须携带以下统一标识字段可放在报文头或固定位置字段作用说明请求序号客户端为本次请求生成的唯一递增或全局唯一编号建议结合时间戳或 UUID 保证唯一性工站号标识具体工站/设备批次号当前生产批次Lot标识DUTSN当前待测器件序列号Device Under Test Serial Number时间戳客户端发起请求的时间用于辅助判断时效性与日志服务端处理逻辑收到请求后用「工站号 批次号 DUTSN 请求序号」或更完整的组合键作为唯一请求标识。查询近期已处理请求缓存内存 持久化保留时间建议覆盖最大重试窗口如数分钟到数十分钟。相同请求标识完全一致→ 直接返回上一次处理结果成功/失败/中间状态不再执行业务逻辑。不同请求→ 正常执行业务记录新结果到缓存。这就是典型的幂等设计多次执行同一请求与执行一次的效果完全相同。2. 为什么特别需要幂等在测试/生产系统中以下场景极易出现重复命令客户端超时后自动重发。网络短暂中断导致 ACK 丢失客户端认为失败而重试。人工操作或上位机异常导致重复点击/发送。服务端处理慢客户端误判超时。如果没有幂等保护可能出现同一 DUT 被重复启动测试SOT。重复卸料导致机械手冲突或计数错误。Reset 被多次执行导致状态机紊乱。结批EndLot被重复触发造成批次数据异常。3. 重点适用命令及详细说明3.1 SOTReadyReq准备开测请求风险重复到达可能导致设备重复进入 Ready 状态或重复申请资源。幂等处理相同请求直接返回上次 Ready 结果成功/失败原因。不同请求例如新的 DUTSN才真正执行准备动作。3.2 SOTReq正式开测请求风险最高重复开测会造成测试数据重复、测试时间浪费、甚至硬件损伤。幂等处理以「工站 批次 DUTSN 请求序号」严格判断。相同请求直接返回上次测试启动结果已启动/正在测试/失败原因绝不重新触发测试流程。3.3 Reset风险重复 Reset 可能打断正在进行的测试或使设备进入异常复位循环。幂等处理相同请求返回上次复位结果若设备已处于复位后状态直接告知“已复位完成”。3.4 EQPUnloadReq设备卸料请求风险重复卸料指令可能导致机械手重复动作、物料计数错误或碰撞。幂等处理相同请求返回上次卸料结果成功/失败/当前物料位置状态避免重复执行物理动作。3.5 EndLotReq结批请求风险重复结批会造成批次统计错误、数据归档重复、或后续批次无法正常开始。幂等处理相同请求直接返回上次结批结果真正结批动作只执行一次。4. 案例分析案例一网络超时导致的 SOTReq 重复客户端发送 SOTReq请求序号1001DUTSNABC123。服务端成功启动测试返回“启动成功”但返回报文在网络中丢失。客户端超时重发完全相同的 SOTReq序号仍为 1001。服务端识别为相同请求 → 直接返回缓存的“启动成功”结果不重新启动测试。客户端收到结果后继续后续流程测试数据保持唯一。案例二人工误操作导致的 EQPUnloadReq 重复操作员点击卸料发送 EQPUnloadReq序号2005。服务端执行卸料成功返回结果。操作员因界面卡顿再次点击产生相同序号的请求。服务端直接返回上次成功结果机械手不再动作避免二次卸料风险。案例三不同请求正常执行第一个 DUT 测试完成发送 EndLotReq序号3001。服务端执行结批并缓存结果。下一个批次开始客户端发送新的 EndLotReq序号3002批次号不同。服务端识别为不同请求 → 正常执行新批次的结批逻辑。案例四Reset 后状态一致性设备异常客户端发送 Reset序号4001。服务端执行复位并返回成功。客户端因超时重发相同 Reset。服务端返回“已复位完成”设备状态保持一致不会再次执行硬件复位动作。5. 实现要点与建议缓存策略使用本地内存缓存如 LRU TTL 持久化数据库或 Redis保证服务重启后仍可查询近期请求。唯一键设计建议至少包含「工站号 请求序号」有 DUT 时再叠加 DUTSN 和批次号提高精确度。结果缓存内容不仅缓存成功/失败还应缓存关键业务数据如测试启动时间、错误码、当前状态方便客户端直接使用。过期清理根据最大重试时间和业务需求设置合理 TTL避免缓存无限增长。日志与监控对“命中幂等缓存”的请求单独打日志和指标便于排查重复请求问题。客户端配合客户端重试时应保持请求序号不变只有真正的新业务才生成新序号。通过以上机制系统在不可靠网络和异常操作环境下仍能保持业务正确性与设备安全是提升产线自动化系统稳定性的关键方案之一。