WordPress 7.0 自动更新不完整导致网站崩溃的排查与修复

问题现象

2026年5月25日，我的博客顾念の小窝突然打不开了，浏览器访问只显示两行PHP致命错误：

Fatal error: Cannot redeclare wp_sanitize_script_attributes()
(previously declared in .../wp-includes/deprecated.php:6521)
in .../wp-includes/script-loader.php on line 2875

Fatal error: Uncaught Error: Call to a member function set() on null
in .../wp-includes/l10n.php:857

根因分析

经过对比调查，这是一次 WordPress 6.x → 7.0 自动更新不完整 导致的事故。

到底发生了什么？

在 WordPress 6.x 中，wp_sanitize_script_attributes() 函数定义在 wp-includes/script-loader.php 里，是一个普通的功能函数。

但在 WordPress 7.0 中，这个函数被废弃了：官方把它从 script-loader.php 中删除，改为在 deprecated.php 中以 _deprecated_function() 包装的形式存在，引导开发者使用新的 wp_get_script_tag() 和 wp_get_inline_script_tag() 替代。

自动更新时出了岔子：

部分文件更新成功：version.php（版本号变成了7.0）、deprecated.php（新增了废弃版函数声明）
大部分文件更新失败：script-loader.php 保留了旧的6.x版本（仍然定义了同名函数）、connectors.php 等49个新文件完全没有被解压到服务器上

结果：同一个函数在 deprecated.php 和 script-loader.php 中各声明了一次 → PHP 报 "Cannot redeclare" → 网站崩溃。

为什么自动更新会不完整？

WordPress 自动更新机制会下载完整 zip 包并解压覆盖。如果解压过程被中断（磁盘空间不足、文件权限问题、进程超时等），就会出现版本号变了但核心文件混用新旧两个版本的情况。本案例中 wp-content/upgrade/ 目录为空，升级过程的临时文件已被清理，无法回溯具体中断原因。

修复步骤

以下是完整的修复过程，如果你也遇到类似问题可以参照：

第一步：修复 deprecated.php 中的重复声明

临时方案是删除 wp-includes/deprecated.php 中重复的 wp_sanitize_script_attributes() 函数声明（含注释共28行），让网站先恢复运行。

第二步：从官方包补全缺失文件

下载 WordPress 7.0 完整安装包，对比服务器上 wp-includes/ 目录，找出缺失的PHP文件并逐一上传。本案例共补全了49个缺失文件：

connectors.php
ai-client.php 及 ai-client/adapters/ 下的5个类文件
block-patterns/ 下5个新模式文件
block-supports/ 下3个文件
blocks/ 下5个区块文件
css/dist/registry.php
js/dist/script-modules/ 下30个 asset 文件

如何操作服务器上的文件？

本案例使用宝塔面板的API接口来读写服务器文件。如果不方便SSH，宝塔API是一个很好的替代方案：

在面板设置中开启API接口并获取密钥
签名算法：request_token = md5(request_time + md5(api_sk))
关键接口：/files?action=GetFileBody（读取）、/files?action=CreateFile（创建）、/files?action=SaveFileBody（保存）
详细文档见宝塔官方API文档

预防建议

大版本升级前先备份：WordPress主版本升级（如6.x→7.0）差异巨大，建议手动备份后再升级
升级后立即检查：打开网站首页确认无报错，访问 /wp-admin/ 确认后台正常
关闭自动主版本升级：在 wp-config.php 中添加 define('WP_AUTO_UPDATE_CORE', 'minor'); 只允许小版本自动更新
保留一份官方安装包：出问题时可以快速对比/恢复文件