别慌！WP-CLI 导入导出连环坑，这 7 个鬼打墙问题我帮你一脚踢开

安装环境检测不通过——“PHP 版本太老，WP-CLI 直接罢工”

报错现象： 执行 wp --info 时,终端直接红字警告：

Error: WP-CLI requires PHP 7.2.5 or later. You are running PHP 5.6.40.

更气人的是，明明服务器上装了 PHP 7.4，但 WP-CLI 认死理”地跑去调用了旧版 PHP。

原因分析： WP-CLI 是通过系统 PATH 环境变量寻找 php 可执行文件的，很多时候，服务器上安装了多个 PHP 版本，而 /usr/bin/php 被软链接到了旧版本，如果你用 apt 或 yum 装的 PHP 和源码编译的 PHP 混在一起，PATH 顺序一乱，WP-CLI 就抓瞎了。

别慌！WP-CLI 导入导出连环坑，这 7 个鬼打墙问题我帮你一脚踢开

解决步骤（对着敲就行）：

先确认系统里所有 PHP 的位置：which -a php
找到你那个 7.4+ 的 PHP 绝对路径，/usr/local/php74/bin/php
在 ~/.bashrc 或 ~/.zshrc 末尾追加一行：
```
export PATH="/usr/local/php74/bin:$PATH"
```
重新加载配置：source ~/.bashrc
再跑 wp --info，确认 PHP 版本正确。
如果还不行，直接用绝对路径调用 WP-CLI：
```
/usr/local/php74/bin/php /usr/local/bin/wp --info
```

数据库连接错误——“明明密码对了，却说 Access denied”

报错现象： 执行 wp db check 或 wp core install 时,报：

Error: Database connection error (Access denied for user 'wpuser'@'localhost')

你检查 wp-config.php 里的 DB_PASSWORD 也对着呢,但就是连不上。

原因分析： 八成是数据库账号的 host 限制问题，MySQL 里的用户 wpuser 可能只授权了 'wpuser'@'127.0.0.1'，但你的 PHP 连接时用的是 'localhost'（走的是 socket），或者反过来，还有一个隐蔽原因：wp-config.php 里定义了 DB_HOST 为 localhost，而 MySQL 的 socket 路径配置不对。

解决步骤：

在 MySQL 里执行：

SELECT user, host FROM mysql.user WHERE user='wpuser';

看到 host 是 0.0.1 或，但你的连接方式是 localhost，那就改授权：

GRANT ALL PRIVILEGES ON wpdb.* TO 'wpuser'@'localhost' IDENTIFIED BY '你的密码';
FLUSH PRIVILEGES;

wp-config.php 里 DB_HOST 写的是 localhost，改成 0.0.1 试试，因为有些 PHP 版本对 localhost 会强制走 socket 而绕过 TCP。
确认 PHP 的 MySQL socket 路径：在 php.ini 里查 mysqli.default_socket，跟 MySQL 的 socket 变量比对,不一致就统一一下。
最后再跑 wp db check,通了就继续。

500 内部服务器错误——“导入插件后，整站变成‘白底黑字’”

报错现象： 用 wp plugin install xxx.zip --activate 后，前端所有页面变成 500 错误，连 wp-admin 都进不去，但 WP-CLI 还能执行 wp plugin list。

原因分析： 插件代码里用了不兼容的函数，或依赖某个 PHP 扩展未开启，导致 fatal error，而 WP-CLI 有独立的错误处理，所以它看得到列表，但 Web 服务器（Apache/Nginx + PHP-FPM）直接崩了。

解决步骤：

先用 WP-CLI 强制停用所有插件（等于是救命的止血带）：
```
wp plugin deactivate --all
```
如果这步都报错（说明 fatal 在加载阶段就发生了），直接用 WP-CLI 跳过插件加载：
```
wp plugin deactivate --all --skip-plugins
```
页面试试能打开了，再一个一个启用插件排查：
```
wp plugin activate $(wp plugin list --field=name --status=inactive)
```
但别一次全激活,手动分批来：
```
wp plugin activate akismet
```
每激活一个就 curl -I http://你的域名,看返回码。
找到出问题的插件，要么删除，要么用 --force 卸载：
```
wp plugin delete 坏插件名 --force
```

白屏死机——“导入 XML 后，首页空白，连登录页都白”

报错现象： 用 wp import 文件.xml --authors=create 导入后，前台、后台全部白屏。wp post list 能列出文章,但页面渲染就是空白。

原因分析： 通常不是 PHP fatal error，而是内存耗尽或递归调用死循环，导入大量数据时，WordPress 的 wp_insert_post 会触发很多钩子（比如更新缓存、生成缩略图、更新父子关系），如果某个钩子回调里又调用了导入函数,就直接炸掉。

解决步骤：

查看 PHP 错误日志，常见的是 Allowed memory size of 128M bytes exhausted。

用 WP-CLI 临时提高内存限制：

wp config set WP_MEMORY_LIMIT 512M
wp config set WP_MAX_MEMORY_LIMIT 512M

如果还是白屏，八成是导入时某个插件在“捣鬼”，用 --skip-plugins 模式再试：
```
wp import 文件.xml --authors=create --skip-plugins
```
导入成功后，马上更新固定链接：
```
wp rewrite flush
```
最后清理对象缓存：
```
wp cache flush
```
如果用了 Redis/Memcached，记得 purge 一下。

插件冲突导致异常——“激活插件后，AJAX 全部 400”

报错现象： 用 wp plugin activate 某个插件 后，后台主题编辑器、自定义菜单、附件上传等所有 AJAX 功能全部失效，点击没反应，浏览器控制台显示 400 错误。

原因分析： 插件里注册了自定义 REST 路由或 AJAX action，但它的 admin_init 里调用了 wp_die() 或 exit() 来拦截请求，导致 WordPress 的 admin-ajax.php 根本走不到标准流程。

解决步骤：

用 WP-CLI 主动探查哪个插件在搞鬼：
```
wp plugin list --status=active --field=name
```
逐个停用并测试 AJAX：
```
wp plugin deactivate 可疑插件
```
然后去后台前端页面，按 F12 手动触发一个 AJAX 请求（比如上传图片）,看是否恢复。
如果全停用后恢复了，就二分法：激活一半，测试，再激活一半,缩小范围。
找到元凶后，看它的代码里有没有 add_action('admin_init', 'xxx'); 且函数里调用了 wp_send_json() 但没加权限判断，用 wp plugin update 插件名 看看有没有新版修复了这个问题。
如果插件已停更，直接删了吧,别恋战。

自动更新失败回滚——“WordPress 自动更新卡在 Maintenance 模式”

报错现象： WordPress 后台显示“正在执行例行维护，请一分钟后回来”，结果一个小时后还在，用 WP-CLI 执行 wp core check-update 没问题,但前端就是被锁。

原因分析： 更新过程中，WordPress 会在根目录创建 .maintenance 文件，里面写入 <?php $upgrading = time(); ?>，如果更新进程被中断（PHP 超时、杀掉进程、磁盘满），这个文件不会自动删除,站点就永远卡在维护模式。

解决步骤：

用 WP-CLI 强制移除维护模式：
```
wp maintenance-mode deactivate
```
如果这个命令报错（WP-CLI 本身也要过维护模式检查）,直接手动删除文件：
```
rm -f /你的站点根目录/.maintenance
```
然后查一下是不是更新到一半卡住了：
```
wp core version
wp core check-update
```
如果版本不一致（比如显示 5.9 但你想更新到 6.0），说明更新中断，重新执行：
```
wp core update --force
```
更新后别忘了把数据库里的版本号校准：
```
wp core update-db
```
如果反复出现这种问题，干脆禁用自动更新：
```
wp config set WP_AUTO_UPDATE_CORE false
```

登录页面重定向循环——“wp-admin 一直跳回 login”

报错现象： 能打开 wp-login.php，但输对账号密码后，又弹回登录页，地址栏变成 wp-admin/ 然后无限刷新，用 WP-CLI 执行 wp user list 能看到用户存在,密码也是对的。

原因分析： 这是经典的 cookies 路径问题。wp-config.php 里的 COOKIE_DOMAIN 或 ADMIN_COOKIE_PATH 被错误地设成了 https://www.example.com（带协议），或者反向代理配置导致 HTTP_HOST 跟实际域名不匹配，还有一种情况：siteurl 和 home 两个选项值不同步。

解决步骤：

先用 WP-CLI 直接查两个关键选项：
```
wp option get siteurl
wp option get home
```

如果不一样，立即统一：

wp option update siteurl 'https://你的域名'
wp option update home 'https://你的域名'

如果一样但还是死循环，检查 wp-config.php 里的 cookie 定义：

define('COOKIE_DOMAIN', 'www.你的域名.com'); // 这里严禁带 http:// 或 https://
define('ADMIN_COOKIE_PATH', '/'); // 别设成 /wp-admin/

如果你用了 Cloudflare 或 Nginx 反向代理，检查 $_SERVER['HTTP_X_FORWARDED_PROTO'] 是否被正确处理，在 wp-config.php 里加：
```
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
    $_SERVER['HTTPS'] = 'on';
}
```
最后刷新一下永久链接和缓存：
```
wp rewrite flush
wp cache flush
```
如果还不行，那就暴力清 session：
```
wp eval 'session_destroy();'
```
然后换一个浏览器无痕模式登录。

最后唠叨一句： 以上所有 WP-CLI 命令，都建议在站点根目录下执行，如果你的 wp 命令没找到，先全路径 /usr/local/bin/wp，或者用 alias wp='php /path/to/wp-cli.phar' 起个别名，干这行，遇到问题别慌，WP-CLI 就是你手里的手术刀，一刀一刀切,总能找出病灶。

正文

别慌！WP-CLI 导入导出连环坑，这 7 个鬼打墙问题我帮你一脚踢开

安装环境检测不通过——“PHP 版本太老，WP-CLI 直接罢工”

数据库连接错误——“明明密码对了，却说 Access denied”

500 内部服务器错误——“导入插件后，整站变成‘白底黑字’”

白屏死机——“导入 XML 后，首页空白，连登录页都白”

插件冲突导致异常——“激活插件后，AJAX 全部 400”

自动更新失败回滚——“WordPress 自动更新卡在 Maintenance 模式”

登录页面重定向循环——“wp-admin 一直跳回 login”

相关阅读

避开六大运维陷阱，用WP-CLI精准拆解WordPress性能、安全与维护难题

发表评论取消回复

目录[+]