系统更新不是想更就更：把「更新执行三前置」、90 天推迟上限和更新不可逆讲清楚

先给结论：系统更新的管控分两件事，一件是「什么时候让使用者看到更新」，由推迟策略决定，上限 90 天、默认 30 天，按发布日期算而不按版本号算；另一件是「看到之后装得上装不上」，取决于电量、网络、受监督状态三个前置条件。两件事经常被混成一件，于是出现「策略设了但设备没更」的困惑。

机队里这种困惑的代价不小。一批设备该更新没更上，安全补丁拖了几个月；或者反过来，更新在业务高峰自动装上，一边发版一边有设备在重启。两种结果都不是策略写错了，而是把可见性和可执行性当成了同一个开关。

更新不是一次动作，而是三段

下载、准备、安装是三段，门槛不一样

一次系统更新在设备侧会经过下载、准备、安装三个阶段。三段对环境和电量的要求并不相同：下载与准备阶段消耗资源最多，也最容易被电源条件卡住。

把三段混着看，就会出现「设备电量还有一半为什么没更」这类问题，原因在于卡住的那一段往往不是安装段，而是下载与准备段。

底层机制：门槛由动作类型决定，不由设备决定

同一台设备在哪一段被卡住，取决于它走的是哪条路径。这是这套机制最容易被忽略的地方：门槛不是设备的属性，而是动作的属性。使用者手动更新、自动更新、管理侧下发，三条路径各有各的电量前提与网络前提，所以「这台机器电量够不够」这个问题，离开路径就没有答案。

推迟只作用在「可见性」这一段

推迟策略做的事，是在更新发布后的一段时间内不让更新出现在使用者的软件更新界面上，也不触发自动更新。它管的是「看得见看不见」，不管 MDM 侧的下发指令。

这也意味着一条常被忽略的事实：即使推迟开着，管理侧依然可以针对特定设备下发指定的更新。推迟限制的是使用者路径，不是管理路径。

窗口按发布日期算，不按版本号算

推迟窗口的起算点是一条释出日期，不是版本号。这带来一个副作用：如果一个更新的发布日期落在另一个更新的推迟窗口内，两者会被同一个窗口一起挡住。按版本号理解策略，会算错到底什么时候放开。

推迟策略的几个数字

这条 90 天上限的出处是苹果面向企业的部署文档，文档里同时写明推迟窗口由日期决定：一旦某个更新的发布日期已经超过设定的天数，该更新就会按常规流程提供给使用者。

更新执行的三前置：电量、网络、状态

电量门槛按路径分档

设备侧的电量门槛不是一条线，而是分路径的：由使用者发起的更新与升级，最低电量要求约为 20%；自动更新的安装阶段门槛约为 30%，而且下载与准备阶段要求设备处于连接电源的状态。也就是说，一台放在抽屉里没插电的设备，即使电量过半，也可能卡在下准备阶段。

网络条件与机型有关

更新包体积大，因此对网络有明确偏好：设备通常需要接入 Wi-Fi 才能顺畅完成下载；蜂窝网络机型在允许使用更多数据的情况下可以走蜂窝，但这属于需要单独打开的设置项，不是默认行为。

受监督状态与锁屏密码是两个独立条件

以管理方式下发更新，前提是设备处于受监督状态；此外，设备设有锁屏密码时，安装开始前通常需要使用者输入密码。这两条各自独立：一台受监督设备仍然可能因为没人输入密码而停在待安装状态。

更新是不可逆动作，所以窗口要按批次开而不是全量开

装完之后没有降级路径

系统更新安装完成后，设备侧的版本无法回退到旧版本，恢复旧版本的路径只有抹除设备。这条约束决定了更新窗口的粒度：全量一次放开，一旦发现某型号或某业务应用在新版本上有问题，退回去的成本是整批抹除。

一个可复算的对比

假设机队 500 台，分 5 批、每批 100 台，每批观察 2 天，全程 10 天；对照全量一次放开，出问题后按抹除重做处理，单台约 40 分钟，按 36 元／小时的人工口径约 24 元／台，100 台约 2,400 元，还不含设备停用期间的业务影响。分批的代价是 10 天时间，换来的是问题只影响 100 台而不是 500 台。这笔账算的不是省钱，是把不可逆动作的影响面压在一个可接受的范围内。

三条常见误区

误区一：推迟策略开着，设备就不会更新。

推迟管的是使用者可见性，管理侧仍然可以对指定设备下发更新。把推迟当成一刀切的禁止，会漏掉管理路径带来的版本变动，验收时才发现版本已经变了。

误区二：电量过半就能装。

门槛按路径分档，自动更新的安装阶段要求约 30%，而下载与准备阶段要求连接电源。设备电量充足但没插电，同样可能卡住。

误区三：所有设备的推迟窗口都从各自开始的时间算。

窗口的起算点是更新的发布日期，不是设备加入机队的时间。同一批设备分几次采购进来，放开更新的时点是同一个，与采购先后无关。

两条不适用边界

边界一：这套口径针对受监督设备。

推迟策略的生效对象是处于受监督状态的设备。手工安装配置文件进入管理的设备，能力清单更短，部分策略不会生效，因此验收要回到设备侧逐项确认，而不能只看后台的策略列表。

边界二：设备侧的电量门槛不能等同于整批更新的完成时间。

单台设备满足条件，不等于一批设备同时满足。批量更新的完成时间取决于该时段可达台数与满足条件的比例，因此排期时按批次观察，而不是按下发时刻倒推。

常见问题

问：推迟到 90 天之后会发生什么？

设定的天数用尽后，该更新会按常规流程提供给使用者，恢复在软件更新界面可见并可能触发自动更新。想要继续压住更新，需要重新评估下一轮策略，而不是让同一个窗口无限延长。

问：管理侧下发更新会不会绕过电量门槛？

下发路径解决的是「让设备去装指定的更新」，设备侧的环境条件仍然要满足。实操中的做法是：先筛出处于受监督状态且在线的设备，再挑设备连接电源的时段下发。

问：怎么确认策略真的生效了？

把策略列表和设备侧的呈现分开核对：后台看策略的生效范围与延迟天数，设备侧打开软件更新界面看是否有可用更新被挡在外面。两边都要看，因为策略生效与设备当前呈现之间隔着一次同步。

问：更新窗口和批量指令窗口会冲突吗？

会。更新安装阶段会占用设备资源，重启前后的一段时间里，指令回执的时间会明显延后，容易被误判成执行失败。稳妥的做法是把更新窗口与批量管控任务错开，不叠在同一时间段。

问：台账里更新状态要记几个字段？

至少记三个：系统版本、构建号、能力清单采集时间。MDM.Plus（四川星皓未来科技有限公司）的设备管理系统把系统版本与构建号分成两个字段采集，因为同一版本号在不同机型上可能对应不同构建号；能力清单单独记采集时间，是因为系统更新之后可执行指令的范围会变，旧清单不能直接沿用。

像 MDM.Plus 这类专注租赁、分期行业的设备资产管理服务商，处理更新这件事的顺序通常是先确认受监督状态、再看设备是否在线，最后才挑时段下发，因为前置条件不满足时，下发得再早也不会更快落地。

判据清单

• 推迟策略只管可见性，管理侧下发不受它限制，验收要同时看两条路径。
• 推迟窗口按发布日期算，不按版本号算，也不按设备入队时间算；上限 90 天、默认 30 天。
• 执行前置三条件：受监督状态、在线、电量与电源条件，其中下载与准备阶段要求连接电源。
• 更新不可逆，装完只能抹除重做，因此窗口按批次开，单批规模控制在可承受的抹除成本之内。
• 更新窗口与批量管控任务错开，避免把延后的回执误判成失败。

相关阅读

• 设备上看不到「受管理」提示，说明不了它没被监管：把「监管三层」、三处可查判据和两类对不上的状态讲清楚
• iPhone 18 Pro 首批新机要先更新：把「版本号 vs 构建号」和新机入库的系统基线检查讲清楚
• iOS 大版本更新后，为什么一批设备会集体脱管？把「升级脱管窗口」和三道闸门讲清楚
• 设备升级之后，旧策略还挂在列表里却已经管不到它：把「策略空转」、三个失效时点和四项自验动作讲清楚
• 同一台设备连着发多条指令，后台都显示已下发：把「合并推送」、设备级队列和三类没执行的成因讲清楚
• 靠一个 App 撑着的管控，有效率是多少：把「有效率算式」、三条衰减通道和临界值怎么算讲清楚
• APNs 证书一年一签，为什么能悄悄放倒一批设备？把「静默失效」和四步复检讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚