WordPress更换服务器，异常恢复后怎样区分缓存过期与真正修复
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /f19dd5ec88e1.html
📄
WordPress更换服务器，异常恢复后怎样区分缓存过期与真正修复
先给结论：如果异常表现是“时好时坏、不同网络结果不同、同一 URL 多次请求返回内容不一致”，优先怀疑缓存过期；如果同一 URL 在同一网络、同一请求头下持续返回相同错误，并且服务器日志、源站响应和数据库状态都指向同一处，才更接近真正修复。判断时不要只看浏览器页面，要把“页面表现”和“源站响应”分开记录。
先固定一个观察对象，而不是反复刷新首页
选一个迁移前就存在、内容不常变、没有登录态的静态页面，例如关于页或某篇旧文章。把它当作观察对象，后续所有判断都围绕它进行。原因是首页可能被 CDN、对象缓存、浏览器缓存多层覆盖，刷新首页得到的结果并不能代表源站已经恢复。
假设这个页面在更换服务器后返回 500。你在本地浏览器看到错误，但用命令行请求时有时返回 200。此时不要立刻判定“已经修好”。先记录三组信息：请求发出的网络、请求是否带缓存绕过参数、返回内容是否与源站数据库中的正文一致。只有这三组信息稳定一致，才进入下一步。
用响应头判断缓存是否还在替你“演戏”
缓存过期和真正修复最容易被混淆的地方，是响应头。你可以对同一个 URL 连续请求两次，观察 Age、Cache-Control、X-Cache 这类字段。如果第一次返回旧内容且 Age 很大，第二次仍然返回旧内容，说明缓存层还在提供旧副本。反过来，如果两次返回内容一致、Age 很小或没有缓存命中标记，并且源站日志里能看到这次请求，才说明请求已经打到源站。
这里有一个实际动作：临时给观察对象加一个不会影响正文的查询参数，例如 ?probe=1，再请求一次。如果带参数返回正确内容，而不带参数仍返回旧内容，通常说明问题在缓存键或缓存过期，不在源站代码。这个结果会直接影响下一步：你应该去清理对应缓存层，而不是继续改主题文件或插件。
看服务器日志和数据库，确认“修复”有没有落到源站
缓存绕过之后，如果页面仍然错误，就要看源站。具体做法是：请求观察对象时，同时在服务器上查看访问日志和错误日志。访问日志能告诉你请求有没有到达这台服务器，错误日志能告诉你 PHP 或数据库有没有报错。如果访问日志里没有这次请求，说明请求被前面的缓存或代理截住了；如果有请求但错误日志持续报同一处，说明源站还没修好。
再查数据库。以文章正文为例，确认 wp_posts 中该文章的 post_content 是否完整、post_status 是否为发布状态。如果数据库里内容正确，但页面输出错误，问题更可能在主题、插件或 PHP 环境；如果数据库里内容本身缺失，缓存清多少次都不会真正修复。
区分“缓存过期”和“真正修复”的三个可验证信号
- 信号一：同一请求条件是否稳定。 同一网络、同一 URL、同一请求头连续多次返回一致结果，才偏向真正修复；结果随机跳变，偏向缓存过期或有多台后端不一致。
- 信号二：源站日志是否出现对应请求。 日志中没有请求，说明你看到的可能只是缓存副本；日志中有请求且无新错误，才说明源站参与了这次响应。
- 信号三：内容是否与数据库一致。 页面正文、标题、状态与数据库记录一致，才说明输出链路没有继续使用旧数据。
这三个信号不需要同时完美，但至少要有两个能互相印证。只凭“刷新后好了”就结束处理，很容易在缓存再次过期时复发。
一个注明假设的短例子
假设某篇文章在更换服务器后显示旧标题。你清除了插件缓存，页面恢复新标题，于是认为修复完成。第二天旧标题又出现。此时更合理的解释是：CDN 或反向代理仍持有旧副本，插件缓存只是其中一层。正确动作是检查响应头中的缓存命中标记，并对该 URL 执行对应缓存层的刷新，而不是再次修改文章。若刷新后带参数请求与不带参数请求都返回新标题，且源站日志出现请求，才可以把这个页面视为已恢复。
最后提醒一点：robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录。更换服务器后的异常恢复判断，重点始终是“你看到的响应来自缓存还是源站”，而不是页面是否暂时能打开。把观察对象、响应头、源站日志和数据库状态放在一起核对，才能决定下一步是继续清缓存，还是回到源站排查。
