定义
State Machine（状态机）描述设备或任务（如 OTA、设备生命周期）的状态及状态转换规则。例如设备状态：未激活→在线→离线→禁用；OTA 任务状态：待下发→下载中→升级中→成功/失败。用于规范化状态流转与 Connection Status 管理。
建模与转换规则
状态机由状态集合、初始状态、转换条件及动作组成。转换条件可基于事件（如设备上线、OTA 完成）、超时或外部触发。设备管理平台中，Device Lifecycle 设备生命周期、OTA 任务、工单等均可用状态机建模。实现时需定义非法转换的拦截逻辑，避免状态不一致；支持状态持久化与恢复，便于审计与故障回溯。
与 DMP 的集成
平台通过状态机驱动 Connection Status 连接状态展示、OTA 任务进度跟踪、工单流转等。状态变更可触发 Event Stream 事件流，驱动告警、通知或下游系统联动；Audit Log 审计日志记录状态转换历史。可视化配置状态机可降低开发成本，支持业务人员按流程定义扩展状态与转换规则。
应用场景
适用于设备激活、入网、升级、维护、报废等全生命周期管理；OTA 任务的创建、下发、执行、回滚；工单的创建、派单、处理、关闭。规范化状态机可提升系统可预测性，便于监控大盘展示、SLA 统计及运维自动化。
状态集合与非法迁移的拦截
状态机先列出允许存在的状态，再列出每一种状态可以因为什么事件进入哪一种下一状态。设备生命周期、升级任务和工单各自有一套，不能共用一个叫“进行中”的筐。未出现在集合里的值应被拒绝写入。例如升级任务不能从“待下载”直接变成“已确认”，中间缺少写入和启动的证据。拦截要发生在写入时，而不是只在界面上隐藏按钮；接口若仍能写入，界面限制就没有约束力。
每个迁移都要记录来源状态、目标状态、触发事件和操作者或系统组件。没有来源状态的更新说明有人在覆盖，而不是在迁移。终态，例如已报废、已确认、已关闭，默认不再接受业务迁移；需要重开时，应定义单独的重开事件，并产生新的阶段，而不是把终态悄悄改回进行中，让历时统计被覆盖。
超时迁移必须有持久化时钟
靠超时自动转移的状态，使用条件是截止时刻已经写进持久存储，并且有唯一的计时器负责到期事件。只存在某个进程的内存里时，进程重启会忘掉“还在等待”，任务永远停在中间态；或者重启后重新计时，把已经等得很久的任务又延长一个周期。多个实例同时扫描时，必须保证同一任务只被一个实例迁移，否则会发出两次回滚或两次关闭。
时钟要使用平台统一的时间基准，并保存到期时刻而不是“再等十分钟”这种相对说法。相对说法在重试时会被重复累加。设备离线导致的超时和平台自身停机导致的超时应能区分：停机期间不应把所有任务都判失败。恢复后按保存的到期时刻补处理，而不是按恢复时刻重新起算。与回滚相关的观察期尤其如此，观察期被重置会使未确认的新版本被提前当成稳定版本。
外部系统回写绕过状态机
对接工单或资产系统时，常见做法是对方回调一个“状态”字段，平台直接覆盖本地值。对方若使用另一套词汇，覆盖会制造本地不存在的状态，后续迁移全部匹配不上。回调应先翻译成本地事件，再交给状态机决定能否迁移。翻译不了的回调进入待处理队列，而不是写入主状态。
初始化数据同样容易绕过。批量导入若把历史设备直接标成在线，会跳过未激活应有的凭证检查。导入只能放置到明确允许作为起点的状态，其余状态必须经过事件补齐。并发点击也会打架：两人同时关闭和重新派发，后写入的请求若不去对来源状态，会把已经关闭的单再打开。每次迁移都带上来源状态作为条件，条件不符就返回冲突，让调用方刷新后再决定。禁止用定时脚本“修正”不一致的状态而不留下事件，那会抹掉本来可以追查的非法路径。
为每一种状态画出允许的进入和离开之后，用真实历史跑一遍：有没有出现过图上不存在的跳跃，有没有状态停留超过规定时限却没有产生超时事件。历史对不上图，就先改图或补事件，再继续开发新流程。模拟时钟用于测试超时迁移，测试结束后必须确认生产环境没有留下被拨快的计时器。状态名称一旦被外部系统保存，就不要复用旧名字表示新含义；新含义用新名字，旧名字保留到迁移完成。否则对方缓存的字符串会把新流程写进旧分支。