同樣是 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 自身執行解壓縮。本文引用伺服器用 SMB 資料作為機制的依據，但不表示所有 NAS 都具備相同設定或功能。

本文根據 2026 年 9 月 17 日確認的官方資料撰寫。下列數值是根據假設所做的計算，操作則是供讀者在自己的環境中確認的方法，並不是在特定 Windows 電腦、SSD 或 NAS 上取得的測量結果。本文不涵蓋僅存在雲端的線上檔案下載，也不涵蓋完整備份的設計。

解答與解決方法

決定複製時間的因素不只有合計位元組數。若必須針對大量檔案反覆執行建立、管理與結束處理，內容傳輸以外的時間就會增加。在 SMB 共用環境中，等待對方處理與回應的時間也會造成影響。使用 ZIP 彙整檔案或利用 robocopy 並行化有時會有幫助，但不保證一定更快。[S1: Slow SMB files transfer speed]

首先確認合計大小與檔案數量，並使用相同路徑及相同最終保存目的地進行比較。ZIP 要比較建立、傳輸及必要解壓縮的合計時間；並行複製則要使用相同資料與相同選項，只改變並行數量來比較所需時間。速度與複製是否成功，必須分別確認。

定義

檔案複製不只是把檔案內容寫到另一個位置，還包括在目的地建立檔案，以及設定必要的屬性、日期與時間等處理。本文將這些處理檔案所需的作業與等待時間統稱為「每個檔案的額外時間」，並與內容傳輸本身區分。[S2: CreateFileW function]

「小檔案」不是照片格式的同義詞。幾張大型照片與數萬張小型圖片的條件並不相同。比較時要同時查看相當於資料夾「大小」的內容合計位元組數與檔案數量，而不是只對齊「磁碟上的大小」。

以搬家為例，即使行李總重量相同，一個大箱子與一萬個必須逐一核對收件資訊的小包裹，所需工夫仍然不同。同樣地，「搬運 1GB」與「處理一萬個檔案」是兩種不同的工作。

flowchart TB
    accTitle: 容量相同但檔案數量不同
    accDescr: 即使資料合計都是 1GB，一個檔案與大量檔案需要執行的管理處理次數仍不相同。
    A["合計 1GB 的資料"] --> B["一個大型檔案"]
    A --> C["一萬個小型檔案"]
    B --> D["每個檔案的處理次數較少"]
    C --> E["反覆執行每個檔案的處理"]

圖 1：位元組數相同，不代表檔案數量也相同。

下列說明用資料將 1GB 視為 1,000,000,000 位元組，將 100KB 視為 100,000 位元組。比較時應記錄實際位元組數，而不是 Windows 或工具經過四捨五入的顯示值。

作用

複製的目的是讓所需檔案在目的地進入可用狀態。即使傳輸畫面顯示很高的 MB/秒，如果建立 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 傳送到接收端電腦，再於該電腦的本機磁碟機上解壓縮，就不必逐一透過網路建立小檔案。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 與一萬個檔案的簡化計算

下列公式是假設所有處理都不重疊、依序執行的概念模型，並不是 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["一個 1GB 檔案"]
    A --> C["一萬個 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["重複一萬次"]
    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 並記錄建立時間

確認上一項產生程序已成功完成，而且 $lab 與 $smallDir 仍保留在同一個 PowerShell 視窗中。本程序只適用於產生的一般檔案。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 建立時間要作為每次比較的固定成本；若實際操作會重複使用同一個 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，以區分記錄。不要同時改變壓縮方式與並行化，只判斷其中一項的效果。

   /MT:8 只是比較的起點，並不是最佳值。並行數過多會增加儲存設備或 NAS 的負擔，反而可能使處理變慢。不要把發生錯誤的結果當成加速成功，而要檢查記錄檔與實際內容。[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 簽章可保護通訊免遭竄改。不要繞過受管理電腦的設定，應向管理者確認。[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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。