同样是 1GB，为什么复制照片文件夹比复制一部视频还慢？

即使同为 1GB，复制时间也会因打开、创建和关闭文件的次数而不同。本文说明文件数量和等待时间的工作原理，以及如何在相同条件下比较 ZIP 和并行复制。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 11 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

问题与疑问

一个 1GB 的视频很快就复制完了，但总计 1GB 的照片文件夹却迟迟无法完成。即使使用 SSD 或高速 LAN，移动大量零碎文件时，为什么显示的速度仍会下降？

本文要回答的是：“为什么总容量相同，复制时间却不同”，以及“如何确认打包成 ZIP 或并行复制是否适合自己的环境”。不要只凭照片这种文件格式判断速度慢或设备故障，而要比较文件数量和文件最终达到可用状态所需的时间。

适用环境

本文面向使用 Windows 11，将本地实际存在的照片、资料等普通文件复制到外置驱动器或通过 SMB 共享的 NAS 的一般用户。NAS 是通过网络使用的存储设备，SMB 是 Windows 文件共享所使用的通信协议。

操作示例使用文件资源管理器、Windows PowerShell 5.1 或更高版本中的 Compress-Archive，以及 Windows 自带的 robocopy。使用命令示例时，需要拥有复制源的读取权限，以及在实验文件夹和复制目标中创建、写入文件的权限。这些步骤不会通过管理员权限绕过访问控制。[S7: Compress-Archive] [S9: robocopy]

只有 NAS 产品本身支持 ZIP 解压功能，并且用户拥有相应使用权限时，才能在 NAS 端解压 ZIP。本文引用面向服务器的 SMB 资料来说明其工作原理，并不表示所有 NAS 都具备相同的设置或功能。

本文依据截至 2026 年 9 月 17 日确认的官方资料。下文中的数值示例是基于假设的计算，操作内容是在读者自身环境中执行的验证步骤，并非在某台特定 Windows PC、SSD 或 NAS 上测得的结果。本文不涉及仅联机的云端文件下载，也不讨论完整备份方案的设计。

解答与解决方法

决定复制时间的并不只有总字节数。若需要为大量文件反复执行创建、管理和结束处理，传输文件内容以外的时间就会增加。在 SMB 共享中，等待对端处理和返回响应的时间也会产生影响。通过 ZIP 汇总文件或使用 robocopy 并行复制有时会有帮助，但不能保证一定更快。[S1: Slow SMB files transfer speed]

首先确认总大小和文件数量，并使用相同路径和相同最终保存位置进行比较。对于 ZIP，应比较创建、传输以及必要的解压所需的总时间；对于并行复制，应使用相同数据和选项，只改变并行数进行比较。复制速度与复制是否成功应分别验证。

定义

文件复制不仅是把文件内容写到另一个位置，还包括在复制目标创建文件，并设置必要的属性、日期和时间等信息。本文把这些用于处理文件的操作和等待时间与内容传输区分开，称为“每个文件的额外时间”。[S2: CreateFileW function]

“小文件”并不是照片格式的别称。几张大照片与数万张小图片的条件完全不同。比较时应记录相当于文件夹“大小”的内容总字节数和文件数量，而不是只对齐“占用空间”。

搬家时，即使物品总重量相同，一个大箱子与一万个需要逐一核对收件信息的小包裹，所需工作量也不同。同样，“搬运 1GB 数据”和“处理一万个文件”是两项不同的工作。

flowchart TB
    accTitle: 相同容量对应不同文件数量
    accDescr: 即使数据总量都是1GB，一个文件和大量文件所需的文件管理处理次数也不同。
    A["总计1GB的数据"] --> B["1个大文件"]
    A --> C["1万个小文件"]
    B --> D["逐文件处理次数较少"]
    C --> E["反复执行逐文件处理"]

图1：字节数相同，并不表示文件数量也相同。

下文的说明数据把 1GB 视为 1,000,000,000 字节，把 100KB 视为 100,000 字节。比较时记录实际字节数，而不采用 Windows 或工具中经过取整的显示值。

作用

复制的目的是让所需文件在目标位置达到可用状态。即使传输窗口显示很高的 MB/秒，如果创建 ZIP 或解压 ZIP 耗时很长，也不代表能更快实现这一目标。

ZIP 用于把待传输的文件汇总起来；并行复制则让多个文件处理过程中的等待时间彼此重叠。两者都不会让线路或磁盘本身变快，而且各自适用的条件不同。[S1: Slow SMB files transfer speed] [S4: Performance Tuning for SMB File Servers]

flowchart TB
    accTitle: 选择复制方法时的目标
    accDescr: 将同一组文件放到目标位置，确认内容后，比较文件达到可用状态所需的时间。
    A["把同一组文件放到目标位置"] --> B["完成复制"]
    B --> C["核对数量和内容"]
    C --> D["比较达到可用状态所需的时间"]

图2：选择方法的目标，是让同一组文件正确达到可用状态。

一个大文件是用于观察文件数量差异的对照。它与一万个小文件的结构不同，因此不能直接作为实际用途中的替代品。实际选择方法时，应以能够把原始文件组放到同一个最终保存位置为目标。

组成

内容、管理信息和复制路径

复制文件时，需要打开复制源、创建复制目标文件、读写内容、设置必要信息，然后关闭文件。Windows 的文件打开操作还会处理访问权限，以及是否允许其他进程同时打开文件的共享模式。[S2: CreateFileW function]

名称、大小、日期和时间等用于管理文件的信息称为元数据。NTFS 会把每个文件的管理信息记录在 MFT（主文件表）等结构中。因此，复制并不是只写入照片的像素数据就结束。[S3: Master File Table]

flowchart TB
    accTitle: 复制一个文件时需要完成的工作
    accDescr: 除读取复制源外，还需要为每个文件创建复制目标、管理信息并关闭文件。
    A["打开复制源"] --> B["创建复制目标"]
    B --> C["读写内容"]
    C --> D["整理信息并关闭"]
    D -.-> E["对下一个文件重复执行"]

图3：这是概念性流程。实际处理顺序和并行执行方式会因复制方法和文件系统而异。

即使使用 SSD，文件管理工作仍然存在。不要只根据连续传输时很高的速度数字推算一万个文件的复制时间，也不要把所有小文件复制都简单称为随机 I/O。应分别考虑数据布局和文件处理带来的负担。[S3: Master File Table] [S1: Slow SMB files transfer speed]

工作原理

总容量相同时仍会出现速度差异，其原因可以分为等待响应、汇总为 ZIP 以及解压位置三个方面。

在 NAS 中，带宽和等待响应分别产生影响

使用 SMB 共享时，PC 会发出文件操作请求，对端文件系统进行处理，随后 PC 等待响应返回。按顺序复制大量小文件时，文件创建等操作所占的比例可能超过发送数据的时间，从而无法充分使用网络带宽。[S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: 通过网络执行文件操作
    accDescr: PC的操作请求通过网络到达对端，由对端处理文件，然后把响应返回PC。
    A["PC请求执行文件操作"] --> B["通过网络传送"]
    B --> C["对端处理文件"]
    C --> D["响应返回PC"]

图4：一次能够传输很多数据，与单次操作能够很快得到响应，是两件不同的事。

道路的车道数量相当于带宽，而等待响应返回的时间相当于延迟。防病毒检查也可能影响每个文件所需的处理时间。[S1: Slow SMB files transfer speed]

但这并不表示每个文件必然产生固定次数的通信。SMB 具有把多个操作请求组合发送的机制，缓存和并行处理也会改变等待方式。不要把家庭 LAN 与远程共享文件夹视为相同条件。[S5: Sending Compounded Requests] [S8: File Caching]

分别考虑 ZIP 的压缩和汇总作用

ZIP 既可以压缩数据，也可以把多个文件汇总到一个容器中。JPEG 本身已经是压缩格式，因此打包成 ZIP 后，容量可能不会缩小多少。即便如此，把待传输文件从一万个减少为一个的作用仍然存在。[S6: Zip and unzip files]

flowchart TB
    accTitle: ZIP的两种作用
    accDescr: 打包成ZIP所带来的文件数量变化，与压缩所带来的容量变化，是两种不同的效果。
    A["把照片打包成ZIP"] --> B["只传输一个文件"]
    A --> C["容量变化取决于内容"]

图5：即使几乎无法压缩，也仍能减少待传输文件的数量。

如果最终要把照片作为普通文件夹使用，应按以下总时间进行比较。

通过ZIP所需的时间 ＝ 创建ZIP ＋ 传输ZIP ＋ 解压

创建 ZIP 时需要读取小文件，解压时又要在目标位置重新创建这些文件。ZIP 并不会消除逐文件处理，而是改变执行这些工作的地点和传输形式。如果传输前后的处理负担较大，不打包反而可能更快。[S1: Slow SMB files transfer speed]

区分执行解压的设备

如果把 ZIP 发送到接收端 PC，并在该 PC 的本地驱动器上解压，就不需要通过网络逐一创建小文件。Microsoft 也建议在传输目标系统上解压存档，而不是从远端执行解压。[S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: 在传输目标端解压与从PC向共享目标解压
    accDescr: 区分传输目标自行在内部解压的路径，以及PC解压后把文件写入共享目标的路径。
    A["把ZIP发送到传输目标"] --> B["传输目标自行在内部解压"]
    C["在PC应用程序中解压"] --> D["把小文件发送到共享目标"]

图6：ZIP 位于 NAS 上，并不表示解压也一定在 NAS 内部执行。

如果在 PC 的文件资源管理器中打开 NAS 上的 ZIP，并把同一个共享文件夹指定为解压目标，PC 会把解压后的小文件写回 NAS。这样又会发生大量细碎的网络操作，因此必须与使用 NAS 自带功能在内部解压的方式区分开。

如果 NAS 不具备相应功能，就应测量实际可用的完整路径。解压到 NAS 内部与解压到 PC 本地的最终保存位置不同，不能简单地作为同一项工作的速度进行比较。

具体示例

下面给出用于说明的计算，以及将在操作步骤中创建的比较数据。两者都不是实际设备的测速结果。

1GB、1万个文件的简化计算

假设所有处理都按顺序执行且彼此不重叠，可以使用下面的概念模型。这并不是 Windows 的精确计算公式。

复制时间 ≒ 总字节数 ÷ 数据传输速度
           ＋ 文件数量 × 每个文件的额外时间

为了便于说明，假设数据部分的速度为 100MB/秒，每个文件的额外时间为 2 毫秒。因为 1GB＝1,000MB，所以数据部分需要 10 秒。一个文件的额外时间是 0.002 秒，一万个文件则是 20 秒，后者的总时间约为 30 秒。

flowchart TB
    accTitle: 把复制时间分成两部分考虑
    accDescr: 区分由总容量决定的传输时间，以及随文件数量累积的额外时间。
    A["与总容量对应的时间"] --> C["整体复制时间"]
    B["与文件数量对应的额外时间"] --> C

图7：文件数量增加后，只看数据量时看不到的时间开始产生影响。

这是根据假设计算出的数值。模型省略了并行处理、缓存以及 CPU 和存储设备的限制，因此不能用来预测实际设备一定需要 30 秒。

大文件、小文件组和未压缩 ZIP

比较数据之间的对应关系

使用自己的视频和照片也能观察趋势，但其内容和可压缩程度并不相同。下面的生成步骤会把相同的字节序列分别写入一个文件和一组拆分后的小文件，再从后者创建未压缩 ZIP。

flowchart TB
    accTitle: 三种比较数据
    accDescr: 创建总容量相同的一个大文件和一组小文件，再从后者创建未压缩ZIP。
    A["准备相同的总计1GB"] --> B["1个1GB文件"]
    A --> C["1万个100KB文件"]
    C --> D["内容相同的未压缩ZIP"]

图8：使用未压缩 ZIP，可以把压缩率变化与单纯汇总文件数量的效果分开观察。

A 与 B 的内容总量相同，但 C 的 ZIP 文件大小不会恰好等于 1,000,000,000 字节。由伪随机数创建的 .bin 不能作为实际照片或视频打开，也不能用于测试照片显示或重现应用程序行为。

操作步骤

首先使用文件资源管理器进行比较，仅在需要时再比较 robocopy 的并行数。请使用实验数据，不要使用重要照片或资料，也不要把复制与移动混为一谈。

不要更改保护功能、SMB 签名或同步设置等条件。如果写入权限和 NAS 操作受管理，请不要绕过设置，而应咨询负责人。[S10: SMB signing overview]

创建总容量相同的实验文件

使用 Windows PowerShell 5.1 或更高版本，并确认临时文件夹位于本地驱动器。A 和 B 合计约占 2GB，加上 ZIP 后约占 3GB。请确保复制源至少有 5GB 可用空间，复制目标也有足够空间容纳多次复制和解压试验。以下 PowerShell 示例应在同一个窗口中依次执行。

flowchart TB
    accTitle: 从相同字节序列创建两种比较数据
    accDescr: 把每次生成的100000字节伪随机数据追加到大文件，同时保存为一个小文件。
    A["生成100000字节"] --> B["追加到one.bin"]
    A --> C["保存为单独的part文件"]
    B --> D["重复10000次"]
    C --> D

图9：向两种数据写入相同的生成内容，使其总字节数保持一致。

1. 确认使用新的实验文件夹，而不是现有数据。

   代码会创建名称唯一的 copylab 文件夹。请记录显示的创建位置。处理中途不要重复执行同一段代码；如果发生错误，不要使用当时生成的数据进行比较。

2. 运行以下代码，创建一个大文件和一组小文件。

   $ErrorActionPreference = 'Stop'
   $lab = Join-Path ([System.IO.Path]::GetTempPath()) ('copylab-' + [guid]::NewGuid().ToString('N'))
   $drive = New-Object System.IO.DriveInfo ([System.IO.Path]::GetPathRoot($lab))
   if ($drive.AvailableFreeSpace -lt 5GB) {
       throw '请确保实验驱动器至少有 5GB 可用空间。'
   }
   $largeDir = Join-Path $lab 'large'
   $smallDir = Join-Path $lab 'small'
   [System.IO.Directory]::CreateDirectory($largeDir) | Out-Null
   [System.IO.Directory]::CreateDirectory($smallDir) | Out-Null
   Write-Host "创建位置：$lab"
       
   $fileCount = 10000
   $buffer = New-Object byte[] 100000
   $random = New-Object System.Random 20260905
   $large = [System.IO.File]::Open(
       (Join-Path $largeDir 'one.bin'),
       [System.IO.FileMode]::CreateNew,
       [System.IO.FileAccess]::Write,
       [System.IO.FileShare]::None
   )
   try {
       for ($i = 0; $i -lt $fileCount; $i++) {
           $random.NextBytes($buffer)
           $name = 'part-{0:D5}.bin' -f $i
           [System.IO.File]::WriteAllBytes((Join-Path $smallDir $name), $buffer)
           $large.Write($buffer, 0, $buffer.Length)
       }
   }
   finally {
       $large.Dispose()
   }
   Write-Host "准备完成。每组数据的内容为$([long]$fileCount * $buffer.Length)字节。"
   

3. 确认完成消息，并检查 large 和 small 文件夹中的文件数量与总大小。

   large 中的 one.bin 应为 1,000,000,000 字节；small 中应有一万个文件，每个文件为 100,000 字节。请在文件夹属性中检查字节数。只看到完成消息，并不表示已经确认复制目标的内容正确。

A 和 B 会创建在同一个实验文件夹中。一个大文件和拆分后的文件组写入的是相同字节序列，两组数据均为 1,000,000,000 字节。这样可以避免全部填零造成的极端压缩效果，但并不保证其性能与实际照片相同。

创建未压缩 ZIP 并记录创建时间

上一步必须已经成功完成。请确认同一个 PowerShell 窗口中仍保留 $lab 和 $smallDir。该步骤只适用于生成的普通文件。Compress-Archive 存在忽略隐藏文件等限制，因此不要用它为重要文件夹创建完整备份。

1. 在同一个 PowerShell 窗口中运行以下代码。

   $zip = Join-Path $lab 'small.zip'
   $watch = [System.Diagnostics.Stopwatch]::StartNew()
   Compress-Archive -LiteralPath $smallDir -DestinationPath $zip -CompressionLevel NoCompression
   $watch.Stop()
   Write-Host "ZIP创建时间：$($watch.Elapsed.TotalSeconds)秒"
   Write-Host "ZIP大小：$((Get-Item -LiteralPath $zip).Length)字节"
   

   NoCompression 表示以 ZIP 格式存储文件而不压缩内容。ZIP 中仍会包含存档管理信息。[S7: Compress-Archive]

2. 记录创建 ZIP 所需的秒数和 ZIP 文件的字节数。

   确认 small.zip 已创建。解压后，文件位于 small 文件夹内，因此稍后确认文件数量时，应比较该文件夹中的内容。创建失败的试验应排除，并检查原始实验数据和可用空间。

可以确认 C 包含与 B 相同的文件，并记录 ZIP 创建时间。A 和 B 的生成时间属于实验准备，不计入比较；ZIP 创建时间则是通过 ZIP 完成操作所需的成本，应计入比较。

沿相同路径复制并测量所需时间

固定复制源和复制目标设备、连接、应用程序以及同时发生的负载。必须有权限并能够为每次试验准备新的空复制目标。复制后的内容验证在计时之外进行；比较目标是让 B 和 C 在同一个最终保存位置达到可用状态。

flowchart TB
    accTitle: 统一比较条件的步骤
    accDescr: 固定复制路径和方法，改变顺序，多次复制到空目标，并在完成后检查内容。
    A["相同设备、路径和方法"] --> B["每次使用空复制目标"]
    B --> C["改变顺序并测量多次"]
    C --> D["同时检查数量和内容"]

图10：不要把跳过已有文件所节省的时间误认为传输变快。

1. 记录设备、路径、复制方法以及执行解压的设备。

   不要混合比较同一物理驱动器内部的复制和向另一设备的复制。不要使用仅联机的云端文件，并固定防病毒软件和同步功能的条件。如果 NAS 没有解压功能，应记录为从 PC 向共享目标解压的路径。

2. 分别使用文件资源管理器把 A、B 和 C 复制到新的空复制目标。

   不要使用“移动”。从开始复制到完成窗口关闭，应始终使用相同标准计时，并记录实际用时，而不是预计剩余时间或瞬时显示速度。如果某次试验出现跳过已有文件或确认覆盖的提示，不要把该次结果用于同条件比较。

3. 如果需要把 C 作为单独文件使用，还应测量解压时间。

   需要解压时，应合计 ZIP 创建、传输和解压时间。此前测得的 ZIP 创建时间应作为固定成本计入每次比较；多次重复使用同一个 ZIP 的运用方式应作为另一种条件记录。即使最终保存位置相同，也不能省略记录解压是在 PC 端还是 NAS 端执行。

4. 改变顺序，对每个案例分别测量多次，例如三次，并记录中位数和波动情况。

   即使使用新的复制目标，读取端缓存也不会消失。应同时记录只有第二次试验变快的情况，以及内容确认产生的读取对下一次试验的影响。此步骤用于观察接近日常复制的趋势，并不是严格的无缓存介质性能测试。[S8: File Caching]

执行后会保留 A、B 和 C 的时间与测量条件。在下文“验证”的记录表中，把 A 作为对照，把 B 和 C 作为同一组文件的不同放置方法进行比较，并且只用成功的试验判断速度。

ZIP 不适用时比较 robocopy 的并行数

使用创建实验数据时的同一个 PowerShell 窗口。确认 $smallDir 指向该数据，可以向 $lab 写入日志，并且复制目标的父文件夹可写。保留原始数据，每次都创建新的复制目标。不要添加 /MIR、/PURGE、/MOVE 等会删除文件的选项。

flowchart TB
    accTitle: 让逐文件处理的等待时间彼此重叠
    accDescr: 同时处理多个文件后，可以在一个文件等待响应时继续传输另一个文件。
    A["并行处理多个文件"] --> B["文件A正在等待响应"]
    A --> C["文件B正在传输"]
    B --> D["让等待时间彼此重叠"]
    C --> D

图11：并行化让等待时间彼此重叠，并不会让线路或磁盘本身变快。

1. 确认不使用 ZIP 的目的，例如需要立即使用单个文件，或需要反复发送变更内容。

   robocopy 的 /MT 会并行处理多个文件。一个文件等待响应时，可以继续传输另一个文件，但线路或设备本身的速度不会改变。[S9: robocopy] [S4: Performance Tuning for SMB File Servers]

2. 把 $targetRoot 改为自己有权写入的复制目标，然后运行以下代码。

   $targetRoot = '\\NAS\share\CopyLab' # 改为自己的复制目标
   $runId = [guid]::NewGuid().ToString('N')
   $target = Join-Path $targetRoot ('small-mt8-' + $runId)
   $log = Join-Path $lab ('robocopy-' + $runId + '.log')
   robocopy $smallDir $target /E /MT:8 /R:1 /W:1 /XJ "/LOG:$log"
   $code = $LASTEXITCODE
   if ($code -ge 8) {
       throw "复制出现失败。退出代码=$code，日志=$log"
   }
   Write-Host "退出代码=$code。请检查日志中的复制数、失败数以及复制目标的内容：$log"
   

   请替换示例中的 NAS 名称和共享名称。从执行命令之前到命令完成，应使用相同标准计时，并保存显示的日志位置和退出代码。

3. 使用相同方法比较 /MT:1 和 /MT:8，并固定并行数以外的条件。

   每次重新运行都会使用新的 GUID 创建复制目标和日志。示例中的 small-mt8 文件夹名称用于识别试验，因此测试 /MT:1 时，也可以把名称改成 small-mt1，以区分记录。不要同时改变 ZIP 和并行复制，然后只判断其中一种方法的效果。

   /MT:8 只是比较的起点，并不是最佳值。并行数过多会增加对端负载，反而可能变慢。出现错误的试验不能视为成功加速，应检查日志和实际内容。[S1: Slow SMB files transfer speed]

对于 B 中的同一组文件，将保留不同并行数对应的时间、日志和内容确认结果。退出代码为 8 或更高时表示包含失败，示例代码会停止；即使退出代码为 0 至 7，也仍需执行下文的验证。

验证

完成判定应分为两部分：“内容是否完整”和“在相同条件下达到可用状态的时间是否缩短”。不要用复制完成提示或退出代码代替完整性检查。

核对数量、内容和命令结果

预期内容和失败时的返回位置

即使文件数量和大小相同，也不能证明内容完全一致。如有必要，应在计时之外比较复制源和复制目标中对应文件的哈希值。验证过程中的读取也会影响下一次试验的缓存，因此应记录验证时机。

flowchart TB
    accTitle: 比较时间前检查内容
    accDescr: 检查数量和大小，必要时核对哈希，不把存在不一致或失败的试验视为成功加速。
    A["检查数量和大小"] --> B{"是否一致？"}
    B -->|是| C["必要时核对哈希"]
    B -->|否| D["排除该次试验并调查"]
    C --> E{"是否没有不一致或失败？"}
    E -->|是| F["比较相同条件下的时间"]
    E -->|否| D

图12：显示速度与复制内容是否正确，应分别检查。

robocopy 选项和退出代码

可以在 Microsoft 的 robocopy 资料中确认选项和退出代码。默认复制内容包括数据、属性和时间戳，本示例不是保存 ACL 等所有信息的完整备份方案。[S9: robocopy]

记录实际测量值

填写结果的表格

下表没有预先填写结果数值。应记录每次试验的条件、顺序、解压位置和是否出错，并且不仅保留中位数，还要保留原始时间和波动情况。

判断 B 与 C 时，应保证同一组文件最终能在同一个保存位置使用。如果只保存 ZIP 而不使用单独文件，则不需要解压，但这与需要使用单独文件是不同条件。如果多次试验的结果相互重叠，就不能断言速度提升已经超过误差。

区分速度慢与复制失败

分别确认是否只有大量小文件较慢、大文件是否也较慢，以及把同一文件复制到本地时会怎样。如果速度在途中下降，缓存也可能产生影响，仅凭显示速度无法确定原因。[S8: File Caching] [S1: Slow SMB files transfer speed]

flowchart TB
    accTitle: 排查复制速度慢的范围
    accDescr: 区分只有小文件较慢的情况，以及不论数据类型都很慢的情况。
    A{"只有小文件较慢？"} -->|是| B["检查文件数量和等待时间"]
    A -->|否| C["同时检查设备、连接和负载"]
    B --> D["同时确认是否失败或断开连接"]
    C --> D

图13：小文件无法达到很高速度，与复制失败或设备异常并不是同一问题。

如果出现复制失败、连接断开，或者性能突然比过去明显恶化，不要只用文件数量解释后便停止调查。应中止比较，优先保护重要数据，并检查日志、连接、可用空间和设备状态。在受管理环境中，应把试验条件和日志交给负责人。

清理前，应确认显示的 copylab 文件夹和每次试验的复制目标确实是自己创建的实验数据。本文不提供自动删除命令。不要删除原始照片或资料。

限制

这项比较能够说明和不能说明的内容

本文说明文件数量影响时间的机制，但不是已经确定读者设备根本原因的诊断。数值示例基于假设，比较步骤也不是已经取得的实测结果。不能保证使用 ZIP 或改变并行数一定会变快。

即使使用新的空复制目标，也无法统一操作系统的读取缓存和设备端状态。复制窗口关闭所需的时间，也不等于数据已经达到可以承受突然断电的状态。不要进行复制后立即拔出外置设备的实验，应使用正常的安全移除操作。[S8: File Caching]

备份和保护功能属于不同要求

生成的 .bin 和未压缩 ZIP 只用于比较。Compress-Archive 存在忽略隐藏文件等限制，普通 robocopy 选项也不会保存所有属性和权限。不要仅凭这项速度比较设计重要数据的完整备份。[S7: Compress-Archive] [S9: robocopy]

本文不建议为了提高速度而关闭防病毒软件或禁用 SMB 签名。SMB 签名用于防止通信遭到篡改等威胁。不要绕过受管理 PC 的设置，应与负责人协商。[S10: SMB signing overview]

在购买更快的设备之前，应先同时查看总大小、文件数量、实际复制路径，以及文件达到可用状态所需的总时间。判断是否采用改进措施时，不要把速度判断与复制内容正确性检查分开。

参考资料

资料确认日期为 2026 年 9 月 17 日。下面同时列出每份资料所支持的内容。面向服务器的资料中给出的设置示例，并不表示可以原样应用于一般用户或所有 NAS。

[S1] Microsoft Learn, Slow SMB files transfer speed。用于说明大量小文件、文件创建、通信与检查造成的负担，以及并行复制和在传输目标端解压存档。

[S2] Microsoft Learn, CreateFileW function。用于说明打开和创建文件的操作、访问权限和共享模式。

[S3] Microsoft Learn, Master File Table。用于说明 NTFS 保存每个文件管理信息的机制。

[S4] Microsoft Learn, Performance Tuning for SMB File Servers。用于说明复制小文件时使用 robocopy 并行化和输出日志。

[S5] Microsoft Open Specifications, Sending Compounded Requests。用于说明 SMB2 把多个相关操作组合发送的机制。

[S6] Microsoft Support, Zip and unzip files。用于说明 ZIP 对文件的汇总作用，以及 JPEG 在进一步压缩后通常难以显著缩小。

[S7] Microsoft Learn, Compress-Archive。用于说明 NoCompression 选项，以及忽略隐藏文件等限制。

[S8] Microsoft Learn, File Caching。用于说明系统文件缓存和延迟写入的机制。

[S9] Microsoft Learn, robocopy。用于说明并行数、重试、日志、复制选项和退出代码。

[S10] Microsoft Learn, SMB signing overview。用于说明 SMB 签名的保护目的和运用注意事项。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

容量一样，为什么复制照片文件夹更慢？

复制不只是把内容搬过去。创建文件、管理文件信息、关闭文件等处理，每个文件都会发生一次。小文件一多，这些处理和等待时间所占的比重就会上升。比起“照片”这种格式本身，文件的数量和单个文件的大小更重要。

用 SSD 或高速局域网，小文件的复制也会变慢吗？

会。即使用 SSD，文件管理的处理依然存在；复制到 NAS 等设备时，还要加上等待通信和对端处理的时间。连续传输大文件时的速度，和处理大量小文件的速度是两回事。

JPEG 打包成 ZIP 也变不小，那还有意义吗？

即使容量几乎没减少，把要传输的文件合并成一个仍然有效果。不过创建和解压 ZIP 也要花时间。在需要解压的场景下，要用创建、传输、解压的合计时间来比较。

把 ZIP 传到 NAS，再用电脑解压到共享文件夹，会更快吗？

那种做法是把解压出来的小文件从电脑写到 NAS，于是跨网络的文件创建又发生了一遍。这与由 NAS 自身的功能在内部解压是两回事，请把解压也算进去一起测量。

robocopy 的并行复制是不是开得越多越快？

不是。并行化可以把文件处理的等待时间叠起来，但同时也会增加存储和 NAS 的负担。请从较小的并行数开始在相同条件下比较，并用日志确认复制是否失败或遗漏。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。