1 前言

在之前的文章中（参见：家庭数据中心系列 WordPress网站通过Simply Static插件实现站点静态化），我详细介绍了如何在 WordPress 上使用 Simply Static 插件，将动态网站一键导出为纯静态页面。这个方案非常适合用来构建一个全站缓存的备份站点，或者直接部署到 Cloudflare Pages 之类的平台，实现极致的访问速度与安全性。

其实如果只是偶尔更新网站，手动点一下仪表盘的「生成静态文件」按钮倒也没什么问题，甚至于对于现在我的更新频率来说，这种方式已经足够了。但是嘛，问题就出在“手动”这两个字上：

• 一旦网站更新频率高，比如我这种几乎隔三差五就要改点小东西的人，就很容易忘记去点那一下。
• 更别提如果想要每周定时导出，然后自动同步到 GitHub 仓库，触发 Cloudflare Pages 的重新部署，就完全做不到了。

虽然目前我还是选择每周手动导出一次，但我也一直在寻找一种自动化的可能性。如果未来有需要启用全自动流程，那么 WordPress 的命令行工具 wp-cli，无疑是最合适的解决方案。有了 wp-cli，我可以在不打开浏览器的情况下，直接通过命令行调用 Simply Static 的导出动作，甚至结合 Git、计划任务、Docker 等工具，构建一个从动态站到静态站的自动化流水线。

即使你暂时没有自动化的打算，wp-cli 本身也非常值得了解。它就像是 WordPress 的“命令行面板”，可以帮助我们以更快的方式安装插件、更新文章、管理用户……对喜欢用命令行的人来说，非常友好。

所以，在进入实操之前，先单独用一章好好聊聊 wp-cli，因为这个工具其实非常值得掌握。

2 wp-cli工具介绍

2.1 wp-cli是什么？

简单来说，wp-cli 就是 WordPress 的命令行接口（CLI：Command Line Interface），它能让你用命令行的方式去管理和操作 WordPress，几乎可以代替后台仪表盘完成绝大多数工作，从官方的角度说，wp-cli 的初衷就是为了提升 WordPress 的可维护性和自动化能力，让你可以在不打开浏览器的情况下进行各种批量操作，特别适合下面这些场景：

• CI/CD 工作流：可以配合 GitHub Actions / GitLab CI 在部署阶段做一些事情。
• 大规模站群管理：一行脚本就能对上百个站点执行操作。
• 自动化运维脚本：比如定时导出数据、自动清缓存、每日检查更新。
• 包括我这次要用到的 —— 调用 Simply Static 插件进行静态化导出

可以把它理解为 WordPress 的“脚本入口”，如果你的博客是个工厂，平时需要点后台按钮排队加工，现在有了 wp-cli，就可以直接在终端里敲命令，机器立刻开始运转。可以说，对于追求极致可控和自动化的人来说，wp-cli 是 WordPress 必不可少的“超能力”工具。

2.2 wp-cli的2种部署方式

2.2.1 第一种、直接部署在 WordPress 宿主机(或 Docker 容器)里

这其实是最常规的方式。

• 如果你的 WordPress 是直接运行在一台 Linux 主机(比如 Debian)上，那只需要在主机上通过 curl 或 apt 安装 wp-cli 就可以了。
• 如果你的 WordPress 是在一个 Docker 容器里运行的，你也可以把 wp-cli 安装到那个容器里（通常是在 Dockerfile 里 RUN curl …）。

这样 wp-cli 可以直接在同一台机器(或同一个容器)里操作 WordPress 文件、读写数据库，什么都不用配置，最天然的方式。

缺点是：如果容器只内置了最小的 PHP/FPM，或者你想保持应用容器尽可能“干净”，就不一定想把 wp-cli 装进去。

2.2.2 第二种、用wp-cli官方的docker镜像单独部署

更优雅、更解耦的方式是使用 WordPress 官方提供的 wordpress:cli Docker 镜像。这个镜像里自带了：wp-cli和PHP + 必要扩展，没有包含Web 服务，只用于执行 CLI 命令。

它的原理其实很简单：

• 通过 docker run 或 docker-compose 把这个容器启动起来。
• 用 -v 把宿主机或者另一个容器里的 WordPress 目录挂载到这个 CLI 容器里，让它可以访问 wp-config.php 以及 wp-content。
• 然后通过环境变量或者 wp-config.php 里已有的配置，去连接同一套数据库。

这样就同时满足了两个关键点：

1. 能操作 WordPress 文件(比如生成静态文件、修改主题、安装插件)

2. 能操作 WordPress 的数据库（因为 wp-cli 会读 wp-config.php 或用 –dbhost 参数连上数据库）

所以只要挂载好文件夹、让数据库地址可达(比如 mysql/mariadb 容器的网络可见），wp-cli 就可以像在原地一样工作。

2.2.3 总结

方式	适用场景与特点
方式 1：直接部署在宿主机(或 Docker 容器)	更适合那种宿主机源码部署 WordPress（比如在 /var/www/html）。这时候文件和数据库都在同一个环境里，wp-cli 安装在本机或者容器里就能直接使用，几乎零配置。
方式 2：用 docker run wordpress:cli 单独跑	更适合Docker 部署 WordPress 的场景，尤其是 WordPress 和 MySQL 分别是独立容器的架构。这样可以用官方 cli 镜像单独跑任务容器，通过挂载卷来操作 WordPress 文件，通过容器网络访问数据库，既轻量解耦，也方便后续迁移到其他机器或写到 CI/CD 里自动执行。

对于我想做的“定时执行 Simply Static 生成静态站”，适合用第二种方式：用 Docker 镜像单独跑 wp-cli，既可以挂载 WordPress 文件，又可以通过网络访问数据库，是一种非常优雅的做法。

---

虽然 wp-cli 提供了非常强大的命令行操作能力，支持插件管理、主题操作、数据库导出导入、文章发布等常用功能，但它并不是 WordPress 的“万能遥控器”：
•一些插件或主题的设置依赖前端页面交互，或者存储在复杂的选项结构中，wp-cli 并不总能精确处理这些配置。
•某些需要用户授权（OAuth）、图形界面配置的功能，wp-cli 也无法覆盖。
•此外，wp-cli 操作数据库时绕过了部分 UI 层的逻辑验证流程，虽然效率高，但有可能引发数据一致性问题或遗漏必要的副作用。

例如：
•Jetpack 插件的连接流程涉及 WordPress.com 的 OAuth 授权跳转，wp-cli 无法通过命令行完成认证绑定，只能在后台仪表盘中手动授权。
•Elementor 等可视化构建器的页面结构，往往存储为复杂的 JSON 数据片段，即使勉强用 wp-cli 修改，也难以确保前端排版的准确性。
•部分安全插件（如 Wordfence、iThemes Security）启用后会在后台动态生成配置文件或防火墙规则，这些机制同样不受 wp-cli 控制。

因此，它更适合作为脚本化、批量操作、自动化部署等场景的利器，而不是完全取代仪表盘的操作方式。

---

3 wp-cli工具的部署

3.1 方式1：直接部署在宿主机(或 Docker 容器内部)

3.1.1 在宿主机上安装 wp-cli

如果你的 WordPress 是用最传统的方式部署在一台服务器上，比如直接把源码放到 /var/www/html，用 nginx 或 apache 提供服务，数据库就在同机或者同局域网，那么最简单的方式就是直接把 wp-cli 安装在这台宿主机上，最常见的方法就是使用官方提供的安装脚本：

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info   # 测试一下能不能正常执行
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

这样就可以在全局通过 wp 命令使用了，比如：

wp --info
wp core version

如果你是源码部署的 WordPress，执行时只需要指定路径就行，这样就能列出你的插件清单：

wp --path=/var/www/html plugin list

3.1.2 在 WordPress 容器内部安装 wp-cli

同理，如果你用的是一般的容器方式部署 WordPress(比如用 docker run 或 docker-compose 启动 WordPress + MySQL)，也可以在 WordPress 这个容器内部通过 apt install 或 curl 安装 wp-cli。因为这个容器本身就已经带了 PHP 运行环境和 WordPress 文件目录，只要能执行 php 命令，就可以跑 wp-cli，比如先进入容器内部：

docker exec -it your_wordpress_container bash

然后执行：

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp

这样容器内部就可以直接执行 wp 命令。

---

需要注意的是，很多WordPress镜像内部都是非常「瘦身」的，只包含了 PHP + Apache/Nginx + WordPress 文件，未必装了curl、wget 这类最常见的工具，如果没装的话，要在容器里使用它们，往往还需要先执行：

apt update && apt install curl wget less -y

而且更麻烦的是，这种方式只在当前容器有效 ——
如果以后执行了 docker-compose down 再 up，或因为 WordPress 自动更新拉取了新镜像，之前安装的工具就都会丢失(除非写进 Dockerfile)。

所以对于 Docker 部署 WordPress 的场景想安装wp-cli，更推荐用下一节介绍的 wordpress:cli 镜像单独执行的方式，这样更轻量、解耦，也不用担心容器重建后环境消失的问题。

---

3.2 方式2：用wp-cli官方的docker镜像单独部署

3.2.1 docker-compose方式部署

相比在 WordPress 容器内部安装 wp-cli，更推荐的方式是直接使用官方提供的 wp-cli 镜像单独部署一个容器。这样更干净、隔离性更好，也更容易复用，尤其适合已经通过 docker-compose 管理多个 WordPress 实例的场景。

你可以直接在现有的 docker-compose.yml 中加上一个 wp-cli 容器，例如：

wpcli:
    image: wordpress:cli
    container_name: wpcli
    volumes:
      - ./html:/var/www/html
    entrypoint: tail -f /dev/null

这段配置有几点说明：
• 容器用了 tail -f /dev/null 持续挂起不退出，方便我们随时 docker exec 进去执行命令；
• volumes 对应 WordPress 的数据目录，建议和 WordPress 容器保持一致（你可以改成你自己的路径）；
• 没有单独绑定网络、数据库等服务，是因为我们大多数操作都是跑 wp 命令本地处理静态文件或配合 HTTP 请求，不涉及数据库的话就够用了。

部署好这个容器后，你可以像这样进入 wp-cli：

docker exec -it wpcli bash

然后直接在容器内执行命令，比如：

wp --path=/var/www/html plugin list

这样做的好处是：
• 避免了在 WordPress 镜像中修改环境；
• 避免因容器销毁、镜像升级而丢失 wp-cli；
• 更易于统一管理，也便于后续自动化脚本封装。

如果你想更进一步，也可以写一个专用的 Dockerfile 来做一些预定义，比如配置默认路径、默认 URL 之类的参数。但对大多数场景来说，直接用官方镜像就已经足够好用了。

3.2.2 docker-run命令格式部署

除了通过 docker-compose 方式，也可以使用更直接的 docker run 命令来运行 wp-cli 官方镜像。这种方式无需修改已有的 docker-compose.yaml 文件，也不会影响现有 WordPress 容器的运行状态，因此在一些对稳定性要求较高的环境中，反而更为稳妥。

例如可以使用docker run直接执行wp-cli命令wp plugin list：

docker run --rm \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli \
  wp plugin list

这条命令做了以下几件事：
• –rm：容器退出后自动清除；
• –volumes-from：复用 WordPress 容器的持久化数据卷；
• –network container:…：直接加入 WordPress 容器的网络命名空间，确保 wp-cli 命令能够连接 WordPress 所使用的数据库；
• wordpress:cli：使用官方 wp-cli 镜像；
• wp plugin list：运行示例命令，列出插件列表。

这种方式适合临时操作或脚本调用，执行完即退出，避免对 wordpress的docker-compose.yaml 做任何更改，整洁轻量，不需要改动部署结构。

如果你需要在容器中依次运行多个 wp-cli 命令，而不希望每次执行完一条命令容器就退出，那就不要加 –rm 参数，可以像下面这样启动一个持久化的 wp-cli 容器：

docker run --name wp-cli \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli /bin/bash

之后如果还需要再次进入容器执行操作，可以视情况选择以下两种方式之一：

• docker exec -it wp-cli /bin/bash：进入容器的 shell，适合执行多条命令；
• docker start -ai wp-cli：重新进入 wp-cli 容器主进程（如果主进程是交互式的 wp 命令）。

注意：如果你用 docker stop wp-cli 停止了容器，docker start -ai 才能再次唤起；如果容器还在运行，推荐用 docker exec 直接进入。

---

如果执行 wp 命令时出现类似 Undefined array key “HTTP_HOST” 的警告，一般是因为某些插件/主题在 CLI 模式下依然尝试读取 HTTP 头部信息，这在 wp-cli 的运行上下文中是不存在的。
这些警告不会影响命令实际结果，可忽略。如果需要屏蔽，可以考虑通过挂载自定义 php.ini 的方式调整 PHP 的错误输出级别：

---

4 常用wp-cli命令介绍

以下是常见的 wp-cli 命令及其作用介绍，涵盖插件管理、主题管理、数据库、用户、缓存等常用操作。

插件管理相关：

命令	说明	示例
wp plugin list	列出所有插件及其状态（激活/未激活）	wp plugin list
wp plugin install <slug>	安装插件（默认不激活）	wp plugin install akismet
wp plugin install <slug> --activate	安装并激活插件	wp plugin install akismet --activate
wp plugin activate <slug>	激活已安装插件	wp plugin activate akismet
wp plugin deactivate <slug>	停用插件	wp plugin deactivate akismet
wp plugin delete <slug>	删除插件	wp plugin delete akismet

---

插件与 wp-cli 扩展支持说明

wp plugin list 只能显示插件的安装和激活状态，但无法告知插件是否提供了针对 wp-cli 的扩展命令。部分知名插件（例如 WooCommerce、Jetpack 等）会为 wp-cli 提供专属命令，支持更细粒度的管理和操作。

要查看当前站点支持的所有 wp-cli 命令，可以使用：

wp help

或者针对某个插件命令空间查询帮助：

wp help <plugin-slug>

若插件文档或官网没有明确说明，可以尝试用以上方式确认是否支持，这种方式能帮助你发掘更多命令行的高级用法，提高运维效率。

---

主题管理相关：

命令	说明	示例
wp theme list	查看所有主题及当前启用主题	wp theme list
wp theme install <slug>	安装主题（默认不启用）	wp theme install twentytwentyfour
wp theme activate <slug>	启用指定主题	wp theme activate twentytwentyfour

用户管理相关：

命令	说明	示例
wp user list	列出所有用户	wp user list
wp user create <login> <email>	创建新用户	wp user create alice [email protected] --role=editor
wp user delete <id>	删除用户（可选转移内容）	wp user delete 3 --reassign=1

查看站点信息：

命令	说明	示例
wp option get <name>	获取站点配置项值	wp option get siteurl
wp option update <name> <value>	修改站点配置项值	wp option update blogdescription "新副标题"

缓存操作相关：

命令	说明	示例
wp cache flush	清空对象缓存（如使用 Redis 等）	wp cache flush
wp transient delete --all	删除所有临时缓存（transients）	wp transient delete --all

数据库操作相关：

命令	说明	示例
wp db export	导出数据库到 SQL 文件	wp db export backup.sql
wp db import <file>	导入 SQL 文件	wp db import backup.sql
wp db reset	重置数据库（清空所有数据）	wp db reset
wp search-replace <old> <new>	全站文本替换（含数据库）	wp search-replace 'http://old.com' 'https://new.com'

wp核心相关操作：

命令	说明	示例
wp core update	更新 WordPress 核心程序	wp core update
wp core version	查看当前 WordPress 版本	wp core version

这只是 wp-cli 的冰山一角，它还有非常强大的脚本化处理能力。如果你正在维护多个 WordPress 站点，或者打算实现自动化部署流程，深入学习 wp-cli 是非常值得的。

注：很多命令都支持 --allow-root 和 --path=/var/www/html 等参数，具体根据运行环境调整。

5 使用wp-cli实现simply static pro的定时导出

5.1 概述

---

这是我想到什么目标直接就上，然后“边研究边记录”习惯的跳坑现场实录：我原本想着通过 wp-cli 来定时执行 Simply Static 的导出任务，结果刚刚兴致勃勃地写了几段命令，就发现免费版根本不支持 wp-cli：

然后看simply static官网才发现，这是pro订阅专用：

所以这就把我架在半空了。。。不过既然坑已经挖了，我还是会把研究过程写完，只是要提醒各位：只有 Simply Static Pro 才支持 wp-cli 命令，免费版用户就别白费劲了，如果真要免费版支持wp-cli命令，只能换个同类老牌插件”WP2Static“，不过这个软件的使用比simply static要稍微复杂一些，我开始就是为了图简单才最终选的simply static～。

---

实现simply static pro的导出的关键命令是：

wp simply-static run --update=true

这个命令的作用是：调用插件的核心逻辑，触发一次完整的静态站点导出任务。它会根据你当前在后台配置的选项（比如导出路径、要排除的内容、URL 重写方式等），生成整站 HTML 文件。

但使用这个命令时有一个容易踩坑的问题，就是“导出时间”的不确定性。Simply Static 在执行导出时，会根据以下几个因素影响导出所需的时间：

• WordPress 所部署的主机性能（特别是磁盘 I/O 和 PHP 执行效率）；
• 站点内容的体量（页面数量、媒体资源大小）；
• 导出设置中是否启用了某些耗时功能（如 URL 替换、包含媒体文件等）；
• 是否首次导出（首次生成通常会慢很多）；

在一些情况下，导出耗时可能仅为 10 分钟左右，但也可能因为资源不足或页面数过多延长到几十分钟甚至几个小时。因此，不能简单使用传统 shell 脚本中“顺序执行”的方式一口气跑完。——比如你不能简单写一个：

wp simply-static run --update=true
git add .
git commit -m "auto update"
git push

这种写法会导致后续命令在导出未完成时就执行了，最终提交的内容可能是不完整的，甚至是空的。因此，如果你希望将导出任务自动化并串联后续操作，必须引入异步处理或轮询检测机制,也就是说，脚本需要判断导出是否已完成，才能进行后续的 Git 提交或部署操作。

5.2 方案1：设置一个保守的超时时间

适合：了解自己站点大致导出时间，或愿意设置一个足够冗余的等待时间。

假设你在第一次执行中观察到完整导出用了 20 分钟，那可以设置脚本超时时间为 30 分钟甚至更长：

#!/bin/bash

# 触发 Simply Static 导出任务
docker run --rm \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli \
  wp simply-static run --update=true

# 等待足够长时间，确保导出完成
sleep 1800  # 等待 30 分钟（1800 秒）
cd /your-export-path
git add .
git commit -m "auto update"
git push

注：第一次执行导出任务后，可以观察实际用时，再据此合理调整 sleep 时间。

5.3 方案2：轮询检查导出状态(适合导出耗时不稳定、对效率敏感的场景)

#!/bin/bash

# 触发 Simply Static 导出任务
docker run --rm \
  --volumes-from your-wordpress-container \
  --network container:your-wordpress-container \
  -it wordpress:cli \
  wp simply-static run --update=true

# 轮询等待导出完成，最多等待 1 小时（3600 秒）
for i in {1..60}; do
  status=(docker run --rm \
    --volumes-from your-wordpress-container \
    --network container:your-wordpress-container \
    -it wordpress:cli \
    wp simply-static status)

  echo "status" | grep -q "completed" && break
  echo "等待中... 第 $i 分钟"
  sleep 60
done

# 推送导出内容到远程仓库
cd /your-export-path
git add .
git commit -m "auto update"
git push

注：这种方案更加灵活稳妥，可自动识别导出是否结束，适合生产环境或任务时长变化较大的站点。

5.4 总结与建议

对于导出 + 推送的自动化流程，其实并不存在唯一正确的做法。本文提供的两种方案，各有适用场景：

• 方案 1 更适合资源占用小、插件较少的小型博客，配置简单，稳定性也足够；
• 方案 2 则更适合站点结构复杂、插件众多的情况，能有效规避导出过程中的不确定性，更稳妥一些。

建议根据自己站点的规模和实际情况，灵活选择。

另外，如果你使用的是 Simply Static Pro，其实是可以直接将导出内容推送到 GitHub 仓库的。不过目前我们主要是基于 WP-CLI 来实现自动化，对这部分 Pro 插件的 CLI 支持能力不太清楚(主要是懒得研究～)，如果未来能验证其支持，也可以尝试在 CLI 中直接调用其推送逻辑，进一步简化整个流程。

6 后话

如果想实现 WordPress 相关功能的自动化，wp-cli 可以发挥非常大的作用。比如，我现在导出 WordPress 数据库是直接在 MariaDB 容器中使用 docker exec 命令进行操作，而有了 wp-cli 之后，可以直接用一行命令导出数据库，例如：

wp db export /var/www/html/wordpress.sql

相比通过数据库容器执行 mysqldump，wp-cli 的这个用法更贴近 WordPress 本身的逻辑，导出路径、权限问题也更可控。

除了数据库导出，wp-cli 还可以用来完成许多常见管理操作，比如：

• 启用或停用插件：

wp plugin activate simply-static
wp plugin deactivate akismet

• 安装并激活主题：

wp theme install twentytwentyfour --activate

• 更新插件/主题/Core 核心：

wp plugin update --all
wp theme update --all
wp core update

• 后台用户操作：

wp user list
wp user create newadmin [email protected] --role=administrator

更别提我们上文提到的静态站点导出任务，也完全可以通过 wp-cli 来调度。

虽然本文主线是为了实现 Simply Static 静态化站点的自动化部署，但实际上，wp-cli 可以成为整个 WordPress 系统的自动化控制台。无论你是希望每天定时备份数据库、清理缓存、批量启用插件，还是后续打算构建 CI/CD 自动部署流程，wp-cli 都是最值得掌握的工具之一。它更像是一种面向 WordPress 的“自动化语言”，让你摆脱繁琐的后台点击，真正用脚本来管理站点。

如果你对wordpress的自动化和运维有更多兴趣，非常值得花时间好好挖掘一下 wp-cli 的能力。