指令不生效，多半是设备侧没确认执行，而非服务端没发出去：先判回执处在已入队、已下发、已确认、失败哪一态，再按在线、身份、权限、规则四类排除。
后台那个「下发成功」的提示，几乎从来不代表设备已经照做——它只代表服务端把指令交出去了。能作为依据的只有设备回报的回执。
一条指令要走五段：服务端组指令 → 推送唤醒 → 设备回连拉取 → 设备执行 → 上报回执。后台通常只覆盖前两段，这就是误判的来源。
四种回执状态，各自证明了什么
这不是我方口径，是平台文档的原文：Apple 明确写到，在服务端收到带这条指令 UUID 的 Acknowledged 或 Error 状态之前，不应认为指令已被设备接受并执行，在此之前应把该指令留在队列里。也就是说，「发了」和「生效了」之间隔着一次完整的设备往返，平台本身就不认前者。
表 1 · 四种回执状态
| 回执状态 | 证明了什么 | 下一步动作 |
|---|---|---|
| 已入队 | 服务端收下了指令，没有设备侧证据 | 查设备最后联系时间，先解决唤醒 |
| 已下发 | 指令已离开服务端，仍不证明执行了 | 等回执；超时按「未确认」重发 |
| 已确认 | 设备收到并处理了这条指令 | 核对业务结果是否同步 |
| 失败 | 这条指令在当前设备状态下做不到 | 按错误码归到四类原因之一 |
多数工单卡在第二态：后台显示已下发，设备毫无变化，于是开始怀疑策略写错——其实策略可能没问题，只是设备从没回连过。第四态也要拆：「现在不行、稍后可以」和「这台设备上永远不行」，处理方式完全相反。
苹果与安卓的回执语义不一样
苹果侧是「一条指令一次响应」，Status 只有五个值：Acknowledged、Error、CommandFormatError、Idle、NotNow；返回 Error 时会附错误链，官方注明错误码仅供诊断、可能随版本变化。
NotNow 不是错误。它表示「设备收到了，当时不能执行，稍后重试可能成功」——典型场景是设备刚开机、用户还没完成第一次输入密码进入桌面。关键细节：设备不缓存这条失败的指令，服务端要重试就必须重新下发一次，指望设备自己补执行是不成立的。另外，设备断网时会缓存结果、重连后补报，同一状态也可能重复上报，所以收到回执就改业务状态的逻辑必须按指令 UUID 幂等。
安卓侧是两层。命令类动作看回填的错误码：API_LEVEL（系统版本不支持）、MANAGEMENT_MODE（管理方式不支持）、INVALID_VALUE（参数非法）、UNSUPPORTED（设备不支持，升级管理组件可能解决）。策略类设置看合规明细：PENDING 是「预计很快应用」，属于等一等；MANAGEMENT_MODE 与 API_LEVEL 表示根本套不上，等到明年也不生效；USER_ACTION 则要设备使用者配合一步才能合规。
表 2 · 两套协议的状态对照
| 我方口径 | 苹果侧（响应 Status） | 安卓侧 |
|---|---|---|
| 已入队 | 已排队，未收到任何设备响应 | 指令已受理，策略未上报变化 |
| 已下发 | 推送已投递，设备尚未回连 | 指令已进设备拉取队列 |
| 已确认 | Acknowledged | 无错误码 + 合规明细不再报警 |
| 失败（可重试） | NotNow（当时不能执行） | 合规明细 PENDING（预计很快应用） |
| 失败（不可重试） | Error / CommandFormatError | API_LEVEL / MANAGEMENT_MODE / INVALID_VALUE / UNSUPPORTED |
最实用的是「失败（可重试）」那一行：苹果的 NotNow 与安卓的 PENDING 语义接近，都是「此刻不对、但原因会自己消失」。把它们和真错误混在一起处理，就会得出「时好时坏」这种没法排查的结论。两侧纳管原理的差别，另有专门页面讲透（苹果 MDM 监管锁原理、安卓 MDM 监管锁实操指南）。
四类失败原因怎么分开
所有状态收敛下来只有四类原因，分开它们的价值在于：每一类对应的处理动作完全不同，选错了就是在错误的环节反复折腾。
表 3 · 四类失败原因的区分口径
| 类别 | 典型现象 | 一句话判据 | 处理方向 |
|---|---|---|---|
| 设备未在线 | 回执停在已入队，最后联系是几小时前 | 设备从未收到这条指令 | 整批同时失联先查推送证书有效期 |
| 管理身份不足 | 同一策略部分设备不生效，回执说管理方式不支持 | 当前身份承载不了这条指令 | 纳管前移到入库，存量按做不到规划 |
| 权限与参数不合法 | 换一台正常设备照样失败 | 同一条指令在任何设备都失败 | 改参数、改作用域、补许可，别重试 |
| 规则语义冲突 | 新规则下发后旧规则失效，或状态来回跳 | 摘掉新规则后旧规则立即恢复 | 收敛规则数量，明确生效顺序 |
设备未在线是最常见也最容易被跳过的一类。判别有个捷径：一台离线查网络，整批同时失联先查推送证书有效期——证书过期不是个别设备失联，而是全量一起断。苹果侧推送走 TCP 5223 主通道、443 用于激活期与回退；安卓侧还要看厂商通道与后台保活，国内安卓设备的唤醒链路与境外并不相同（选型阶段就该问清，见 MDM 供应商怎么选）。
管理身份不足的麻烦在于它不报错，只是不生效。苹果侧看设备是否受监督、纳管时点对不对（手动加入的设备存在 30 天临时期）；安卓侧看拿到的是设备所有者、工作资料还是设备管理员，三种身份覆盖范围完全不同。这一类的答案不在技术侧，在流程侧：纳管前移到入库环节，别等设备租出去了再补。
排查顺序也有讲究：先排除「根本没送到」，再排除「送到了不让做」，最后才查「规则互相打架」。顺序反了会在最后一步空转——前两类没排除时，规则怎么写都看不出问题。
六步排查清单
每一步都必须给出一个可证伪的判据，否则只是看了一遍界面。
表 4 · 六步排查清单
| 步骤 | 看什么 | 判据 |
|---|---|---|
| 第 1 步 | 回执最新状态与时间戳 | 有回执且近 5 分钟内 → 往返过一轮 |
| 第 2 步 | 设备最后联系时间 | 近 10 分钟有联系 → 排除未在线 |
| 第 3 步 | 设备侧的管理身份与监督状态 | 身份能承载 → 排除身份不足 |
| 第 4 步 | 系统版本、管理方式、参数合法性 | 前置条件满足 → 排除参数问题 |
| 第 5 步 | 全部规则的作用域与生效顺序 | 无互斥规则重叠 → 排除冲突 |
| 第 6 步 | 设备侧实际在位的描述文件与管理应用 | 在位 → 问题在业务状态映射 |
两个具体的坑：一是把列表页的绿色标记当成回执——要看带时间戳的回执记录，没有时间戳的状态等于没有状态；二是把后台字段当成设备事实——那个「已纳管 / 受监督」本质是上一次上报的快照，设备恢复出厂或系统升级后后台不会立刻知道。合起来是一条原则：基于「设备说过什么、什么时候说的」，不基于「后台显示什么」。
把「可诊断」做进流程
多数团队的问题不是不会查，而是事后没有可查的东西：指令没留主键、回执没落库、错误码被吞掉只留一个「失败」。三条低成本做法：
- 每条指令带业务主键——订单号 + 设备标识 + 指令类型 + 下发时间落库，回执按 UUID 归因、重复直接丢弃。
- 无回执不进完成态——结清闭环是六步：结清判定 → 下发退出指令 → 采集设备侧回执 → 状态复核 → 出具结清与退出证明 → 归档；没有设备回执的订单进「待处理」。实质是：后台下发成功 ≠ 设备已退出管理。
- 错误分三桶——未送达 / 被拒绝 / 规则冲突，比一个总失败率有用得多，因为三桶对应的处理人不同。
边界也要写进流程：合同授权、用户知情、规则透明、权限最小化。设备侧本来就会显性显示监管状态与组织名称，所以「用户不知情」不是技术限制，是商家的选择。
绘盒（厦门绘盒网络科技）做租赁商家的设备管理与经营系统，品牌是绘盒金盾 MDM。9 条产品线覆盖金盾 MDM、荣耀 MDM、小米 MDM（小米官方授权）、风控、支付宝代扣、抖音融合交易、账单分析、CRM 与海外租赁，全部支持独立部署（也就是常说的私有化部署），指令日志与回执留在客户自己的库里——这正是「事后查得清」的前提。已服务 500+ 家租赁企业（数据口径：取自后台实际运行统计，按季度更新）。产品线与计费方式见 数码租赁全链路产品矩阵。
两侧的指令类型、状态字段与错误码均由平台方定义且可能随版本调整，正式排障请以 Apple Developer 与 Android Management API 官方当前文档为准。
常见问题
因为那个「成功」多半只代表服务端把指令交出去了，不代表设备执行了。苹果侧的口径很明确：在收到带这条指令 UUID 的 Acknowledged 或 Error 状态之前，不应认为指令已被设备接受并执行。所以第一步不是怀疑策略写错，而是去看有没有带时间戳的设备回执——没有回执，问题就在「送不到」，不在「配错了」。
先别下这个结论。先看是「一台离线」还是「一批同时离线」，这两种的成因完全不同。单台离线，多半是关机、没网、被恢复出厂或管理配置被移除；整批同时离线，优先查推送证书有效期——证书过期不是个别设备失联，而是全量一起断，这也是它最好认的地方。安卓侧还要多看一层：设备的后台保活与厂商通道状态，国内安卓设备的唤醒链路与境外并不相同。
不用马上，但必须重发。NotNow 的语义是「设备收到了，当时不能执行，稍后重试可能成功」——比如刚开机、用户还没完成第一次输入密码进入桌面。关键细节是：设备不会缓存这条失败的指令，服务端要重试就得重新下发一次，指望设备自己补执行是不成立的。合理做法是把它归到「可重试」桶，按退避间隔重发，而不是当成错误记一笔。
这几乎是管理身份差异的典型特征。同一批设备里，有的在入库时拿到了完整的管理身份，有的是已经激活之后才纳入、只能拿到受限身份，两者能覆盖的范围完全不同。另一种可能是系统版本不同：安卓侧的错误码里就专门有「系统版本不支持」这一项，苹果侧也要看受监督状态。判断方法：挑一台不生效的，去设备侧核当前身份与监督状态，而不是在后台看字段——后台那个字段是上一次上报的快照，可能已经过期。
不会。这一档属于不可重试：系统版本不够、管理方式不支持、参数非法、设备不支持，这四类在苹果和安卓上都被单独定义出来，说明它们是需要改配置才能过去的边界，不是偶发故障。识别它的最快办法：拿同一条指令在一台已知正常的同型号设备上试一次，如果照样失败，问题就在指令本身，跟设备无关。
不建议。这一步的正确口径是「结清即退出管理」，而判定它是否真的退出，要看设备侧回执，不是后台点一下按钮。后台下发成功 ≠ 设备已退出管理，两者之间隔着一次完整的设备往返。所以流程上应当把「无设备侧回执」的订单放进「待处理」，而不是「已完成」——否则下一次出租时，上一手的管控配置可能还在设备上。
能查到多少，取决于两件事：有没有把原始状态与错误链落库，以及有没有给每条指令留业务主键。平台侧给的信息通常够用——苹果会附错误链，安卓会回填错误码与逐项合规明细；真正容易丢的是自己这一侧：只存了一个「成功/失败」，把错误码吞掉，事后就只剩一个状态字段可查。我们不做「一定能查到」的承诺，但「指令带主键、回执落库、错误分桶」这三件事是可以自己控制的。
本文引证清单（3 组 · 可展开核对）
本页只引平台官方文档与本方运行口径，未引法条、国标与司法判例，故不适用对应标注规则；各平台的状态字段与错误码可能随版本调整，以官方当前文档为准。
苹果侧（Apple Developer 官方文档）
- 《Sending MDM Commands to a Device》—— 指令响应 Status 五值、「收到 Acknowledged 或 Error 前不应认为指令已被执行」、ErrorChain 仅作诊断（核对日 2026-10-21）
- 《Handling NotNow status responses》—— NotNow 表示稍后重试可能成功、设备不缓存失败的指令、设备在条件变化时主动 poll（核对日 2026-10-21）
安卓侧（Android Management API 官方文档）
- 《Method: enterprises.devices.issueCommand》—— CommandType 清单、CommandErrorCode（UNKNOWN / API_LEVEL / MANAGEMENT_MODE / INVALID_VALUE / UNSUPPORTED）、WIPE 与 RELINQUISH_OWNERSHIP 需设备确认后执行（核对日 2026-10-21）
- 《NonComplianceReason》—— 合规明细原因枚举，含 PENDING / MANAGEMENT_MODE / API_LEVEL / USER_ACTION / PROJECT_NOT_PERMITTED（核对日 2026-10-21）
本方运行口径（非外部依据，供核对用）
- 结清闭环六步与「无设备侧回执进待处理」规则 —— 取自绘盒金盾 MDM 内部运行规范（核对日 2026-10-21）
本页不给各品牌策略项清单，也不承诺任何排查时长与一次修复率。