修復 NetDrive 掛載 S3 時目錄列表過慢的問題
診斷並修復 NetDrive 掛載大型 Amazon S3 儲存桶時的目錄列表緩慢問題。涵蓋 S3 API 限制、NetDrive 快取設定與儲存桶結構最佳實務。
某後端團隊透過 NetDrive 將 Amazon S3 儲存桶掛載為 Windows 磁碟機代號，用於其 CI 固定測資（fixture）流程。運作數月都很順利——直到一次重構在單一 S3 前綴下新增了 40,000 個測試固定物件。隔天早上的建置在測試設定階段卡住了 90 秒，等待固定物件目錄在 Explorer 中載入。NetDrive 並沒有卡住；它只是為了列舉那一個目錄，正在發出 40 次循序的 S3 API 呼叫。
將 S3 儲存桶掛載為原生 Windows 或 macOS 磁碟機
NetDrive 讓 Google Drive、OneDrive、S3、SFTP、WebDAV 等在 Windows 與 macOS 上顯示為原生磁碟機 — 不需同步，也不需完整下載。
- S3 儲存桶在 Windows 上顯示為 D:、E: 或任何磁碟機代號
- 快取目錄列表，讓首次掛載後的重複存取更快速
- 當上游物件變更時，可強制重新整理特定資料夾
免費試用。提供終身與訂閱方案。
為何 S3 列表比本機檔案系統慢
S3 是物件儲存，而非階層式檔案系統。看起來像是名為 fixtures/integration/ 的資料夾，其實是共用的鍵前綴（key prefix）——數千個剛好以此字串開頭的物件鍵。並不存在真正的目錄。NetDrive（以及其他每一款 S3 掛載工具，包括 rclone 與 ExpanDrive）都是透過呼叫 S3 的 ListObjectsV2 API 來模擬目錄。
問題在於：一次 ListObjectsV2 呼叫最多只會回傳 1,000 個物件。一個持有 40,000 個鍵的前綴，需要 40 次循序 API 呼叫才能完整列舉。以每次往返 S3 端點 50 毫秒計算（在同一 AWS 區域內算合理），這代表在 Explorer 顯示第一個檔名之前，就已耗費 2 秒的純 API 開銷。若經過企業代理伺服器或連往不同區域，這 40 次呼叫可能延長至 30 至 90 秒。
這並非 NetDrive 的臭蟲，而是 S3 API 的合約本質——同樣的行為也會影響 aws s3 ls、rclone 的掛載模式，以及任何列舉大型 S3 前綴的工具。解法落在兩個層面：NetDrive 如何快取目錄列表，以及你如何組織儲存桶結構。
NetDrive 的目錄快取如何降低重複開銷
在首次列出大型前綴之後，NetDrive 會在本機快取該目錄樹。之後任何程序再次瀏覽到 D:\fixtures\integration\ 時，NetDrive 會直接回傳快取的列表，完全不發出 S3 API 呼叫。這個快取會跨工作階段持續存在：即使冷開機重啟後，快取仍保留上一次掛載時的內容，因此就算你整晚重啟了建置伺服器，第二次執行的列表仍是瞬間完成。
快取儲存空間最高可設定至 1 TB（自 NetDrive 3.16.589 起引入）。對於物件數量達數十萬、分散在數十個前綴中的儲存桶，配置更多快取空間能讓更多目錄樹在多次 CI 執行之間保持熱快取狀態。可在 Drive Manager 中該磁碟機的設定裡調整此項。
其代價是資料可能過時。如果同事或上游流程直接透過 AWS 主控台、另一個工具或另一台機器將新物件上傳至 S3，NetDrive 的快取視圖不會反映這些變更，直到快取過期或你手動觸發重新整理為止。若要重新整理特定資料夾：在 Windows Explorer 中右鍵點選該資料夾 → Refresh。NetDrive 會針對該前綴重新發出 ListObjectsV2 呼叫、更新快取，並回傳最新的列表。
能降低列表開銷的儲存桶結構調整
以下調整需要變更你組織 S3 儲存桶的方式，但其效益適用於所有讀取該儲存桶的工具，不僅限於 NetDrive。
扁平化深層前綴階層。 你瀏覽的每一層巢狀結構都會觸發各自的列表呼叫。像 fixtures/integration/service-a/env-staging/2026/05/ 這樣有六層的路徑，在抵達物件之前可能需要多達六次循序 API 呼叫。將其扁平化為 fixtures/integration/service-a-staging-2026-05/，即可用一次列表呼叫存放相同資料並抵達葉層。
依時間或類別分割高基數前綴。 若單一 logs/ 前綴持有 80,000 個物件、橫跨兩年的每日輸出，可拆分為 logs/2025/ 與 logs/2026/。當 NetDrive 列出 logs/ 時，一次 API 呼叫即可看到兩個子前綴。再瀏覽進入 logs/2026/ 時，只需再多一次呼叫，且僅針對該年度。
區隔熱資料與冷資料。 將經常讀取的物件保留在有限範圍的前綴中——例如 fixtures/active/——並將較舊的物件封存至 fixtures/archive/。掛載整個儲存桶、但只讀取 fixtures/active/ 的 CI 流程能快速列出結果；冷封存區則不會被快取，也不會出現在關鍵路徑上。
在磁碟機上設定 Root path。 在 NetDrive 的 S3 連線設定中，Root path 欄位可讓你將特定前綴掛載為磁碟機的根目錄。將其設為 fixtures/active，NetDrive 便會將該前綴視為 D:\。儲存桶其餘部分在整個掛載工作階段中都不會被列出——只會列出工具實際需要的路徑。
確認端點區域是否正確。 在 Drive Manager 中開啟 S3 連線，確認區域與儲存桶所在的實際區域相符。跨區域請求會使每次 API 呼叫增加 50 至 200 毫秒延遲。在 40 次分頁列表呼叫累積下，每次冷開啟目錄就可能白白多花 2 至 8 秒的網路延遲。
總結
S3 目錄列表緩慢幾乎總是儲存桶結構的問題，而非 NetDrive 設定的問題。S3 API 每次呼叫上限 1,000 個物件是固定的；你能控制的是抵達所需物件需要多少次呼叫。扁平化深層階層、分割高基數前綴、設定根路徑以縮小掛載範圍，並讓目錄快取確保重複列表能瞬間完成。
若團隊遇到的是 S3 權限錯誤而非效能問題，請參閱 Fix S3 Access Denied Error with NetDrive。若你的 CI 流程使用 Wasabi 而非 AWS S3，同樣的列表行為依然適用——請參閱 Mount Wasabi on Windows with NetDrive。
— Jay, NetDrive