新闻
更新推不下去，先分清是空间不够还是策略不对：把「两个容量字段」、更新前的空间闸和分批窗口算清楚
摘要：后台能查到的容量只有两个数：总容量与可用容量，单位都是 GB。可用不等于可回收，所以这个数字只能当闸门用，不能当清理目标用。更新前按包体积的 3 倍设闸，再按容量分批，比一次性硬推省下的是窗口，不是人力。
先给结论： 系统更新推不下去、企业 App 装不上、抹除后重装失败，这三件事在后台看起来毫无关系，但在设备上撞的是同一堵墙——剩余空间。判断能不能过这一关只有两个数：总容量与可用容量，单位都是 GB，不是字节也不是百分比。更关键的一点是：可用不等于可回收，所以这个数字只能当闸门用，不能当清理目标用；把它当清理目标，就会得到「清了 8 GB 还是装不上」这种看似无解的结果。
一、后台能查到的容量只有两个数
`DeviceCapacity` 是这台机器的标称容量
`DeviceCapacity` 返回的是设备总容量，单位 GB。它对一台 64 GB 的机器回 64，对 256 GB 的机器回 256。这个值在设备生命周期里基本不变，它适合用来做分组（按机型档位分开排期），不适合用来判断「现在能不能装东西」。
`AvailableDeviceCapacity` 是查询那一刻的余量
`AvailableDeviceCapacity` 返回可用容量，单位同样是 GB，iOS 与 iPadOS 从 4.0 起就支持。它的含义是执行查询那一刻的余量，不是「理论最大可腾挪空间」。这两个说法差得很远：前者是设备当时还空着多少，后者要靠人删东西才成立。
两个数相减得到的是已占用，不是能清出来的
三个量放在一起对照，各自能干什么、不能干什么就清楚了：
| 量 | 来源字段 | 单位 | 适合用来做 | 不适合用来做 |
|---|---|---|---|---|
| 总容量 | `DeviceCapacity` | GB | 按机型分组、排期分批 | 判断能否安装 |
| 可用容量 | `AvailableDeviceCapacity` | GB | 更新前的空间闸、告警阈值 | 估算清理能腾出多少 |
| 已占用 | 两者相减 | GB | 容量利用率统计 | 当作可回收量 |
第三行是错得最多的一行。把「已占用 52 GB」当成「能清出 52 GB」，就一定会高估清理效果。
MDM.Plus（四川星皓未来科技）的设备管理系统把 `DeviceCapacity` 与 `AvailableDeviceCapacity` 作为两个独立字段存进设备台账，并给每次查询结果打上采集时间：判断能否安装的前提是同一时刻的余量，脱离时间的数字没有判断价值。
二、已占用里有一大块是动不了的
这块空间的机制和文件大小无关：它不是被文件占掉的，而是被结构占掉的。分三处看。
系统分区与预置应用占固定的一份
一台 64 GB 的 iPhone，抹除重置之后可用容量通常在 45 GB 上下，差的这十几 GB 是系统分区和预置应用。这部分不随使用者变化，也不随清理动作变化。所以「抹除之后能空出 64 GB」这个预期本身就不成立。
APFS 快照和系统数据不按文件大小算
iOS 用的是 APFS 文件系统，快照、克隆文件、系统数据（设置里显示为「系统数据」）这些占用不体现在单个 App 的大小上。它们在「iPhone 储存空间」页面里可能只显示一个笼统的数字，但真实占用分散在几十个系统容器里。这也是为什么删掉一批照片之后，可用容量有时只涨了一半。
删 App 只释放它自己的那部分
删除一个 App，释放的是它的安装包加用户数据。它产生的缓存、它在「文件」App 里留下的导出文件、它写入相册的图片都不会跟着走。所以「删三个大 App 就能腾出 20 GB」这种估算，实际往往只兑现一半。
三、更新安装要的空间是两份，不是一份
下载一份、展开一份
系统更新（OTA）的过程分两步：先把安装包下载到本地，再解包安装。下载的包和解包后的工作区在同一块存储上，所以峰值占用大约是安装包体积的两倍以上。
口径：4 GB 的包按 8 到 12 GB 预留
按更新包 4 GB 来算，安装峰值占用在 8 GB 上下，再留一点余量给安装过程中的日志与临时文件，预留 12 GB 是稳妥的口径。这个数不是苹果公布的固定值，而是按「包体积 × 2 到 3 倍」推出来的工程口径。原理是下载与解包同时占用同一块存储，峰值必然高于包体积本身；用它做门槛比用固定值更可靠——包体积每代都在变。
空间不足的三种表现
第一种是下载阶段就失败，提示「无法检查更新」，看起来像网络问题；第二种是下载完成、安装阶段失败，重启后版本号没变，占用却少了一块；第三种是装到一半卡住，设备反复重启但进不了系统，这种最麻烦，要走恢复模式。
三种表现落在同一条链路的三个位置，后台看到的现象却完全不同：第一种是「指令超时」，第二种是「版本号未变」，第三种是「设备长时间不回连」。只在后台看，很难把三者归到同一类问题上。
四、算一笔 500 台的账：分批窗口
18% 不足 = 90 台
500 台机队，按 64 GB 机型为主，铺货半年以上，可用容量低于 12 GB 的机器按 18% 估，是 90 台。这 90 台推更新会失败。
90 台 × 12 分钟 = 18 小时
单台处理动作：查容量、清缓存、删非必要 App、腾到 12 GB 以上、重新推、等回执。熟练操作 12 分钟一台，90 台就是 18 小时人工。如果这 18 小时压在更新窗口里，意味着窗口被拉长到三个工作日。
一批硬推和按容量分两批的差别
| 做法 | 完成时间 | 人工投入 | 返工情况 |
|---|---|---|---|
| 500 台一次推 | 当天夜里启动，90 台整夜失败 | 次日 18 小时集中返工 | 更新包重复下载，占用再涨一轮 |
| 按容量分两批 | 410 台当夜完成 | 90 台先清理再进第二批，人工 18 小时分散 | 无重复下载 |
两种做法的总人工是同一个数，差别在窗口：一批硬推把所有失败集中在第二天白天，而那天通常还有交付任务；分批则把 18 小时拆进两天，每天 9 小时，不占交付日。
这个账的意义不在于省人工，而在于把不可控的「整夜失败」换成可控的「提前清理」。
像 MDM.Plus 这类做设备管控与设备资产管理的服务商，通常把容量闸放在排期之前而不是失败之后：先分组、再算余量、最后定批次，顺序反了就会把成本从排期推到返工。
五、三个可以自己动手的验证动作
动作一：在设备上看真实分布
路径是「设置 → 通用 → iPhone 储存空间」。这一页会给出各 App 的占用排序和一个「系统数据」条目。要看的是系统数据那一行——它是不能通过删 App 清掉的那部分。如果系统数据本身就占了一大半，清理动作的回报会很有限。
动作二：在后台查两个字段，别只看一个
查询用 `DeviceInformation`，问 `DeviceCapacity` 与 `AvailableDeviceCapacity` 两项。只看可用容量会丢掉机型信息：同样是剩 10 GB，在 64 GB 机型上是接近告急，在 256 GB 机型上只是正常波动。
动作三：做一次抹除前后的对照
挑 3 台机器，记录抹除前的可用容量，抹除并跳过数据恢复，再记录一次。两个数的差就是这台机型「可被清理动作腾出来的部分」。这个对照做一次，以后估算清理效果就有自己的口径，不用猜。
六、三个常见的误判
误区一：总容量减去已装 App，就是可用空间
漏掉了照片、系统数据、快照、缓存、离线内容。一台装着 20 个 App 的机器，App 总大小可能只有 15 GB，但可用容量远小于「64 减 15」。按这个算法估算，一定会高估。
误区二：抹除能清出全部空间
抹除重置的是用户数据分区，系统分区还在。64 GB 机型抹完可用 45 GB 上下，这是正常值，不是没抹干净。如果预期是 64 GB，就会反复抹除，把时间浪费在一个不会变化的结果上。
误区三：看剩余百分比就够
10% 的余量在 64 GB 机型上是 6 GB 左右，在 256 GB 机型上是 25 GB 左右，差 4 倍。按百分比设告警，等于让大容量机型永远不告警、小容量机型天天告警。按 GB 设阈值才是可比的。
误区四：删 App 是最高效的清理动作
在租赁场景里，机器上通常没装多少用户 App，占空间的大头是照片、视频和系统数据。删 App 的回报往往低于清相册与清缓存。
七、边界与不适用条件
边界一：`AvailableDeviceCapacity` 不在 tvOS 的查询字段列表里。
它在 iOS、iPadOS、macOS、visionOS、watchOS 上可用，但 Apple TV 没有这一项。用同一套脚本批量查所有平台，会在 tvOS 上报字段不存在——这不是设备故障，是字段不支持。
边界二：企业 App 的占用要按另外两个字段核对。
判断 MDM 装下去的企业 App 占了多少，用 `InstalledApplicationList` 里的 `BundleSize` 与 `DynamicSize`，单位是字节。用 App Store 页面上的安装包大小去估算，会漏掉运行时数据，通常低 30% 到 50%。
边界三：共享 iPad 的容量口径不同。
多用户共享设备上，每个用户有独立的配额，查询返回的是 `Storage quota size`，单位是 MB，不是 GB。用单用户的可用容量口径去判断多用户设备，会得出错误结论。
边界四：可用容量是快照，不能当趋势用。
一次查询只代表那一刻。要做容量趋势，必须按固定频率采集并记时间戳；两次相隔一个月的读数直接相比，中间可能发生过一次系统更新，结论会失真。
边界五：抹除前置检查在主机的那个字段上有系统版本门槛。
macOS 上判断能否走「抹除所有内容和设置」看的是 `EACSPreflight`，这项从 macOS 13.3 起才有。更早的系统上不能靠这个字段预判，只能先执行再看结果。
常见问题
问：为什么可用容量比设备总容量小那么多？
因为系统分区、预置应用和恢复分区都占空间，这部分不计入用户可用容量。64 GB 机型抹除后可用 45 GB 上下属于正常范围，与使用习惯无关。
问：更新推不下去，怎么判断是空间问题还是策略问题？
看两个信号：一是可用容量是否低于更新包体积的 2 倍；二是失败发生在下载阶段还是安装阶段。下载阶段失败多为网络或存储，安装阶段失败几乎都是空间。策略问题通常表现为「命令根本没下发」，而不是「下发后失败」。
问：清理到什么程度算够？
按更新包体积的 3 倍设门槛。4 GB 的包留 12 GB，这是有工程余量的口径。低于 2 倍（8 GB）时，安装过程会有概率在中途失败，而且失败后设备状态不好恢复。
问：容量告警应该按什么维度设？
按 GB 设，不按百分比。建议用机型档位分组后各设一个阈值，64 GB 机型 8 GB 告警、256 GB 机型 20 GB 告警，这样告警才有可比性。
问：抹除之后空间还是不够，是不是设备有问题？
先对照机型基准值。如果抹除后可用容量明显低于同机型平均水平，才需要考虑存储异常；如果只是没达到标称总容量，那是正常的系统占用，不是故障。
判据清单
判断一套容量管理做没做对，看五条。
一是容量字段按 GB 统计，不用百分比做跨机型比较；
二是可用容量带采集时间戳，阈值判断只用当次快照，不沿用台账旧值；
三是更新排期前先做空间闸，门槛按更新包体积的 3 倍算，不按固定 GB 数；
四是清理动作区分「可回收」与「不可回收」，抹除后的系统占用作为机型基准单独记录；
五是企业 App 占用按 `BundleSize` 与 `DynamicSize` 核对，不按商店页面大小估算。
相关阅读
- 设备连不上网，后台下发的命令一条都到不了：把「入网三档」、证书先于网络和 iOS 16 的分档变更讲清楚
- 上一轮的成色记录，新一轮上架前要作废：把「快照有效期」、三类变量的沿用规则和六个重采触发点讲清楚
- 一台 iPhone 还能被管几年：把「可用管控年限」、三个日期和采购端的 20 个月上限讲清楚
- 摄像头能出图，不等于镜头没划痕：把「功能轴与外观轴」、上报时效和过期重测讲清楚
- 告警不是按严重程度排，是先分三堆：把「告警三堆」、分堆判据和每月复盘的那笔账讲清楚
- 机器不回连，后台只显示一个时间：把「低可达三态」、三类成因的自愈机制和两个分辨字段讲清楚
- 迁移到声明式管理不是换个开关：把「双轨并行期」、配置项重写工时和四项完成判据算清楚
- 后台里的设备数和现场点数对不上，差的往往不是漏录：把「三个口径」、四类差额和四步对账讲清楚
