先给结论： iOS 27 起，受监督设备在收到 Return to Service 抹除命令时，可以在同一条命令里强制执行系统更新。原来是三段动作------抹除、推更新、等更新装完；现在合成一段。省下来的不是操作次数，是两段「设备停在中间态等人」的等待窗口。
这条写在苹果那份 iOS 27 企业文档的设备管理一节，原文的意思是：受监督设备收到 Return to Service 抹除命令时，软件更新可以被强制执行。前提有三个，受监督、走 RTS 抹除、目标版本可用，三个都得满足。
原来那三段，卡在哪儿
第一段是抹除。命令下发，设备清空，重启，进设置助手。这一段通常十几分钟，取决于设备与网络。
第二段是推更新。设备回到设置助手之后，要先走完注册、回到管理里，才能接收更新命令。这一段的问题是设备必须先「可用」，更新才能发下去。如果注册没走完，更新命令发出去也没有对象。
第三段是等更新装完。更新下载、准备、安装、重启，这一段的时间最长，而且它对网络与电源有要求。设备在客户手里的时候这一段最难控，因为客户随时可能拔掉充电器或者关机。
三段串起来的问题是：每一段之间都有一个「等人确认」的间隙。抹除完要人看一眼是不是真抹干净了，注册完要人看一眼是不是回到管理里了，更新完要人看一眼版本对不对。三个间隙加起来，一台机器的实际处理时间可能是纯执行时间的两三倍。
合成一段，机制上是怎么成立的
关键在 Return to Service 这条路径本身。它不是「抹除 + 重启」这么简单，它是一条有明确终点的路径：把设备送回到一个可交付的状态。这条路径中间会经过设置助手，会在那一步等管理服务的接管。
强制更新能合进去，是因为更新这一步在路径上有位置。设备在走这条路径时，本身就处在一个「可以执行管理动作」的状态里------它已经在跟管理服务交互了。更新不需要等设备回到完全可用的状态，它可以作为这条路径上的一环被执行。
这跟以前的做法有个本质区别：以前更新是「设备可用之后的一个后续动作」，现在更新是「设备回到可用状态这个过程的一部分」。前者要求设备先完成一个阶段，后者把两件事并进同一个阶段。
MDM.Plus 的设备台账把监督状态与目标系统版本分成两列，批量下发 RTS 命令前按这两列筛一遍，不满足条件的设备会被提前排除，不会混进批次里报失败。
顺带说一句同一批文档里的另一条：受监督设备在恢复模式里，软件更新与抹除这两项选项被移除了（27.2 起）。把这两条放在一起看，方向是一致的------抹除与更新这两件事，都被收进了「只能由管理侧发起」的范围里。
省下来的到底是哪一段
不是执行时间，是等待窗口。
三段做法里，两段等待窗口的来源是「人要看一眼」。第一段抹除完，要确认设备真的清空了；第二段注册完，要确认设备真的回到管理里了。这两个确认在批量场景里会被放大------50 台设备，每台看一眼，就是 50 次确认，中间还有排队。
合成一段之后，中间的确认点合并成一个：命令下发，等设备把整条路径走完，看最终结果。中间那两段不需要人盯着，因为它们在设备侧是连续执行的，中间没有需要人做决定的节点。
还有一个附带的好处：版本一致性。三段做法里，抹除和更新是两次独立操作，中间隔了一段时间。这段时间里如果管理侧的版本策略变了，第二批设备拿到的可能是另一个版本。合成一段之后，版本随命令一起下发，同一批设备的版本一定是一致的。
三种做法的取舍
把三种常见做法摆在一起对照：
- 先抹除再推更新：两次操作，两个等待窗口。适合设备数量少、需要逐台确认版本的情形；批量场景下确认成本随台数线性上升。
- 先更新再抹除：一次更新、一次抹除。问题是更新在设备还有数据的状态下执行，安装完重启可能触发一些与数据状态相关的行为；而且更新完才抹除，等于把最长的那一段放在最前面。
- RTS 抹除里带强制更新：一条命令，一个等待窗口。中间没有人工确认点，版本随命令下发保证一致。前提是受监督，且目标版本对这批设备可用。
三行的差别主要在「人工确认点有几个」。第一个两个，第二个一个（更新完要确认），第三个零个。确认点越少，批量场景下的优势越明显，但出问题时的可观测性也越依赖回执。
什么情况下不该用这条命令
第一种，客户资料还没确认处置完。强制更新会在更新的过程中重启设备，如果这台机器上还有未备份、未确认处置的数据，一次重启就可能把现场状态打乱。抹除是清数据，强制更新是改系统，两件事叠在一条命令里，出问题时不好分离原因。
第二种，目标版本会影响在用的业务 App。更新是不可逆的，升上去之后回退要刷机。如果这批机器上有业务侧依赖的 App，而新版本上这个 App 的表现还没验过，就不要把更新夹进抹除命令里------分开做，至少能在抹除之后先用一台样机验一遍。
第三种，这批设备里有不支持目标版本的机型。强制更新对设备有最低要求，一批里混着老机型的时候，部分设备会更新失败。失败之后设备停在哪个状态、后续怎么处置，要提前想好；不想承担这个不确定性，就按机型分批。
这三种情形有个共同点：都可以通过「分批」来化解。所以实操上的建议不是「用或不用」，而是「先按机型与业务依赖分两批，先跑一批看回执」。
一个能自己做的验证
验证要两台样机，都受监督、都在 27 及以上，其中一台故意配一个不支持目标版本的状态------比如把目标版本设成一个比它当前系统低的值。
第一步，给第一台下发带强制更新的 RTS 抹除命令，记下发时间。
第二步，观察三件事：设备有没有走完抹除、有没有在执行过程中完成更新、最终回到管理里时的版本是不是命令里指定的那个。
第三步，给第二台下发同样的命令，看它失败时回执里报的是什么。这一步的目的是摸清「版本不可用时这条命令怎么表现」------是整条命令失败，还是抹除成功、更新失败。两种表现对应两种处置流程，要提前知道是哪一种。
第四步，两台都做完之后，把回执与台账里那两栏（下发时间、最终注册结果）对一遍，确认信息能对上。
两条容易走偏的判断
误区一，把这条命令当成「一键翻新」。它做的只是把抹除与更新合成一段，验机、成色判定、配件核对这些环节一个都没少。把它当翻新用，最后会发现机器是新的、成色记录是空的。
误区二，以为合并不影响可观测性。恰恰相反，合并之后中间过程被压掉了，你能拿到的只剩最终结果。所以对回执字段的要求更高------至少要知道「抹除完成了没有」「更新完成了没有」这两个是可以分开判断的，不能只有一个总状态。
边界与不适用条件
这条能力只对受监督设备生效，未受监督设备走不了 RTS 路径。写操作的前提是目标版本对这批设备可用，版本不可用时的表现本文给出了验证方法但没有结论，因为它取决于管理平台的实现，各家可能不同。另外本文说的「等待窗口合并」是在批量场景下的观察，单台设备的差别不明显------一台机器分开做和合起来做，绝对时间差不多，差别在确认次数上。还有一种情况要说明：设备在抹除路径上如果网络中断，更新这一段会停在中间态，这时不能直接重发整条命令，要先确认设备当前停在哪个阶段，否则会出现重复执行。
MDM.Plus 的批量任务把 RTS 命令的执行结果按「抹除结果」与「更新结果」两列分别记录，最终注册结果单列一栏，出问题时按这三列一起看就能定位停在哪一段。
四条收尾判据
给一套能直接用的判据。一是先按机型分档，确认目标版本对每一档都可用，不可用的单独走。二是命令下发前确认设备受监督，未受监督的不要下发，发了也不会有反应。三是回执要能分出抹除结果与更新结果两列，只有总状态的不能用来定位。四是批量先跑一批，看回执再放全量，别一次推完。四条里第三条最容易被忽略，因为很多平台只给一个成功与否，那种回执在合并执行时等于没有信息。