一个下载中的临时文件，属性里已经显示接近 8.9 GB。第一反应很容易是：这么大，应该快下完了吧？
但在一次 P2P 下载观察中，初期同一文件的已分配磁盘块折算后只有约 29 MB；后来，客户端另一条带时间戳的进度记录显示约 3.63%，仍未完成。
这几个数字并不矛盾，它们根本不是同一把尺子。 而且，它们来自不同采样时刻，不能拿来互相换算。
📏 四种数字，四个问题
| 指标 | 它回答什么 | 它不能单独证明什么 |
|---|---|---|
| 逻辑大小 | 文件当前声明的长度是多少 | 这些位置是否都已有有效内容 |
| 磁盘占用 | 文件系统为它计入了多少存储空间 | 已收到多少有效、通过校验的数据 |
| 接收量 | 客户端按自身口径收到了多少数据 | 数据是否全部保留、去重并通过校验 |
| 校验完成度 | 目标内容有多少已按预期校验信息验证通过 | 校验信息是否来自可信的官方发布者 |
逻辑大小描述文件的长度，不是在替网络连接数流量。下载器可以先把文件长度设到目标大小，再逐块填入内容；P2P 下载还可能乱序接收，不能把文件末尾的位置理解成连续下载到了那里。
接收量也要看定义：累计传输量可能包含重复接收或校验失败后重传的数据。“接收了多少”与“保留了多少有效分块”不是天然相等的。客户端的百分比同样需要确认口径，不能默认每个软件都按已校验字节计算。
🧱 为什么一个大文件可以只占一点磁盘
稀疏文件和预分配都是可能机制，但仅凭大小差异，不能断言下载器用了哪一种实现。
稀疏文件允许部分逻辑范围没有对应的已分配磁盘块。这些“洞”通常读出来是零，却不代表下载源的真实内容已经到达。
预分配则是在下载前安排空间。具体 API、分配方式和文件系统不同，可能提前占用较多磁盘，也可能主要改变逻辑长度。不能简单地把“预分配”当成“几乎不占空间”的同义词。
反过来也一样：磁盘已经占满目标大小，不代表内容下载好了，可能只是空间先被留出来了。
因此，磁盘块适合回答容量与分配问题，不适合直接充当准确的有效字节计数器。分配粒度、压缩、共享块以及统计口径，都可能影响它与有效内容之间的关系。拿“占用空间 ÷ 目标大小”画进度条，看似精确，实际量错了对象。
🕒 进度必须带上采样时间
“正在下载”是一条状态描述，不是完成证据。单条日志甚至不能证明下载仍在持续推进：它可能只是启动时留下的一句话。
一份有用的进度回报，至少说明采样时间、数据来源、指标口径和当前状态。比如下面这条假设示例：
截至 9 月 12 日 14:20（UTC+8），客户端显示 4.2%，状态为下载中；该百分比是否按已校验内容计算尚未确认，未取得完成证据。
这里的时间和数字只是示例，不是前述案例的记录。关键在于：读者能知道这是谁测的、何时测的，以及结论到哪里为止。
想判断是否推进，可以比较两次带时间戳、同一口径的采样；想估计剩余时间，还需要一段时间内的有效速度。不能凭一次百分比，就保证什么时候能下完。
✅ 怎样才算真的下载好了
一个适用于大文件的检查顺序是：
- 确认目标范围：是单个文件、选中的部分内容，还是整个下载任务？
- 确认客户端完成状态：所需内容已经接收完成，没有待下载部分；不能只看文件存在、体积或一行日志。
- 确认校验结果：必要的分块或整文件校验已经完成，而非仍在检查中；长度正确只是辅助证据。
- 按用途确认可用性与来源：例如压缩包能否完整测试、软件是否具有可信发布者的签名。
最后一步有两个不同问题：内容是否完整，以及内容是谁发布的。
校验一致，不等于官方来源认证。 文件与某个哈希匹配，只能证明它与那份预期值一致；如果文件和哈希一起来自不可信来源，一致性本身不能给来源背书。需要官方身份保证时，应从可信发布渠道取得校验信息，或验证可信发布者的数字签名。
文件属性里的大数字很醒目，但醒目不等于有判定力。判断下载是否完成，应该沿着客户端状态、有效内容和校验结果往下查，而不是在“文件看起来已经够大”那里停下来。
马启航Marvis