同樣是 1GB，為什麼複製照片資料夾比複製一部影片還慢？

1GB 的影片一下就複製完了，可是合計 1GB 的照片資料夾卻遲遲結束不了。換了新的 SSD，一搬細碎的檔案，傳輸速度又突然掉下來。

容量一樣，時間似乎也該一樣，但決定複製時間的不只是「要搬多少位元組」，還有「要處理多少個檔案」。

本文是寫給在 Windows 11 上把照片與資料複製到外接硬碟、NAS 的一般使用者的入門介紹。先說明原理，再介紹在自己的環境中比較同樣總容量資料的步驟。內容依據 2026 年 9 月 5 日確認的官方資料，並不是對特定電腦或 NAS 的測速結果。

1.「搬 1GB」與「處理 1 萬件」是兩種不同的工作

用搬家來想：就算行李總重量相同，一個大箱子和一萬個要核對收件人的小包裹，費的工夫也不一樣。檔案同樣有在搬運內容之前與之後要做的事。

flowchart TB
    accTitle: 同樣的容量，不同的檔案數量
    accDescr: 同樣是合計 1GB 的資料，一個檔案和大量檔案的管理處理次數並不相同。
    A["合計 1GB 的資料"] --> B["一個大檔案"]
    A --> C["一萬個小檔案"]
    B --> D["以檔案為單位的處理很少"]
    C --> E["以檔案為單位的處理不斷重複"]

圖 1: 位元組數相同，檔案數量未必相同。

Microsoft 也說明過：跨網路依序複製大量小檔案時，資料傳輸以外的處理會發揮作用，導致跑不滿線路速度。¹

當然，這不是「照片慢、影片快」這種依格式劃分的規律。幾張大照片和幾萬個小圖片，條件本來就不同。請先在資料夾內容中同時看看總大小與檔案數量。比較時要對齊的不是「磁碟上的大小」，而是檔案內容的合計位元組數。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 11 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 複製時處理的不只是內容

複製檔案時，要開啟來源檔案、建立目的檔案、讀寫內容，再設定必要的資訊並關閉。Windows 開啟檔案的處理還要處理存取權限、能否與其他處理同時開啟等條件。²

名稱、大小、日期等用來管理檔案的資訊稱為中繼資料。例如 NTFS 這種檔案系統，會把每個檔案的管理資訊記錄在 MFT（主檔案表）等結構中。它不是「把照片的像素資料寫完就結束」的機制。³

flowchart TB
    accTitle: 複製一個檔案時要做的事
    accDescr: 除了讀取來源檔案，還要為每個檔案建立目的檔案、管理資訊並關閉。
    A["開啟來源檔案"] --> B["建立目的檔案"]
    B --> C["讀寫內容"]
    C --> D["整理資訊並關閉"]
    D -.-> E["下一個檔案同樣重複"]

圖 2: 這是概念上的流程。實際的處理順序與平行執行，會因複製方式與檔案系統而異。

用 SSD 也不會讓這份管理工作消失。光憑產品標示的大傳輸速度數字，算不出複製一萬個檔案要多久。另外，把小檔案的複製直接稱為「全都是隨機 I/O」也太過草率。除了讀寫的位置分布，還要把處理檔案本身的開銷分開來考慮。

3. 對 NAS 來說，還要加上「等對方回話的時間」

NAS 是透過網路使用的儲存裝置。Windows 共用資料夾使用的 SMB（Server Message Block）中，有些場合要把檔案操作委託給對方，然後等待對方處理並回應。

flowchart TB
    accTitle: 跨網路的檔案操作
    accDescr: 電腦發出的操作要求經過網路成為對方的檔案處理，回應再回到電腦。
    A["電腦發出檔案操作要求"] --> B["經過網路"]
    B --> C["對方處理檔案"]
    C --> D["回應回到電腦"]

圖 3: 一次能運多少，和一個操作多快得到回覆，是兩回事。

相當於道路車道數的是頻寬，相當於回覆所需時間的是延遲。每個小檔案都要等一下，那麼就算頻寬還有餘裕，傳輸量也上不去。防毒軟體的檢查也可能影響每個檔案的處理時間。¹

不過，這並不表示每個檔案一定要通訊固定的次數。SMB 有把要求合併的機制，快取與平行處理的條件也會改變等待的方式。⁴⁵ 家用區域網路和遠端的共用資料夾，結果也會不同。

為了用數字思考而做的簡化例子

假設處理沒有重疊、依序進行，思路就會像下面這樣。

複製時間 ≒ 合計位元組數 ÷ 資料傳輸速度
         ＋ 檔案數量 × 每個檔案的額外時間

這既不是實測值，也不是 Windows 的精確計算公式。 為了說明，假設資料部分是 100MB/秒，額外時間是每個檔案 2 毫秒。這裡 1GB＝1,000MB。

1GB 的資料部分是 10 秒。檔案只有 1 個時額外是 0.002 秒，一萬個則是 20 秒，合計約 30 秒。這是省略了平行化、快取、CPU 與儲存裝置限制的模型，但足以說明「容量相同、時間卻不同」。

flowchart TB
    accTitle: 把複製時間拆成兩部分來看
    accDescr: 區分由合計容量決定的傳輸時間，以及隨檔案數量累積起來的額外時間。
    A["與合計容量相應的時間"] --> C["整體的複製時間"]
    B["與檔案數量相應的額外時間"] --> C

圖 4: 檔案數量一多，只看資料量時看不見的時間就開始發揮作用。

4. ZIP 不只是「變小」，還有「合併成一個」

ZIP 既有壓縮資料的作用，也有把多個檔案裝進一個容器的作用。JPEG 本來就是壓縮過的格式，做成 ZIP 後容量可能減不了多少。⁶

即便如此，傳輸時要處理的檔案從一萬個變成一個，這個效果是另一回事。只看壓縮率就斷定「做成 ZIP 沒意義」，還太早。

flowchart TB
    accTitle: ZIP 的兩種作用
    accDescr: 打包成 ZIP 帶來的檔案數量變化，和壓縮帶來的容量變化是不同的效果。
    A["把照片打包成 ZIP"] --> B["要傳輸的檔案只有一個"]
    A --> C["容量的變化取決於內容"]

圖 5: 就算幾乎壓不動，要傳輸的檔案個數還是能減少。

不過，打包的處理與解壓縮的處理都不是免費的。如果希望照片仍然以一般資料夾的形式使用，就要用下面這個合計來比較。

經由 ZIP 的耗時 ＝ 建立 ZIP ＋ 傳輸 ZIP ＋ 解壓縮

建立 ZIP 時要讀取小檔案，解壓縮時又要在目的位置重新建立。重點不是消除以檔案為單位的工作，而是改變這些工作發生的位置與傳輸的形態。 如果傳輸前後的處理很重，不打包反而可能更快。¹

5.「在哪裡解壓縮」會改變 ZIP 的效果

如果把 ZIP 送到接收端的電腦，並在那台電腦的本機磁碟上解壓縮，就不必把小檔案一個一個送上網路。Microsoft 的指引也提到把封存檔在傳輸目的地的系統上解壓縮的做法。¹

flowchart TB
    accTitle: 在傳輸目的地解壓縮與從電腦解壓縮到共用位置
    accDescr: 區分在傳輸目的地內部解壓縮的路徑，以及電腦把解壓縮出的檔案寫到共用位置的路徑。
    A["把 ZIP 送到傳輸目的地"] --> B["由傳輸目的地自己在內部解壓縮"]
    C["用電腦上的應用程式解壓縮"] --> D["把小檔案送到共用位置"]

圖 6: 只知道「ZIP 在 NAS 上」，並不代表解壓縮處理也在 NAS 內部進行。

這裡很容易搞錯。用電腦的檔案總管開啟 NAS 上的 ZIP，把解壓縮目的地指定為同一個共用資料夾，那麼電腦解壓縮出的小檔案還是要寫到 NAS，細碎的網路操作又會重新發生。

請把它和「NAS 自身具備對應的解壓縮功能，可以從管理介面等在 NAS 內部執行」的情況區分開。如果沒有這類功能，就不要認為「送個 ZIP 就解決了」，而要測量實際使用的整條路徑。要比較「解壓縮到 NAS 內部」和「解壓縮到電腦本機」時，也別忘了檔案最終放置的位置並不相同。

6. 用同樣的 1GB，比較大檔案、小檔案與 ZIP

一開始拿手邊的影片與照片來試也沒關係。不過它們的內容、檔案數量、可壓縮程度都不一樣，想釐清原因時就要使用實驗資料。以下不是速度的測量結果，而是讀者在自己環境中執行的比較步驟。

要準備的是三樣：一個大檔案、一萬個小檔案，以及把這一萬個打包成的未壓縮 ZIP。A 與 B 的內容合計都精確為 1,000,000,000 位元組。C 還要加上 ZIP 的管理資訊，所以檔案大小不會與 A、B 完全一致。

flowchart TB
    accTitle: 三種比較用資料
    accDescr: 製作合計容量相同的大檔案與小檔案群，再由後者製作未壓縮 ZIP。
    A["準備同樣合計 1GB"] --> B["1GB 的檔案一個"]
    A --> C["100KB 的檔案一萬個"]
    C --> D["把同樣內容做成未壓縮 ZIP"]

圖 7: 用未壓縮 ZIP，更容易把壓縮率的差異和合併檔案數量的效果分開觀察。

製作實驗用檔案（可選）

這一節寫給會用命令的讀者。在 Windows PowerShell 5.1 以上，於本機的暫存資料夾中新建一個實驗用資料夾。光是大檔案與小檔案群就約占 2GB，加上 ZIP 約 3GB，傳輸目的地也另需空閒容量。為了不把磁碟塞滿，來源端請至少保留 5GB 左右的餘裕。

這裡不使用你既有的照片與資料。產生的是虛擬亂數資料，因此不是能當成影片或照片開啟的檔案。它避開了只用全零資料時那種極端的壓縮效果，但也無法重現針對真實照片的檢查與應用程式行為。

$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) 位元組。"

同一段位元組序列會同時寫入小檔案與一個大檔案。接著在同一個 PowerShell 視窗中製作未壓縮 ZIP，並在這裡記錄建立時間。NoCompression 表示不壓縮、直接存入 ZIP。⁷

$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) 位元組"

這套步驟只適用於剛產生的一般檔案。Compress-Archive 有忽略隱藏檔等限制，請不要直接拿它為重要資料夾做完整備份。⁷ 如果中途出錯停下，就不要把這一次納入測量，並檢查提示中顯示的實驗用資料夾。清理時也要先確認那是自己建立的資料夾再動手。

統一測量的條件

統一來源端與目的端的裝置、網路與複製方式。一開始三種資料都用檔案總管複製，不使用移動。目的端每次都用新的空資料夾，避免混入略過既有檔案或覆寫確認的情形。

flowchart TB
    accTitle: 統一比較條件的步驟
    accDescr: 固定複製路徑與方式，往空的目的位置調換順序多次複製，完成後還要核對內容。
    A["同樣的裝置·路徑·方式"] --> B["每次都用空的目的位置"]
    B --> C["調換順序測多次"]
    C --> D["核對件數與內容"]

圖 8: 不要把「已複製的檔案被略過」省下的時間，當成傳輸變快的結果。

每種情況例如各測 3 次，調換順序，記錄中位數與波動。Windows 會把檔案快取在記憶體中，所以有時只有第二次變快。就算換了新的目的資料夾，讀取端的快取也不會消失。這套步驟得到的是接近日常複製的趨勢，而不是嚴格無快取下的媒體效能。⁵

同一顆實體磁碟內的複製會讓讀寫互相競爭，不要和複製到另一台裝置的情況混在一起。僅限線上的雲端檔案會帶入取得時間，請不要使用；防毒軟體、同步等條件也不要中途更改。

這是用來記錄的表格，裡面沒有填入結果數值。A 是用來觀察傳輸性質的對照，因為檔案結構不同，它並不能代替 B。B 與 C 的實用比較，目標是把同一組檔案放到同一個最終儲存位置。解壓縮的位置也務必記錄下來。

複製或解壓縮之後，要核對件數與合計位元組數，必要時用雜湊確認內容。核對時的讀取要放在計時之外，並記下它也會影響下一次嘗試的快取。複製視窗關閉為止的時間，並不等於「可以承受斷電的狀態」所需的時間，因此也不要做「剛複製完就拔掉外接裝置」的實驗。⁵

7. 無法做成 ZIP 時，就一點一點地平行複製

如果希望在目的端立刻使用個別檔案，或者每次只送出有變動的檔案，那麼打包成 ZIP 就未必合適。Windows 內建的 robocopy 提供了平行處理多個檔案的 /MT。⁸⁹

flowchart TB
    accTitle: 把以檔案為單位的等待時間平行化
    accDescr: 同時推進多個檔案的處理，就能在一個檔案等待期間推進另一個檔案的傳輸。
    A["平行處理多個檔案"] --> B["檔案 A 正在等待回應"]
    A --> C["檔案 B 正在傳輸"]
    B --> D["把等待時間疊起來"]
    C --> D

圖 9: 平行化是把等待時間疊起來的方法，並不會讓線路或磁碟本身變快。

下面是從剛才建立的 $smallDir 複製的例子。只需把 $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"

/MT:8 是 8 個執行緒，/R:1 /W:1 是失敗時的重試次數與等待秒數，/LOG 是儲存記錄檔。robocopy 就算結束代碼為 1 也屬於正常複製，8 以上則含有失敗。0～7 並不代表可以省去內容確認。⁸

/MT:8 只是比較的起點範例，不是最佳值。平行數開得太多會加重對方的負擔，反而可能更慢。¹ 請用同樣的方法比較 /MT:1 與 /MT:8，把一次更動的條件縮到最少。不要根據同時更動了 ZIP 與平行化的結果，去判斷其中某一項的效果。

8. 在斷定「慢就是壞了」之前

是只有大量小檔案慢，還是大檔案也慢？把同樣的檔案複製到本機又如何？把這些分開，就能縮小要排查的範圍。如果是複製到一半速度下降，那也可能是快取的影響，光看顯示的速度無法確定原因。⁵

flowchart TB
    accTitle: 釐清複製變慢的原因
    accDescr: 把只有小檔案才慢的情況，和與資料種類無關都慢的情況分開來查。
    A{"只有小檔案慢？"} -->|是| B["看檔案數量與等待時間"]
    A -->|否| C["也檢查裝置、連線與負載"]
    B --> D["同時確認有無失敗或中斷"]
    C --> D

圖 10: 小檔案跑不上速度，和複製失敗或裝置異常，不是同一回事。

如果出現複製失敗、連線中斷，或者比以前突然變差，就不要只用檔案數量來解釋了事。請優先保全重要資料，並確認記錄檔與裝置的狀態。

另外，不建議為了加速而停用防毒軟體或關閉 SMB 簽章。SMB 簽章的作用之一是防止通訊遭到竄改。¹⁰ 在受管理的電腦上不要繞過設定，請與負責人討論。

總結

複製時間裡既有與資料量相應的時間，也有與檔案數量相應的工作。這就是「同樣是 1GB，時間未必相同」的原因。

要試 ZIP，就不要只看壓縮率，而要把建立、傳輸、解壓縮都算上。要試平行複製，一次就只改平行數。在換更快的裝置之前，把總大小與檔案數量放在一起看，會更容易想清楚現在的 Windows 上到底發生了什麼。

參考連結

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

容量一樣，為什麼複製照片資料夾比較慢？

複製不只是把內容搬過去。建立檔案、管理檔案資訊、關閉檔案等處理，每個檔案都會發生一次。小檔案一多，這些處理與等待時間所占的比重就會上升。比起「照片」這種格式本身，檔案的數量與單一檔案的大小更重要。

用 SSD 或高速區域網路，小檔案的複製也會變慢嗎？

會。就算用 SSD，檔案管理的處理依然存在；複製到 NAS 等裝置時，還要加上等待通訊與對方處理的時間。連續傳輸大檔案時的速度，和處理大量小檔案的速度是兩回事。

JPEG 打包成 ZIP 也變不小，那還有意義嗎？

就算容量幾乎沒減少，把要傳輸的檔案合併成一個仍然有效果。不過建立與解壓縮 ZIP 也要花時間。在需要解壓縮的用途下，要用建立、傳輸、解壓縮的合計時間來比較。

把 ZIP 傳到 NAS，再用電腦解壓縮到共用資料夾，會更快嗎？

那種做法是把解壓縮出來的小檔案從電腦寫到 NAS，於是跨網路的檔案建立又發生了一次。這與由 NAS 自身的功能在內部解壓縮是兩回事，請把解壓縮也算進去一起測量。

robocopy 的平行複製是不是開得越多越快？

不是。平行化可以把檔案處理的等待時間疊起來，但同時也會增加儲存裝置與 NAS 的負擔。請從較小的平行數開始在相同條件下比較，並用記錄檔確認複製是否失敗或漏掉。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。