WordPress图片不显示主因是迁移后\_guid字段仍为旧域名绝对路径，但实际应优先修复post\_content中的src链接和附件元数据，而非直接批量修改\_guid，以免破坏UUID或RSS功能。
WordPress图片不显示是因为_guid存了旧域名绝对路径
媒体库里图片缩略图和文章内图片全挂了，但文件本身还在服务器上——大概率是迁移站点或更换域名后，_guid字段还锁着老地址（比如http://old-site.com/wp-content/uploads/2023/01/photo.jpg），而wordpress现在用的是新域名。浏览器直接请求这个旧url，404就完事了。
注意：_guid不是用来前端展示的字段，它是RSS、导入导出、某些插件识别资源的唯一标识。强行改它可能影响订阅源或第三方同步，但对纯网站浏览来说，只要post_content里的图片链接正确，_guid错位只会影响后台预览和部分API行为。
别直接UPDATE _guid，先确认哪些记录真要动
很多教程一上来就UPDATE wp_posts SET guid = REPLACE(guid, 'old.com', 'new.com')，这很危险。因为_guid里混着非URL内容：比如自定义文章类型、页面、甚至草稿的guid可能是http://old.com/?p=123这种结构，也可能是urn:uuid:xxx格式——批量REPLACE会把UUID里的old字母也干掉。
- 只处理
post_type = 'attachment'的记录，其他类型别碰 - 只改以
http://或https://开头、且包含旧域名的_guid值 - 执行前务必备份数据库，哪怕只是
mysqldump导出wp_posts表
安全SQL示例（替换前先查）：
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
SELECT ID, guid FROM wp_posts WHERE post_type = 'attachment' AND guid LIKE 'http://%old-site.com%';
用wp_update_attachment_metadata()重生成更稳妥
硬改_guid治标不治本。WordPress真正决定图片怎么显示的，是附件元数据里的file路径和url字段。只要这些对，后台预览和前台输出都能恢复。而wp_update_attachment_metadata()会根据当前upload_path和upload_url_path重新生成url，顺便把_guid按当前站点URL刷新（仅对attachment有效）。
- 适合已上传但
_guid错乱、且文件物理路径没变的场景 - 在WP-CLI中批量执行最省事：
wp post list --post_type=attachment --format=ids | xargs -d ' ' -I {} wp post meta update {} _wp_attached_file "$(wp post meta get {} _wp_attached_file)"（先刷一次元数据触发重建） - 如果
upload_path配置错误（比如还是指向旧服务器路径），得先修正wp_options表里的upload_path和upload_url_path
前端图片仍不显示？检查post_content和srcset
_guid修好了，但文章里图片还是404？那问题根本不在_guid，而在正文HTML里写死的src或srcset属性。WordPress不会自动更新这些字段——它们是用户编辑时手动插入或由编辑器生成的静态字符串。
- 用SQL批量修复正文链接：
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://old-site.com', 'https://new-site.com')，但必须加WHERE post_type IN ('post','page','custom_post')限制范围 -
srcset里的多尺寸URL也要单独处理，否则响应式图片仍失效；可以用正则替换工具（如wp search-replace）一次性扫清 - CDN开启后，有些缓存插件会把
src替换成CDN域名，此时要确认CDN回源是否指向新站，而不是继续找旧域名
最麻烦的情况是：数据库里_guid、post_content、附件元数据三处URL全部混着新旧地址。这时候得按优先级来——先保post_content和附件元数据，_guid能不动就不动，除非你明确要用到RSS或跨站导入。
