wordpress 6.9 首次提供 php 8.5 的 beta 支持，仅确保核心运行，插件/主题需自行验证兼容性；常见报错包括 create_function() 调用失败、类型声明冲突及弃用函数警告。
WordPress 6.9 正式支持 PHP 8.5，但属于「Beta 支持」——不是插件/主题也自动兼容，而是核心能跑，其余得你自己验。
PHP 8.5 在 WordPress 6.9 中的官方定位
WordPress 6.9（2025 年 12 月 2 日发布）是首个声明支持 PHP 8.5 的正式版，但文档明确标注为 Beta support。这不是 WordPress 官方“不认”，而是按其生态准则：只有当 ≥10% 的活跃站点实际运行该 PHP 版本时，才会升为「全面支持」。目前（2026 年 3 月）PHP 8.5 使用率仍在爬升中，所以你升级 PHP 8.5 后，WordPress 后台可能一切正常，但某个插件突然白屏或报错，这完全符合预期。
- 核心代码已通过基础兼容性测试，
wp-admin和wp-includes主要逻辑无致命冲突 - 不意味着所有插件、主题、自定义
functions.php代码都适配了 PHP 8.5 的语法变更（比如create_function()彻底移除、fn()箭头函数强制要求、联合类型中null必须显式写成?string） - 如果你用的是托管主机（如 SiteGround、WP Engine），它们很可能还没开放 PHP 8.5 切换选项——不是技术不行，是等插件市场整体达标
插件不兼容 PHP 8.5 的典型错误现象
别等网站崩了才查，这些信号一出现，基本就是某插件/主题卡在 PHP 8.5 上：
-
Fatal error: Uncaught Error: Call to undefined function create_function()—— 老旧插件还在用已被移除的动态函数生成方式 -
TypeError: Return value of SomeClass::someMethod() must be of the type string, null returned—— 函数声明了非空返回类型，但实际逻辑可能返回null，PHP 8.5 类型检查更严格 - 后台设置页空白、AJAX 保存失败、区块编辑器加载卡住 —— 很可能是插件用了被废弃的
each()或未处理#[\NoDiscard]属性导致静默失败 - 启用调试后，
wp-content/debug.log里反复出现Deprecated: Function money_format() is deprecated—— 插件还在调用 PHP 8.5 已弃用的本地化函数
验证和修复插件兼容性的实操步骤
别靠猜，用最小成本快速定位问题模块：
立即学习“PHP免费学习笔记（深入）”；
- 先在
wp-config.php开启调试：define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); - 禁用全部插件 → 逐个启用 → 每启一个就刷一次后台/前台关键页面，观察是否触发错误日志
- 发现可疑插件后，不要急着删，去它的 GitHub/GitLab 仓库看
issues标签有没有人提 PHP 8.5 相关 issue；再查composer.json或插件头部注释，确认是否声明了Requires PHP: 8.5 - 临时绕过：若插件作者长期不更新，可手动替换掉
create_function()调用，例如把$func = create_function('$a', 'return $a * 2;');改成$func = fn($a) => $a * 2;（注意作用域和引用限制）
升级前必须做的三件事
PHP 8.5 不是“装上就更快”，它是把兼容性问题提前暴露出来。跳过这三步，大概率会半夜收告警邮件：
- 备份整站：包括
/var/www/your-site文件 + MySQL 导出 SQL，别只信主机后台一键备份 - 在本地或 staging 环境完整复现：用
php:8.5-fpm+apache2Docker 镜像搭个最小环境，把生产环境的插件、主题、wp-config.php全部搬过去跑一遍 - 检查
disable_functions：PHP 8.5 默认仍可能禁用chmod、shell_exec等，而某些备份/部署插件依赖它们；确认php.ini中该行没包含你插件需要的函数
真正麻烦的从来不是 PHP 版本号本身，而是那些藏在插件深处、五年没动过、却恰好踩中 PHP 8.5 语法红线的三行老代码。
