為什麼你的 WordPress uploads 資料夾這麼肥大
你的 WordPress uploads 資料夾之所以肥大,是因為 WordPress 從來不會一張圖片只存一個檔案。每次上傳都會在原圖旁邊產生一組固定數量的縮放副本
發布於
你的 WordPress uploads 資料夾之所以肥大,是因為 WordPress 從來不會一張圖片只存一個檔案。每次上傳都會在原圖旁邊產生一組固定數量的縮放副本——以一張相機尺寸的照片來說就是七個,這還沒算上任何佈景主題或外掛額外新增的。沒有任何檔案損毀;你看到的只是每一次上傳都會發生的倍數增長。解法是停止產生那些你根本不會用到的尺寸,然後重新產生,讓舊副本從磁碟上被刪除。
算一下數字
上傳一張 4000×3000 的 JPEG,然後打開 /wp-content/uploads/2026/07/ 看看。你不會只找到一個檔案,而是會找到這些:
photo.jpg— 原圖,未經處理photo-scaled.jpg— 一個 2560px 的副本,WordPress 會用它取代原圖來輸出photo-150x150.jpg—thumbnailphoto-300x225.jpg—mediumphoto-768x576.jpg—medium_largephoto-1024x768.jpg—largephoto-1536x1152.jpg— 2× 的medium_largephoto-2048x1536.jpg— 2× 的large
這就是原圖再加上七個衍生檔,而且光是核心就這樣了。一個 3 MB 的上傳,在任何外掛執行之前就可能在磁碟上佔掉 5–6 MB。現在再加上一個自己註冊了四種尺寸的佈景主題,以及 WooCommerce(再多三種),一次上傳就變成十四或十五個檔案。乘上一個有幾千張圖片的媒體庫,資料夾的大小就不再是個謎了。
如果你想針對自己的尺寸和已註冊的尺寸算出確切數字,圖片儲存空間計算機會幫你把乘法做完。
為什麼會這樣
當你上傳時,wp_generate_attachment_metadata() 會呼叫 wp_create_image_subsizes(),它會走過 get_intermediate_image_sizes() 回傳的每一種尺寸,並為每一種原圖大到足以產生的尺寸寫入一個檔案。核心會註冊 thumbnail、medium、medium_large、large,再加上 WP 5.3 新增的 1536x1536 和 2048x2048 視網膜尺寸。任何呼叫 add_image_size() 的佈景主題或外掛都會加進同一個迴圈——而且是永久性的,對之後每一次上傳都適用。
-scaled 檔案來自另一個機制:big_image_size_threshold 過濾器,預設為 2560px。任何寬度超過的圖片都會得到一個縮放副本,成為被輸出的「full」圖片,而原圖則留在磁碟上。所以一張大圖會同時保留巨大的原圖和 2560px 版本。
你可以用圖片尺寸檢查工具看看你的設定針對某張圖片究竟會產生哪些檔案。
該怎麼修,照順序來
**1. 動手之前先量測。**用猜的只是浪費時間。從網站根目錄執行:
du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20
**2. 取消註冊你不會輸出的尺寸。**大多數佈景主題從不輸出 1536 和 2048 尺寸,很多也從不使用 medium_large。把它們拿掉:
// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
remove_image_size( '1536x1536' );
remove_image_size( '2048x2048' );
} );
// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
unset( $sizes['medium_large'] );
return $sizes;
} );
**3. 重新產生以刪除舊副本。**取消註冊只會停止未來的產生——已經在磁碟上的檔案會一直留著,直到你重新產生:
wp media regenerate --yes
較新版本的 WP-CLI 會在執行過程中,一邊刪除那些已經不再註冊的尺寸的檔案。如果你用的是 Regenerate Thumbnails 外掛,請勾選它的「delete unregistered sizes」選項——沒勾這個框,舊檔案就會留下來。
**4. 找出孤兒檔案。**切換佈景主題絕不會清理舊佈景主題註冊過的尺寸。刪除文章也不一定會移除它們的衍生檔。做完步驟 3 之後,如果 du -sh 仍然遠高於計算機預測的數字,你就有孤兒檔——磁碟上沒有任何附件參照到的檔案。
不該做的事
不要為了「省空間」而停用縮放圖片。-scaled 檔案其實比你的原圖更小。關掉 big_image_size_threshold 不會刪掉任何東西——它只會讓 WordPress 把那張好幾 MB 的完整原圖輸出給每一位訪客。這是頻寬和畫質的決定,不是儲存空間的清理,而且通常會讓頁面體積更糟。停用縮放圖片工具說明了什麼情況下這麼做才真的正確;縮小你的 uploads 資料夾並不是其中之一。
**不要透過 SFTP 直接從 uploads 刪除檔案。**每個附件的子尺寸清單都存在它的 _wp_attachment_metadata 裡。手動刪除檔案會留下失效的參照,而且如果你移除了衍生尺寸所依據的原圖,重新產生也無法重建那個尺寸。刪掉原圖,那張圖就永遠沒了。
**不要以為在「設定 → 媒體」把 thumbnail/medium/large 設成 0 資料夾就會縮小。**把某個尺寸歸零只會停止未來的產生,卻動不了任何已經在磁碟上的東西,而且這個介面根本碰不到 medium_large、1536、2048 或任何佈景主題/外掛的尺寸——那些選項不在那裡。
**不要怪罪資料庫。**肥大的 uploads 資料夾裝的是圖片檔案,幾乎絕不會是資料庫。最佳化資料表不會讓那個數字有任何變化。
還是卡住了?
如果重新產生之後資料夾仍然比預期大,把你真實的圖片尺寸和已註冊的尺寸輸入儲存空間計算機,再把它的數字和 du -sh wp-content/uploads 比對。差距很大,代表有來自舊佈景主題或已刪除文章的孤兒檔——不是核心造成的,也不是再多重新產生幾次就能解決的。差距很小,代表這個數學就是這麼一回事:每次上傳七個以上的檔案,完全按照設計運作。