为何更大的簇会导致存储设备可用容量降低？

嘿，这个问题真的戳中了很多人对文件系统的认知盲区——按常理说，更大的簇应该减少元数据（比如FAT表、索引项）的占用，怎么反而让可用空间变少了？咱们结合你给出的exFAT和NTFS测试数据，拆解一下背后的原因：

1. 文件系统的预留空间和簇大小绑定了 #

Windows自带的格式化工具，在创建exFAT或NTFS文件系统时，会根据你选的簇大小自动分配一部分固定预留空间，用来做文件系统的维护工作（比如修复、日志记录、元数据扩展），这部分空间是不会被算进“可用容量”里的：

• 拿exFAT来说，当簇大小超过某个阈值（比如2048KiB）时，预留空间会突然大幅增加——你最后一行的差异直接跳到6144KiB，就是这个机制在起作用。
• 对于NTFS，虽然默认预留空间一般是总容量的1%，但针对可移动设备（比如你用的U盘），格式化工具会根据簇大小调整预留值。你数据里出现的“异常”（比如簇16KiB和8KiB的可用容量完全一样），就是因为预留空间的调整刚好抵消了元数据减少带来的收益。

2. 总容量无法被簇大小整除的“尾部浪费” #

不管哪种文件系统，数据区都必须是簇的整数倍。如果你的存储设备总容量不是簇大小的整数倍，最后剩下的那点“零头”空间就会被彻底浪费，没法分配给任何文件：

• 比如你的exFAT分区总容量是15792537600字节（约14.7GiB），当簇大小设为1024KiB时，总容量除以簇大小会剩下512KiB的零头，这部分就直接浪费了；簇越大，这个零头的绝对值往往越大（除非刚好整除，但这种情况真的很少见）。

3. Windows资源管理器的容量计算逻辑有讲究 #

你在资源管理器里看到的“可用容量”，可不是简单的总容量减去元数据和已用空间：

• 它是直接读取文件系统标记的「可用簇数」乘以簇大小。而文件系统初始化时，会把一些簇标记为“不可用”（比如存引导区、备份引导区、FAT表备份的簇），这些簇的数量会跟着簇大小增加变多——因为每个固定的元数据结构至少要占1个簇，哪怕它实际大小远小于簇。比如一个1KiB的引导区，在64KiB簇下只占1个簇，但在4096KiB簇下还是占1个簇，这就平白浪费了额外的3995KiB空间。

关于你发现的“异常差值” #

不管是exFAT最后一行的6144KiB差异，还是NTFS里簇16KiB和8KiB的可用容量相同，都是上面几种因素叠加的结果：

• exFAT的大簇触发了额外预留空间，同时尾部浪费+元数据簇占用的损失，直接超过了元数据减少带来的收益；
• NTFS的簇16KiB时，预留空间的调整刚好抵消了元数据减少和尾部浪费的影响，所以可用容量和簇8KiB时完全一致。

最后补个你提到的小冷知识：exFAT确实在2019年被微软公开了规范，现在很多非Windows系统也能原生支持它啦~

备注：内容来源于stack exchange，提问作者martixy