为什么复制一个10GB的文件夹，进度条总是卡在99%？

这个场景你一定经历过：复制一个大文件夹，进度条刷刷刷地跑到99%，然后……停住了。一分钟、两分钟、五分钟，进度条纹丝不动，心态逐渐崩溃。

到底是卡死了还是还在跑？要不要取消重来？万一取消了前面都白费了怎么办？

别慌，这其实是一个非常经典的技术现象，而且有科学解释。

大文件 vs 小碎文件：速度差了几十倍

这是理解”卡在99%”的关键。

假设你要复制一个10GB的文件夹，里面有两种情况：

• 情况A：1个10GB的视频文件
• 情况B：10万个小文件（代码、配置、缩略图等），加起来也是10GB

情况A可能3分钟就复制完了，情况B可能要30分钟甚至更久。为什么？

因为每复制一个文件，系统都需要做一堆”行政工作”：

1. 找到源文件的位置（寻址）
2. 读取文件元信息（文件名、大小、修改时间等）
3. 在目标位置创建新文件
4. 分配存储空间
5. 实际拷贝数据
6. 写入元信息、更新文件系统索引
7. 确认写入成功

对于大文件，这套流程只需要走一次。对于10万个小文件，这套流程要走10万次。实际的数据拷贝可能只占总时间的10%，剩下的90%都在做文件系统的”文书工作”。

所以进度条卡在99%的真相往往是：前99%是几个大文件，很快就传完了；最后1%是一大堆小碎文件，每个都不大但每个都要走一遍完整流程。

机械硬盘的”物理限制”

如果你用的还是机械硬盘，情况会更糟。

机械硬盘靠磁头在旋转的盘片上读写数据。读取一个连续存储的大文件时，磁头基本不用动，速度很快（顺序读取可达150-200 MB/s）。但读取分散在盘片各处的小文件时，磁头要不停地”跳来跳去”——这叫随机读写，速度可能降到不到1 MB/s。

差了100多倍。

SSD没有机械部件，随机读写性能好很多，但小文件的IOPS（每秒输入输出操作次数）依然是瓶颈。只是从”令人崩溃”变成了”可以忍受”。

网络传输的”最后一公里”问题

如果你不是在本地复制，而是通过网络传文件（比如传到NAS、传到服务器、传到云盘），那”卡在99%”还可能有另外的原因。

带宽≠实际传输速度。你的网络带宽是1Gbps（约125MB/s），但实际传输速度可能远低于此：

• 协议开销：TCP协议的握手、确认、重传机制会占用一部分带宽
• SMB/NFS协议：传统的文件共享协议在处理大量小文件时效率很低，每个文件都需要多次网络往返
• 并发限制：多人同时传文件时，带宽被瓜分
• 延迟敏感：跨地区传输时，即使带宽够用，高延迟也会严重拖慢速度

进度条本身也在”骗你”

还有一个你可能没想到的原因：进度条的计算方式本身就不准确。

大多数系统的文件复制进度条是按”已复制的数据量/总数据量”来计算的。但它没有考虑到：

• 不同文件的传输速度不同（大文件快、小文件慢）
• 写入缓存的”虚假完成”——数据先写到内存缓存，进度条显示完成了，但实际还在往磁盘写
• 文件系统的元数据更新需要时间，但不计入”进度”

Windows的文件复制进度条在这方面尤其”乐观”——经常刷到99%之后等半天，因为它把写入缓存的数据也算成”已完成”了，实际的磁盘写入还在后台慢慢跑。

企业场景下，这个问题被放大了100倍

个人用户复制文件卡一卡，等等就好了。但在企业里：

• 设计团队：几十GB的PSD源文件要在团队成员之间共享，每次打开都要从服务器拷到本地
• 工程团队：项目文件夹里几万个小文件，同步一次要半小时
• 视频团队：几百GB的素材要从拍摄设备导入到存储服务器，进度条成了”焦虑制造机”
• 全公司：几百人同时访问文件服务器，互相抢带宽，所有人都慢

怎么让文件传输不再卡？

如果你是个人用户：

• 把机械硬盘换成SSD，随机读写性能提升几十倍
• 大量小文件先打包成压缩包再传，减少文件系统操作次数
• 用robocopy（Windows）或rsync（Mac/Linux）代替系统自带的复制功能，支持多线程和断点续传

如果你是企业：

• 用专业的文件管理系统替代共享文件夹，支持分块传输、断点续传、多线程加速
• 用局域网部署减少网络延迟，内网传输速度远超公网
• 文件不需要每次都”复制”到本地——在线预览、在线编辑，只在需要时才下载

像赛凡智云这样的企业云盘方案，就针对大文件传输和海量小文件做了专门优化——分块上传、秒传去重、内网直连，几百人同时用也不会互相卡。再也不用盯着99%的进度条干瞪眼了。

最后

进度条卡在99%这件事，看起来是个小烦恼，背后其实是文件系统、存储介质、网络协议等多个层面的技术问题。了解了原理，至少下次再遇到的时候不会那么焦虑——它大概率没有卡死，只是在处理那一大堆让人头疼的小碎文件。

📎 相关阅读：公司文件共享怎么操作？三种主流方案手把手教你配置、远程办公，访问公司文件像在办公室一样快！