上传图片提示‘后处理失败’，媒体库却还能看到图，可能是原图已传上去，小尺寸没有生成。后处理就是上传后读取图片、缩放并保存不同尺寸，文章列表和特色图可能需要这些小图。
围绕同一张图，分别检查原图、尺寸清单、实际小图文件和文章里真正加载的图片。先让运营在界面里找到对象和报错，再由维护者补缺失尺寸。别急着重传：新上传可能得到新编号，旧文章仍用原来的图。
先找到原图，别急着重复上传
进入后台‘媒体 → 媒体库’，按文件名或上传日期找到原来那张图，点缩略图打开详情。查看格式、宽高和上传时间，点‘复制URL到剪贴板’，在新标签打开文件地址，确认返回正确图片。详情字段可对照媒体库说明。
点详情中的‘编辑更多详情（Edit more details）’，保存这个编辑链接。常见地址中 post= 后的数字就是媒体编号；不会判断时，把链接交维护者即可。本文以编号2401为教学例子，不是真实故障媒体。
刷新详情或编辑页，确认同一条媒体记录还在。WordPress 把它称为附件，意思是媒体库中这条记录，和服务器上的图片文件不是同一个对象。只在上传目录找到文件，不能说明库里还有可处理的编号；REST（后台通信接口）受限也不能反过来证明记录消失。
再打开原本使用这张图的文章，记下缺的是列表小图、特色图还是正文图，保留页面地址、报错原文和时间。库里能预览，不代表所有尺寸都在；预览可能借用了另一份图。
曾经上传后又找不到记录时，让维护者检查是否上传未完成或执行过清理。WordPress 5.3 的上传流程说明记录过后处理重试和最终清理，但不能假定所有当前版本、插件都是同一流程。引用与删除问题可另看媒体库整理。
原图和小图，要检查三件事
需要维护者把三项放在一起看：站点当前要求什么尺寸；这张图的记录里写了什么尺寸；对应文件是否真的存在并能打开。
‘注册尺寸’是主题或插件告诉 WordPress 要生成的规格；媒体记录中的 sizes 是这张图已经记下的尺寸清单，包含文件名和宽高。清单写着有 large，文件仍可能被删；站点有 large，这张图也可能还没生成。
继续用2401说明。假设原图1600×1000，已有 thumbnail、medium 的记录和文件，large 的上限是1024×1024、不裁切，但清单里没有它。保持原比例缩小，目标应是1024×640；这一项值得检查和补生成。
另一个 hero-wide 上限2400×1200，也不裁切，两边都大于原图。原图已经在这个范围内，不需要为了凑齐名称强行放大。主题采用裁切时结果另算，不能照搬这个尺寸例子。
清单缺了能生成的尺寸，查生成是否中断；清单有文件名、实际文件没了，查文件恢复；服务器文件能开、文章里的网址失败，查页面引用或CDN（图片分发服务）。三种情况下一步不同，不是全部重生成就能解决。
普通编辑先做这些检查
打开‘工具 → 站点健康 → 信息’，展开‘媒体处理’和‘服务器’，把有关图片处理库与上传限制的信息交维护者。站点健康显示信息，不能在这里直接修这些设置。GD、Imagick 是服务器用来读图、缩放和保存的处理库。
可以先上传一张已知正常的小图作对照，再用同格式的问题图比较；需要缩小像素测试时，保留原文件，另导出副本，不覆盖原素材。记住每次新样本有自己的编号，不能把小图上传成功当成旧图已经修好。
文件只有几十 KB，宽高仍可能很大，解码后的处理负担也可能高。上传体积、像素尺寸和处理资源分别看。报错提到2560像素，也不等于固定上传上限；大图处理阈值可改，缩到这个数字并不保证成功。
交接可以直接写：‘这张图的编辑链接和文件URL在这里，上传时间是几点，宽高和格式是什么，这篇文章的列表图不显示。请先查少了哪个尺寸，只处理这张图，再把目标文件地址给我。’运营不需要先自己找到服务器日志才能求助。
维护者按同一时间查图像库、PHP、写入目录或转换插件的具体错误，再调整有依据的一项。资源不足查实际限制，不能保存查目录或存储凭据，格式转换失败查相应插件。别用开放全部写入权限或关闭所有小尺寸来绕过错误。
本篇的服务器检查适用于服务器生成尺寸的路线。客户端媒体架构还描述在浏览器处理、再上传尺寸的路线；当前版本或插件启用这类处理时，先看是谁生成、哪次请求失败，不能统一提高 PHP 内存。命令行与网页也可能使用不同配置，CLI成功还要复测网页。
维护者怎样只补这一张图
下面由有服务器或工具权限的维护者执行。先准备可恢复的媒体记录、原文件和相关小图备份，确认处理环境能读到源图。图片已迁到对象存储且本地原件被清理时，按存储插件流程取得可处理文件，不因本地缺文件就删除媒体记录。
在正确站点执行以下只读查询，2401换成真实编号；多站点需指定正确目标站。主题和插件正常加载，才能列出实际在用的自定义尺寸。
wp media image-size --format=json
wp post meta get 2401 _wp_attached_file
wp post meta get 2401 _wp_attachment_metadata --format=json
第一条列当前尺寸规格，第二条读文件位置，第三条读这张图的尺寸记录。可对照 image-size 和 post meta get。在 sizes 中找到目标的 file、width、height，再检查对应文件和存储URL。
先修生成条件。确认本图缺 large 登记、原图又能生成它时，可限定一个编号和一个尺寸：
wp media regenerate 2401 --image_size=large --only-missing --skip-delete
如果 large 已登记，但文件丢失或损坏，确认源图与当前工具能力后，可定向重生成：
wp media regenerate 2401 --image_size=large --skip-delete
选项见 media regenerate。两条都会写图片或更新记录，不是只读。--skip-delete 保留旧缩略文件，也不保证同名文件永不覆盖；不要增加删除未注册尺寸的选项，仍被旧文或外部网址引用的文件需要保留。
‘缺尺寸’还有工具差别。核心 wp_get_missing_image_subsizes()按清单中的尺寸名称比较，不逐个查磁盘，也不会仅因同名规格改变就视为缺项；返回空不能证明文件完整。本次查阅的 WP-CLI 源码还有尺寸差异和本地文件检查，实际行为按安装版本及存储方式确认，不能把两个工具当成同一种判断。
缺源图、没有可用图像处理库或再次报错时，保留输出，先修这张图，不扩大到全库。也不要为加速跳过主题和插件，导致注册尺寸、转换或存储流程变了。
没有SSH的运营，把本节任务交给维护者即可。使用重生成插件时，也要确认它支持单张和所需保留选项，先做这一张，再返回目标文件结果。原编号保留了，按编号引用的文章才能继续找到它；固定文件网址的旧文仍要检查旧文件是否可用。
回到文章看图片，再复测网页上传
处理后重新打开2401的记录，查看 sizes.large 是否有实际文件名，宽高是否符合本例1024×640，打开那个文件确认是正确图片。原图和仍在用的旧尺寸也应保留。命令显示成功只是执行结果，还没查文章。
运营再打开使用这张图的原文章，在桌面和手机宽度分别看列表图、特色图或正文中原来失败的位置。维护者在浏览器 Elements 选中相应 img，查看 currentSrc，即浏览器本次选中的图片网址，再在 Network 找对应请求，确认实际加载成功。currentSrc有值也可能加载失败，旧缓存还可能掩盖断图。
目标文件能打开，页面仍请求坏旧地址时，查文章或模板引用；仍下载不合适的原图时，请维护者查看网页 img 元素的 srcset（候选图片）和 sizes（显示宽度规则），再查CDN缓存。这里的 sizes 是网页属性，与前面媒体记录里的尺寸清单不同。可继续看图片优化与实际取图。这个时候反复重生成未必会改变页面地址。
最后再走当初报错的网页上传入口，用同格式、像素接近原失败图的受控样本，经过相同插件处理。记新样本编号，确认上传与后处理请求完成，目标尺寸登记了，对应文件也能打开。
已知小图成功只是对照。接近失败条件的新样本通过，才说明这次网页复测没有再出现相同错误，也不代表所有格式、更大像素或更高负载都正常。旧图补好和新上传恢复要分别检查。
缺文件继续找生成或存储维护者；源文件能开而CDN地址失败，找存储/CDN负责人；文件正常但页面地址错，找文章或模板维护者。需要协助，可把原图编辑链接、报错和受影响页面提交给跨境YOUNG。
常见问题
媒体库里的「完整尺寸」为什么不总是我上传的原图？
WordPress 可能把缩小后的 -scaled 文件作为 full，并另保留原始上传文件。核心大图处理包含这一流程，阈值可以调整。需要备份原素材时，让维护者确认原上传文件位置，不只保存full网址。
浏览器能打开 WebP 或 AVIF，为什么服务器仍处理失败？
浏览器负责显示，服务器图像库负责读取、缩放和保存，支持能力可能不同。查看媒体处理中的实际库和版本，再用同格式样本让维护者查错误。只允许上传这个扩展名，不能补上服务器缺少的编码支持；客户端处理路线另按实际请求判断。
主题改了图片尺寸，重生成后旧文章会全部自动换成新图吗？
不一定。模板按媒体编号取图，和旧正文固定保存一个文件网址，是两种方式。先检查一篇旧文实际加载地址、新规格文件及画面。保留仍使用的旧文件，确认这篇的结果后再决定是否更新固定引用。