PHP版本过高不会直接导致WordPress文章发布失败，而是通过Composer依赖解析失败、插件/主题兼容性报错或require()加载中断等间接方式引发白屏、“不是有效的JSON响应”等问题。
PHP版本太高本身不会直接导致WordPress文章发布不了，但会通过 Composer 依赖解析失败、插件/主题兼容性报错、或 require() 加载中断间接引发发布失败。 最常见的实际表现是：后台点击“更新”或“发布”后页面白屏、卡住、弹出 JS 错误，或保存时返回“不是有效的JSON响应”——这些都不是 WordPress 内核拒绝发布，而是 PHP 在执行过程中提前崩溃了。
Composer install/update 因 PHP 版本过高直接中止
老项目（如 Laravel 6、WordPress 插件依赖 Symfony 4）的 composer.json 中常写死 "php": "^7.4"。当你本地是 PHP 8.2+，composer install 或 composer update 会直接报错退出，导致依赖未安装/未更新，后续调用某个类时触发 Fatal error: require(): Failed opening required，最终让编辑器 JS 请求后端接口失败，表现为“发布无响应”。
- 临时解决：加
--ignore-platform-req=php参数绕过检查，例如composer install --ignore-platform-req=php - 长期修复：检查
composer.json中的require.php值，如果代码实际兼容 PHP 8.2，就改成"^7.4 || ^8.0"或直接"^8.0"，再运行composer update --dry-run验证 - 绝对不要用
composer config platform.php 8.2.0，它会把虚假平台信息写进composer.json，污染协作环境
插件或主题里的 require / include 因路径失效而崩溃
PHP 8.0+ 对相对路径加载更严格，尤其当插件在非标准目录下被 require，而 include_path 没包含该目录，或当前工作目录（CWD）不是预期位置时，require 'config.php' 就会报 Failed opening required。这类错误一旦发生，WordPress REST API 的 /wp-json/wp/v2/posts 接口就无法返回数据，Gutenberg 编辑器显示“发布失败”。
- 用
getcwd()和ini_get('include_path')打印调试，确认脚本执行时的当前目录和搜索路径 - 把所有
require 'xxx.php'改成require __DIR__ . '/xxx.php'，强制使用文件所在目录为基准 - 禁用所有插件并切换默认主题测试；若恢复正常，再逐个启用，定位到具体哪个插件用了不安全的路径写法
WP Cron 或 REST API 在高版本 PHP 下静默失败
部分老旧插件（尤其是自动发布类）依赖 wp_schedule_event 或直接调用 wp_remote_post 触发发布逻辑，而它们内部可能用了已被 PHP 8.0+ 废弃的函数（如 create_function）、或未处理 TypeError 异常。这类错误默认不显示，但会导致定时任务中断、AJAX 请求返回空响应或 500 错误，前台表现为“点了发布按钮没反应”。
立即学习“PHP免费学习笔记（深入）”；
- 打开
wp-config.php，加入define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);，复现操作后查看wp-content/debug.log - 检查错误日志里是否出现
Deprecated:、TypeError:或Uncaught Error:开头的条目 - 重点排查插件中是否调用
mysql_connect（已移除）、each()（废弃）、或未加try/catch包裹的数组解构操作
真正麻烦的不是 PHP 版本高，而是老代码里混着对低版本的隐式依赖——比如靠 include_path 猜路径、靠 get_defined_vars() 返回顺序、或靠错误抑制符 @ 掩盖警告。这些在 PHP 8.0+ 下会直接暴露为致命错误，必须逐个击破，没法一招通杀。
