WordPress 搬家后图片显示不出来，最快的解决方式不是把整站重新打包上传一遍，而是先判断到底坏在哪一层。文件真的丢了只是其中一种可能，更多时候是地址、权限或缓存中的一环还没跟上新服务器。
下面按真实排查顺序给出四条路径：数据库与站点地址、uploads 目录同步、缓存与 CDN（内容分发网络）、缩略图与插件残留。每一步都附可直接执行的命令和判断标准，帮助你把问题解决在定位阶段。
第一步：先判断坏在哪一层
打开任意一篇图片异常的页面，右键点击破图并复制图片地址，交给命令行查一次，就能把范围从“整站坏了”缩小到“某一层坏了”。
curl -sI "https://www.example.com/wp-content/uploads/2025/11/photo.webp" | head -5返回结果基本只有三类，每一类对应完全不同的修法：
- 返回 404：文件确实不在新服务器上，或路径大小写对不上。Linux 区分大小写，
Photo.JPG与photo.jpg是两个文件。 - 返回 200 但 Content-Type 是 text/html：请求被重写规则拦到了首页，图片根本没落到磁盘上，最容易被误读成“图片还在”。
- 浏览器报 Mixed Content：页面是 https，图片地址仍是 http，被浏览器直接拦下。此时 curl 请求往往仍返回 200，服务端本身是通的。
再确认图片地址的域名来自哪里，抓页面源码过滤 URL 前缀：
curl -s "https://www.example.com/2026/03/sample-post/" | grep -o 'https\?://[^"]*wp-content/uploads' | sort | uniq -c | head出现旧域名、旧 IP 或 http:// 前缀，根因就在数据库或配置，直接跳到路径一；输出是干净的 https 新域名，说明问题在文件或缓存。
路径一：数据库和配置里还留着旧域名
WordPress 把站点地址存在数据库里，正文中的图片地址也常带域名。换服务器后域名或协议一变，这些绝对地址立刻变成死链。
先查两处，命令很短，但结论很硬：
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%//old-domain.com%';"第一条若仍返回旧域名，先在后台“设置 – 常规”里改掉，或直接在 wp-config.php 里加 WP_HOME 与 WP_SITEURL 常量强制覆盖；第二条返回数字大于零，说明正文里写死了旧域名，需要做一次全库替换。
替换不建议直接写 SQL。主题设置、小工具、插件配置多以 PHP 序列化数组存储，数组带着字符串长度，直接 UPDATE 会把长度字段改坏，页面正常而设置整体失效。用 WP-CLI 先空跑再执行：
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --precise --dry-run--precise 会按序列化结构重算长度，--dry-run 只输出将被修改的行数，不动数据。空跑结果值得逐张对一遍，尤其是 wp_postmeta：页面构建器和主题的图片字段常藏在这里。
有一个字段要特殊对待：wp_posts.guid 不要改。它只是文章的唯一标识，订阅器和第三方抓取工具把它当 ID 使用，改动之后容易被当成新内容重复抓取。域名切换本身属于另一件事，如果你还没完成解析切换，先看《网站搬家 不停机迁移完整指南》里关于 DNS（域名解析系统）记录与 TTL 的准备步骤，那部分做对了，这里的替换才不会反复返工。
路径二：uploads 目录没同步全，或者权限不对
数据库地址都对，图片还是 404，就往文件系统看。搬家最典型的情况是同步中断：rsync 跑到一半网络抖了一下，原图传上去了，缩略图和当年上传的其它月份目录没跟上。
最直接的判断是对比两边的文件数量，同一个命令在旧服务器和新服务器各跑一次：
find wp-content/uploads -type f | wc -l两边数字差几十个以内属于正常波动（缓存文件、临时文件），差几百个就说明同步确实没跑完。补同步时首次不要加 --delete，先确认新服务器上没有本地生成的新文件，再考虑清理：
rsync -avz --progress /var/www/old/wp-content/uploads/ user@new-host:/var/www/new/wp-content/uploads/文件齐了还打不开，看权限和属主。目录应为 755、文件 644，属主须与 PHP 运行用户一致，Debian/Ubuntu 上通常是 www-data。权限错返回 403，文件缺失返回 404，第一步的 curl 结果就能分开这两种情况：
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;
chown -R www-data:www-data wp-content/uploads如果新主机是 Hostease 的[虚拟主机](https://cn.hostease.com/shared-hosting.html)或 [VPS](https://cn.hostease.com/vps/)（[虚拟专用服务器](https://cn.hostease.com/vps/)），上传目录一般在账户下的 public_html/wp-content/uploads，面板的文件管理器就能核对文件数与属主。整站打包与还原的完整步骤见《LEMP 环境整站迁移：旧服务器打包 WordPress 到新主机全流程》，其中的排除规则能避免把旧缓存目录一起搬来。
路径三：缓存和 CDN 还在发旧内容
数据库改完、文件也齐了，图片依旧 404 或显示旧图，问题就落在缓存层。典型现象是 CDN（内容分发网络）边缘节点缓存了旧源站返回的地址，甚至缓存了一次 404 响应，之后源站怎么修，节点都按 TTL 继续返回旧结果。
先确认命中的是缓存而不是源站。响应头里的几个字段足够判断：
curl -sI "https://www.example.com/wp-content/uploads/2025/11/photo.webp" | grep -Ei "cache|age|via|server"看到 x-cache: HIT 或一个很大的 age 值，就说明内容来自缓存。清理要针对图片 URL 本身，图片是独立缓存键，刷首页不会让它们失效。在控制台全量 purge 或按目录 /wp-content/uploads/* 刷新，再回到第一步复测。
页面级缓存插件是另一个来源。它缓存完整 HTML，如果这份 HTML 生成于域名替换之前，里面写的就是旧图片地址。顺序必须先改数据库再清缓存，反过来等于把旧地址重新缓存一遍。
混合内容问题不体现在状态码上：页面是 https，主题设置里写死的图片仍是 http。批量扫一遍正文和元数据里的 http 地址统一改成 https://，同时确认站点的 SSL（安全传输协议）证书安装正确、证书链完整。
缓存配置本身如果还没理顺，把缓存键、回源规则和 TTL 设对能省下后面大量返工时间，具体思路见《外贸网站 CDN 加速：解决国内访问慢的缓存层配置完整思路》。
路径四：缩略图和 WebP 插件留下的坑
有一种情况很容易被忽略：原图能打开，列表页和文章内的缩略图 404。这时去看地址，往往形如 photo-300x200.webp 或 photo-scaled.webp——这类派生文件由 WordPress 和各尺寸设定生成，不属于原始上传文件。
搬运时只同步了原图、或迁移脚本按扩展名过滤过，派生文件就会缺失。另一个原因是 WebP 插件：旧服务器转过副本，新服务器没启用同名插件，HTML 却仍指向那些后缀。
先用 WP-CLI 看缺失规模，再决定是重新生成还是补同步：
wp media regenerate --only-missing --yes
wp post meta list 123 --format=count重新生成会按当前主题注册的尺寸重建，几千张图片通常要跑十几分钟。图片量大的站点更稳妥的做法是让新旧服务器保持相同的优化插件与尺寸设定，再补一次 --only-missing，避免全量重跑。图片格式与懒加载的配置可以参考《网站图片体积优化：WebP 批量转换与懒加载配置实战》，清理孤儿附件和无效缩略图的步骤则在《WordPress 媒体库清理：孤儿附件与缩略图再生服务器实操》里有更细的命令清单。
按这个顺序排查，通常半小时内能定位
四条路径之间有前后依赖，顺序错了会做无用功：
- 用
curl -sI确认图片地址的 HTTP 状态与 Content-Type，区分 404、200-HTML、Mixed Content 三类症状。 - 查
wp_options的siteurl、home与正文里的旧域名，用wp search-replace --dry-run核对影响行数后再执行。 - 对比新旧主机
uploads的文件数、目录与文件权限，把缺失的派生文件和月份目录补齐。 - 最后清页面缓存与 CDN 缓存，重新生成缺失缩略图，再回到第一步复测同一个图片 URL。
关键在最后一步：先清缓存后改数据库，等于把旧地址的 HTML 又缓存了一遍，这也是有些站长改完之后“过一会儿又坏了”的原因。
搬家前值得固化的三个习惯
排查能救急，真正省时间的是把风险提前挡掉。这三件事写进迁移清单，下一次搬家基本不会遇到同样的破图：
- 迁移前记录基线：
find wp-content/uploads -type f | wc -l的文件总数、wp_posts行数、启用插件清单各存一份，搬完逐项对比，缺多少一目了然。 - 主题和页面构建器里用
wp_get_attachment_image()输出图片地址，不要把完整域名写进模板或自定义字段，否则换域名会同时坏掉几百个页面。 - 保留旧站 7 到 14 天，切换前把 DNS（域名解析系统）记录的 TTL 调到 300 秒左右，出问题能先切回去，不必在深夜硬扛。
总结：图片问题多半不是图片本身的问题
把搬家后的破图当成一次分层验证，而不是一次文件事故：地址层看数据库与配置，文件层看 uploads 的完整性和权限，缓存层看 CDN 与页面缓存，派生层看缩略图和格式转换插件。按顺序排查，通常两三次 curl 就能定位。
我们的建议是把这条四层流程和三项基线记录一起存进迁移清单，下次换服务器直接照着走。如果你需要更省心的做法，可以考虑带数据迁移协助的主机方案，Hostease 中文站的虚拟主机与 VPS 产品在迁移期提供文件与数据库搬运支持，域名替换和缓存清理仍建议自己掌握，出问题时才知道卡在哪一层。