cp命令被甩了3條街：9.2萬文件復制，他省了379MB和幾分鐘

92,000個文件，超過一半是重復內容，傳統工具照抄不誤。一位系統工程師算了一筆賬：光是機械硬盤的磁頭尋道時間，就能吃掉你幾分鐘。

他把解決方案寫成了一個Python小工具，名字叫fast-copy。沒有華麗的界面，沒有融資新聞，GitHub倉庫里只有一行行解決具體問題的代碼。

磁頭在跳舞，你在干等

用cp -r復制大量文件時，讀取順序跟著目錄走。目錄順序和磁盤物理布局是兩回事——對機械硬盤來說，這意味著磁頭要在盤片上跳來跳去。

每次尋道5-10毫秒，乘以6萬個文件，純浪費在機械動作上的時間就能積成幾分鐘。

fast-copy的做法是：復制前先摸清底細。Linux上用FIEMAP（文件區段映射接口），macOS用fcntl，Windows用FSCTL，把每個文件的物理磁盤偏移量讀出來。然后按塊位置排序，順序讀取。

這個思路并不新鮮，數據庫優化領域管這叫"順序I/O優化"。但把它塞進一個隨手能用的文件復制工具里，是另一回事。

重復文件：抄作業還抄三遍？

系統工程師的日常充滿了重復。node_modules在不同項目間復制，緩存文件躺在各個角落，備份副本層層堆疊。fast-copy用xxHash-128（或者降級到SHA-256）給每個文件算指紋。

指紋相同的只存一份，其他的用硬鏈接（hard link）指過去。92,000個文件的測試里，重復文件超過半數，省了379MB空間和對應的讀寫時間。

更實用的是SQLite數據庫。往同一個目的地復制第二次時，工具會查表跳過已存在的文件。增量備份場景下，這省下的不只是時間，還有對SSD壽命的消耗。

SSH傳輸：繞過SFTP的協議稅

遠程復制是另一個痛點。SFTP方便，但協議開銷顯著。fast-copy的做法更粗暴：直接走原始SSH通道，把文件打包成約100MB的tar批次流過去。

遠端執行tar xf -，文件直落磁盤，沒有臨時文件，沒有SFTP握手。某些禁用了SFTP的Synology NAS配置，這條路反而能走通。

作者放出了三組測試數據，都是92,000個文件的場景：

本地復制到USB，遠程到本地走LAN，以及純本地操作。數字本身因硬件而異，但模式很清晰——順序讀+去重+增量跳過，三層優化疊在一起。

用法也極簡：python fast_copy.py /source /destination。不想裝Python的，Release頁有獨立二進制文件，Linux、macOS、Windows全覆蓋。

需要SSH功能就裝paramiko，想加速哈希就裝xxhash。都是可選依賴，核心功能零依賴。

這個項目掛在GitHub上，Apache 2.0協議。作者留了一句話：「特別想聽聽那些處理大文件傳輸或備份流程的人反饋——你現在用什么工具？它們缺了什么？」

這個問題拋給讀者。你的備份腳本里，有多少時間花在磁頭尋道和重復文件上？