为什么你的 WordPress uploads 文件夹这么大

WordPress 的 uploads 文件夹之所以大，是因为 WordPress 从不只为一张图片保存一个文件。每次上传都会在原图旁边生成一组固定的缩放副本——对于一张典型的相机尺寸照片来说是七个，这还没算上主题或插件额外生成的。没有任何东西损坏；你看到的只是每次上传都会发生的成倍增长。解决办法是：不再生成那些你根本用不到的尺寸，然后重新生成一次，让旧副本从磁盘上删除。

算一算

上传一张 4000×3000 的 JPEG 图片，然后进 /wp-content/uploads/2026/07/ 里看看。你不会只找到一个文件，而是会找到这些：

• photo.jpg —— 未经改动的原图
• photo-scaled.jpg —— 2560px 的副本，WordPress 会用它代替原图对外提供
• photo-150x150.jpg —— thumbnail
• photo-300x225.jpg —— medium
• photo-768x576.jpg —— medium_large
• photo-1024x768.jpg —— large
• photo-1536x1152.jpg —— 2 倍的 medium_large
• photo-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 两种高清（retina）尺寸。任何调用 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 插件，请勾选它的“删除未注册尺寸”选项——不勾上这个框，旧文件就会保留下来。

**4. 排查孤立文件。**切换主题从来不会清理旧主题注册的那些尺寸。删除文章也未必总能删掉它们的衍生文件。做完第 3 步后，如果 du -sh 仍然远高于计算器的预测值，那你就有孤立文件了——磁盘上没有任何附件引用的文件。

不要做的事

不要为了“省空间”而禁用 scaled 图片。-scaled 文件比你的原图更小。关掉 big_image_size_threshold 什么都删不掉——它只会让 WordPress 把那个好几兆字节的完整原图提供给每一位访客。这是关于带宽和画质的取舍，不是存储清理，而且通常会让页面体积更糟。禁用 scaled 图片工具会说明什么时候这样做才真正合适；而缩小你的 uploads 文件夹并不是其中之一。

**不要通过 SFTP 直接从 uploads 里删文件。**每个附件的子尺寸列表都保存在它的 _wp_attachment_metadata 里。手动删文件会留下失效的引用，而且如果你删掉了某个尺寸所依据的原图，重新生成就无法重建这个尺寸。删掉原图，这张图片就彻底没了。

**不要指望在“设置 → 多媒体”里把 thumbnail/medium/large 设为 0 就能让文件夹变小。**把某个尺寸清零只会阻止今后的生成，对磁盘上已有的东西毫无影响，而且界面根本触及不到 medium_large、1536、2048 或任何主题/插件的尺寸——那里没有它们。

**不要怪数据库。**臃肿的 uploads 文件夹里是图片文件，基本上从来不是数据库。优化数据表并不会让这个数字变动。

还是没解决？

如果重新生成之后文件夹仍然比预期大，就把你真实的图片尺寸和已注册的尺寸放进存储计算器算一遍，再把它给出的数字和 du -sh wp-content/uploads 作对比。差距很大，意味着来自旧主题或已删除文章的孤立文件——不是核心程序造成的，再怎么重新生成也解决不了。差距很小，意味着这个数就是这么算出来的：每次上传七个以上的文件，完全是按设计正常运作。