题目重点：用低于50%入队、高于95%释放的迟滞状态机，拆空桩预约、命令幂等、遥测滞后与故障恢复。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 阈值按原文严格<50与>95，等于50/95不触发；API返回带有效性与时间的遥测为训练扩展。
- 机器人移动到桩不是瞬时操作，状态包括WORKING、WAITING、EN_ROUTE、CHARGING、LEAVING、FAULT。
- 一次check可能与下一次重叠；单机控制器以锁或串行事件循环保护机器人/桩双向关联，实际题若保证串行可简化。
解题路线
- 先批量读取或按API限制读取电量，再在短临界区规划状态变更，网络调用不长期占锁。低电WORKING机器人只加入等待队列一次，不每次check都发指令。
- 分配时原子地把空桩标RESERVED并把机器人标EN_ROUTE，记录assignment id。发move/charge命令使用这个id；下一check看状态而非只看电量，因此低电机器人途中不会再预订第二个桩。
- 命令ACK只代表接收，不代表物理到桩；到桩/开始充电事件确认CHARGING。未知超时进入核验或故障状态，不能直接释放桩，因为机器人可能正在前往。
- CHARGING且可靠测量>95时标LEAVING，发带id的离桩命令；物理空闲确认后才把桩FREE。没有确认的正式API时明确采用同步成功合同，并说明这只是题内简化。
- 等待队列先FIFO可解释公平性，低电严重程度可作为优先级，但需等待时间提升防饥饿。遥测过旧或异常不发反复相反命令，保留状态并告警。50/95两个阈值提供迟滞，避免在单一阈值附近抖动。
- 崩溃恢复从持久assignment与桩/机器人实际状态对账，检测一机器人多桩、一桩多机器人或无人占用的预订。性能优化事件通知或轮询缓存前，先保证同一check重复调用是幂等的。
手动走一遍
训练例R1=49%、D1空闲。第一次check预约D1给R1并发命令；第二次R1仍49%且在路上，保持原assignment。R1充到95%继续充，96%开始离桩；门口仍有R1时不把D1分给R2，空闲确认后再分配。
规模与取舍
每check轮询R个机器人与D个桩，朴素O(R+D)，分配队列与空桩池均摊O(1)；API调用/遥测延迟是主要成本。优先级等待队列O(log R)，实际并发命令数按设备能力限制。
易错点与追问
容易失分的边界
- 只看电量，每check都重复发充电命令。
- 读取空桩与预约不原子，两个机器人争同桩。
- 95%用≥而非>，悄悄改原文阈值。
- 发离桩命令就立即标空闲。
- 命令超时当失败直接重发，没有assignment身份。
继续深挖
- 所有桩满了而机器人快没电，等待政策怎么降级？
- 控制器重启后如何识别途中机器人？
- 遥测延迟与乱序，是否可用旧低电事件覆盖新状态？
- 同一桩反复故障，怎样隔离且通知调度？
