WordPress 保存失败怎么办？先保稿，再查报错

先保住未保存的文字，再检查保存请求，最后重新打开原文章确认新增段落。普通编辑先完成前两节；仍失败时，可照第三节取信息交给维护者，不必自己改服务器。

先把屏幕上的稿件保存到本地

将标题、正文、重要图片说明和链接另存到工作文档，含客户资料的内容放在受控位置。不要指望自动保存已经包含最后几段，也不要关闭报错的编辑标签。

记下当前编辑网址、报错原文、发生时间，以及点击的是保存草稿还是更新。常见编辑网址中 post= 后面的数字是文章编号，交编辑网址也能让维护者找到同篇。

再注明本次新增在哪里。比如你刚写了配送说明，旧版没有这段，后面就用它判断是否保存成功。先和同时编辑的人确认由谁继续操作，避免两个人恢复保存时互相覆盖。正常操作入口可看后台基础指南。

整个后台都打不开时，保好眼前文字，把地址和报错交维护者恢复入口。下面针对编辑器仍打开、保存失败的情况。

开新标签确认登录，核对同一篇文章

另开一个浏览器标签，进入同一个站点的后台；若要求登录，使用原来有编辑权限的账号登录。旧标签先留着，不从未备份的编辑器直接退出。

登录后到‘文章 → 所有文章’找到原文，或使用刚才保存的编辑链接打开同篇。比较后台文字与本地文档：新增配送段已经在，说明至少这一段已保存；没有，再从备份补回。

不要把本地旧备份整篇粘过去。先保留后台已经存在的新内容，只补未保存的目标段落，核对图片说明和链接后再保存一次。其他人已经改过时，先合并差异，不能用自己手里的旧文覆盖。

保存成功就跳到最后的重开检查。仍报错，停止连续点击，记下这次操作。后台页面一直开着，不代表登录和请求校验永远有效；WordPress 的认证说明解释了登录 Cookie、请求校验值和操作权限的要求。

仍失败时，找到这一次保存请求

区块编辑器保存时，会向后台发送请求。REST 是它与 WordPress 通信的一种方式，机制见官方 REST API 文档。请求记录能说明这次保存到达哪里、后台返回什么，比只看弹窗更有用。

正文已备份后，按下面步骤操作：

1. 在 Windows 浏览器按 F12，打开开发者工具，选择 Network，即网络面板。
2. 勾选 Preserve log（保留日志），需要时选 Fetch/XHR 缩小到后台通信请求。
3. 只点一次保存或更新，在列表中找这个时刻出现的请求。普通文章常见地址含 wp-json/wp/v2/posts/ 和文章编号；页面或插件内容可能用别的地址。
4. 点开对应请求，选 Headers（标头），记请求地址、方法、状态码及 Content-Type；再选 Response（响应）看返回内容。

状态码如403、404、500是服务器返回的结果编号。JSON 是程序读取的数据格式，HTML 常是一整张网页。编辑器期待 JSON，却收到登录页、安全拦截页或错误网页，就可能提示‘无效 JSON’。

先找与这篇文章和这次点击对应的请求，红色记录不一定就是保存正文的那条。还要看最终地址是否到了旧域名、HTTP 地址或登录页，不能只记最初的请求地址。

没有任何新请求时，先确认按钮是否可点、网络是否连接；让维护者看 Console（控制台）的脚本错误。请求没有发出时，服务器未必能找到这次保存。

交接只保留时间、文章编辑地址、请求路径、状态和脱敏错误。不要发登录 Cookie、X-WP-Nonce、授权头或整篇私密正文；这些可能包含登录校验或业务信息。不熟悉请求面板时，可由维护者在受控会话中取这些信息。

维护者按返回内容查原因

看到401或403，先看 Response，不急着升账号权限。返回 WordPress JSON 错误、含 code 和 message 等字段时，按实际原文查登录、请求校验值和该账号对这篇文章的权限。nonce 可以理解为随请求带的校验值，失效时可能需要重新登录和打开编辑器。

同样是403，返回主机安全产品、CDN或 WAF 的一整张拦截页，则要查安全环节。CDN 是站点前面的分发服务，WAF 是检查请求的防火墙；它们可能在到达 WordPress 前就拦了保存。把拦截标识、路径和时间交负责安全规则的人，找到对应记录再调整具体规则，别关闭全部防护。

例如，同一篇配送文保存返回403：一条响应写的是 WordPress 的权限或校验错误，另一条却是主机的 Forbidden 网页。前者先查账号与登录，后者先查安全拦截。这是两种说明用的情况，不是本篇做过真实后台测试。

可以对照下面两个最小样本看“格式”差别，具体错误仍以本站返回为准：

教学样本一：403，Content-Type: application/json {"code":"rest_cookie_invalid_nonce","message":"Cookie check failed","data":{"status":403}} 教学样本二：403，Content-Type: text/html <p>Request blocked</p>

第一个把调查引向登录及请求校验，第二个需要查哪个环节返回了拦截网页；HTML也可能是其他代理或错误页，不能只按外观指认某个产品。交维护者时可以只写：10:32｜原文编辑ID｜POST /wp-json/wp/v2/posts/该ID｜403｜JSON错误code。不要把整包请求头或私密正文一起发出去。

返回404时，先确认文章编号和路径正确，再查最终地址、跳转、REST 路由和服务器重写。路由是后台接收请求地址的方式。可在‘工具 → 站点健康 → 状态’记录 REST 相关提示；站点健康说明介绍了这些检查。这里通过，也不等于当前文章已经能保存。

返回500或其他5xx时，让维护者按同一时间查 PHP、Web 服务器与插件日志。不要把另一时段的错误当成这次原因。重新保存固定链接可能影响某些重写问题，但不能仅因404或无效JSON就当成通用修复。

这些返回内容才决定下一步找账号管理员、主机安全维护者，还是服务器维护者。怀疑插件或主题时，先在测试环境按同一账号、同篇和同一动作复现，再做插件冲突隔离，不要在营业站一次停掉全部功能。

找到200也要继续看内容和后续媒体、自动保存或插件请求。某一条请求成功，不代表整次操作都正常；最终还要看下面的原文检查。

修好后重开原文，再看访客页面

回到原文章，比较本地文档，只补仍未保存的内容，再保存一次。看到成功提示后，从文章列表重新打开同篇，检查标题、新增配送段、图片说明和链接。不能只看原来未关闭的标签，因为屏幕上的文字可能还没写入后台。

已发布文章，再用未登录窗口打开正式网址，找到同一段配送说明，点一下其中的链接并查看图片。草稿只检查后台和预览，不要求它出现在公开页。

重开编辑器已有新文，访客页还旧时，先确认正式URL和发布状态，再让维护者查页面缓存或CDN。不要为了让前台变化把新稿恢复成旧修订。

记录这次失败信息、实际改动与重开后看到的新段即可。问题反复出现，可把网站地址、脱敏报错和复现步骤提交给跨境YOUNG。