WP-CLI命令行安装WordPress：从零到部署的完整实战指南-代码聚汇网

WP-CLI命令行安装WordPress：从零到部署的完整实战指南

慧小田哲思学·2026-09-01·阅读 22 GEO检测（免费）

WordPressWP-CLI命令行安装

|难度：普通|阅读约 44 分钟

1. 为什么放着图形安装界面不用，偏要折腾命令行装 WordPress

如果你用虚拟主机或者带宝塔面板的服务器装 WordPress，全程基本就是“上传压缩包 → 解压 → 浏览器打开站点 -> 填数据库信息 -> 完成”，整个过程十几分钟，傻瓜式操作，确实省心。那为什么还要用 SSH + WP-CLI + 命令行这种看起来“很不友好”的方式？

我先说结论：命令行装 WordPress 不是给所有人准备的，但它恰恰是服务器运维、开发者、以及做站点批量部署的人最该掌握的一种技能。

先说我最直观的感受。传统浏览器安装方式有一个非常烦人的问题：它是个“一次性”流程，装完就结束了。万一中途数据库密码填错、PHP 扩展缺失、目录权限不对，你得反复在浏览器和 SSH 工具之间切换，反复试错。而 WP-CLI 方式是纯命令操作，所有反馈都在终端里，一次动作一行输出，哪里错了当时就能看到，不需要等页面渲染，排查问题的速度能快好几倍。

另外，命令行方式天然适合“重复劳动”。比如你同时在维护三个 WordPress 站点，每个都要装同样的插件、开同样的设置，如果走浏览器，你得登三遍、点无数下鼠标。用 WP-CLI 的话，写三行命令，批量执行，喝口水的工夫就完事了。更别提在自动化部署脚本（比如 Jenkins、GitHub Actions 那类 CI/CD 流程）里，WP-CLI 几乎就是 WordPress 自动化的标配。

还有一个可能被很多人忽略的点：命令行安装会逼着你理解 WordPress 到底是怎么工作的。 你可能知道 WordPress 需要数据库，但你不一定清楚 wp-config.php 里的数据库配置具体长什么样；你可能知道安装界面要填站点标题和管理员账号，但在命令行里你能直接看到这些配置是以什么形式写进数据库的。多走一遍命令行流程，你反而会对 WordPress 的架构有更清楚的理解。这就像开车，自动挡好开，但你要真想搞懂发动机原理，必然绕不开手动挡。

这篇文章的安装环境是基于 Linux 服务器，且已有 SSH 访问权限和 root 或 sudo 权限。整个流程会覆盖 SSH 连接、WP-CLI 获取、数据库配置、WordPress 下载、命令行安装、安装后权限调整与优化。内容不算短，但每一步都非常具体，照着敲就能完成。适合三类人：一是刚买了服务器、想手动搭站的入门者；二是已经用图形面板装了站、但想弄明白底层逻辑的进阶者；三是需要批量部署站点的开发者。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 准备阶段：SSH 连接与服务器环境确认

2.1 选择顺手的 SSH 工具并建立连接

这一步看似基础，但很多人其实在 SSH 工具选择和环境确认上就踩了不少坑。先说工具，Windows 用户我建议直接用 Windows Terminal 自带的 OpenSSH 客户端，或者装一个 MobaXterm。macOS 和 Linux 用户直接打开终端就行，系统自带 ssh 命令，不需要额外装东西。

以 MobaXterm 为例，新建一个 Session，协议选 SSH，Remote host 填服务器 IP，Specify username 填登录用户名，比如 root 或你自己的账户，端口默认 22。点 OK 之后输入密码就能连上。如果你已经配置过 SSH 密钥，可以在 Advanced SSH settings 里指定私钥文件，实现免密登录，这个在后续反复操作时会省很多事。

连上之后第一步不是急着装东西，而是先确认自己有没有操作权限。跑一个 whoami 看当前用户，再跑一个 id 看用户组。如果是 root，下面所有命令直接执行即可；如果是普通用户，需要确认是否有 sudo 权限，执行 sudo -v 输入密码后没有报错就行。

2.2 检查 Web 环境、PHP 版本与扩展

WordPress 不是独立运行的程序，它依赖 Web 服务器（Nginx 或 Apache）、PHP 和 MySQL/MariaDB 数据库。如果你是新买的服务器，可能还没装这些，那就得先搭好 LNMP 或 LAMP 环境；如果已经装过了，也要确认版本是否满足要求。

用下面几条命令快速摸底：

bash复制# 查看 Linux 发行版
cat /etc/os-release

# 查看 PHP 版本
php -v

# 查看 PHP 已启用的扩展
php -m

# 查看 MySQL/MariaDB 版本
mysql --version

# 查看 Nginx 或 Apache 是否运行
systemctl status nginx
systemctl status apache2

WordPress 对 PHP 版本的要求是逐年版更新的，目前官方建议 PHP 7.4 以上，但说实话我强烈建议直接用 PHP 8.1 或 8.2，性能比 7.4 提升不少。如果你的 PHP 版本过低，WordPress 会直接提示“你的服务器运行的是 PHP 版本 X，但 WordPress Y 需要至少 7.2”，所以别在这上面图省事。

常用的 PHP 扩展里，mysqli、curl、gd、imagick、zip、xml 这几个和 WordPress 关系最密切。mysqli 负责连数据库，curl 负责 WordPress 内部和外部的 HTTP 请求，gd 或 imagick 负责图片裁剪缩放，zip 负责插件/主题的在线安装与解压，xml 负责 RSS 解析等功能。缺哪个装哪个，Debian/Ubuntu 上用 apt install php8.1-curl php8.1-gd php8.1-zip php8.1-xml 这种方式补装，装完记得 systemctl restart php8.1-fpm 重启 PHP-FPM。

2.3 确认数据库已就绪并创建专用账号

数据库是 WordPress 存放所有文章、设置、用户信息的地方。我们可以在确认 MySQL 服务正常后，顺手把 WordPress 需要的数据库和用户建好。

bash复制# 登录 MySQL，root 用户，会提示输入密码
mysql -u root -p

# 在 MySQL 命令行中执行
CREATE DATABASE wp_demo DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY '这里填一个强密码';
GRANT ALL PRIVILEGES ON wp_demo.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

这里有两个细节特别值得说。第一，字符集一定用 utf8mb4，不要用老的 utf8。因为 utf8 在 MySQL 里其实是“有损”的，它存不了 emoji 表情，也存不了生僻字，而 utf8mb4 是完全兼容的。第二，数据库账号的主机限制用 localhost 就够用了，如果写成 % 则意味着允许任何主机连接，这等于把数据库裸奔在网络上，除非有远程连接需求，否则不要这么干。安全这个事情，能少开一个口子就少开一个口子。

数据库准备好之后，我们需要的所有前置条件就都齐了。接下来进入正题：搞定 WP-CLI 这个命令行安装的核心工具。

3. 拿到 WP-CLI：下载、权限与自更新机制

3.1 为什么必须用 WP-CLI

WP-CLI 的全称是 WordPress Command Line Interface，它是 WordPress 官方维护的命令行工具，地位等同于 Laravel 的 artisan、Django 的 manage.py。它几乎可以实现你在后台做的所有事情：安装、配置、插件管理、主题管理、更新、缓存清理、数据库修复、用户管理等。

在安装这个场景下，WP-CLI 最大的价值是：它能直接调起 WordPress 的安装流程，帮你生成 wp-config.php、执行数据库导入、创建管理员账号，把原本需要在浏览器里完成的步骤全部压缩成一条命令。而且这些命令是幂等的，也就是说你重复执行也不会出乱子，非常适合写进部署脚本。

我见过很多人用 wget 直接下载 WordPress 压缩包再手工解压配置，这样也能装，但坦白讲比较累，尤其要手动编辑 wp-config.php、手动导入数据库 SQL，容易出错。而 WP-CLI 的 wp core install 命令一次就把活干完了，数据库、配置文件、管理员账号一次搞定，体验完全不一样。

3.2 下载安装 WP-CLI 的完整流程

WP-CLI 本身是一个 PHP 编写的 Phar 包，所谓 Phar 包你可以理解成一个可执行文件包，服务器只要有 PHP 环境就能运行。下载安装步骤如下：

bash复制# 进入家目录
cd ~

# 下载 wp-cli.phar 文件
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

# 检查下载的文件是否完整
php wp-cli.phar --info

如果 --info 能输出版本号、PHP 路径、系统信息，说明 Phar 包可用。接着把它变成系统级命令，方便之后在任何目录下直接调用 wp：

bash复制# 加上可执行权限
chmod +x wp-cli.phar

# 移动到 /usr/local/bin 目录，并重命名为 wp
sudo mv wp-cli.phar /usr/local/bin/wp

# 验证 wp 命令是否全局可用
wp --info

这里有个常见问题：如果你下载的时候遇到 SSL 证书验证失败，可以临时加 -k 参数跳过证书检查，但我建议先检查系统 CA 证书是否过期，sudo apt install ca-certificates 更新一下，而不是直接跳过验证，毕竟从 GitHub 下载文件还是要安全第一。

还有一个鲜为人知的小技巧：WP-CLI 支持自动更新自己。以后想升级到最新版本，只需要执行：

bash复制wp cli update

这会从官方渠道拉取最新 Phar 包，替换掉 /usr/local/bin/wp。如果你的二进制文件是手动 mv 过去的，可能因为权限问题更新失败，解决办法是先 sudo chown -R root:root /usr/local/bin/wp，再执行更新。

3.3 为 wp 配置命令补全（可选但推荐）

WP-CLI 的子命令非常多，比如 wp core、wp plugin、wp theme、wp user、wp option……手打很难全部记清楚，好在 WP-CLI 提供了命令补全脚本。如果你是 bash 用户，下载下面的脚本放到 /etc/bash_completion.d/ 即可：

bash复制cd /etc/bash_completion.d/
sudo curl -O https://raw.githubusercontent.com/wp-cli/wp-cli/main/utils/wp-completion.bash
source /etc/bash_completion.d/wp-completion.bash

如果你是 zsh 用户，配置方式会不太一样，不过一般补全脚本里都有说明。配置好之后，你在命令行输入 wp core i 再按 Tab，它就会自动补全成 wp core install，效率提升不是一点半点。

4. 五步完成 WordPress 核心部署

4.1 确认站点目录并下载 WordPress 源码

现在 WP-CLI 已经全局可用，接下来就看你的站点要放在哪个目录。以 Nginx 的默认站点目录为例，通常在 /var/www/html，你可以新建一个子目录放 WordPress，也可以直接把 WordPress 放在 html 根目录。

我个人的习惯是建一个项目名子目录，比如 /var/www/html/myblog，这样以后一台服务器上放多个站点时，每个站点目录清晰互不干扰。执行：

bash复制# 切换到站点根目录的上级
cd /var/www/html

# 通过 WP-CLI 下载 WordPress 最新版到 myblog 目录
wp core download --path=myblog --locale=zh_CN

wp core download 背后的逻辑实际上是下载 wordpress-xx.tar.gz 压缩包并自动解压到目标目录，不需要你手动 wget 再解压。这里我特意加了 --locale=zh_CN，它会直接下载中文版 WordPress。如果你不带这个参数，默认是英文版，装完后台如果还想改成中文，还得另外装语言包，多一步麻烦。

下载完成后，切到 myblog 目录看看文件：

bash复制cd /var/www/html/myblog
ls -la

你应该能看到 wp-admin、wp-content、wp-includes 目录和一堆 .php 文件。这些就是 WordPress 的全部源码了。

4.2 配置 wp-config.php：使用 wp config create 而非手写

旧时代装 WordPress，最痛苦的就是手动编辑 wp-config.php，要填数据库名、用户名、密码、主机、表前缀，还要顺手设置 AUTH_KEY、SECURE_AUTH_KEY 等盐值。现在 wp config create 一条命令就能搞定：

bash复制wp config create --dbname=wp_demo --dbuser=wp_user --dbpass='你的数据库密码' --dbhost=localhost --dbprefix=wp_ --locale=zh_CN

执行完这条命令后，WP-CLI 会在当前目录生成一份 wp-config.php，数据库信息和盐值都已经写进去了。它还会自动检查 PHP 版本和数据库扩展是否满足最低要求，如果有问题会直接报错提示。

这里我想特别展开讲一个很多新手完全没概念的东西：文件里的盐值（Security Keys）到底是干嘛的。WordPress 用一套密钥来给用户登录 Cookie 和密码哈希加盐，如果这套密钥泄露了，攻击者理论上可以伪造登录 Cookie。wp config create 会自动从 WordPress.org 官方接口拉取一套随机密钥写入文件，省去了手动去官网生成密钥的环节。如果你打开 wp-config.php 会看到 AUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEY 等一堆 define，那些就是盐值。这也解释了为什么很多老教程会让你去 WordPress.org 专门页面复制密钥——因为密钥要足够随机，不能自己随便敲几个字符。

4.3 正式执行安装：wp core install

配置文件就绪后，我们就可以执行安装命令了。这一步会真正往数据库里写入 WordPress 的核心表，同时创建管理员账号。命令如下：

bash复制wp core install --url=http://你的域名或IP --title="我的博客" --admin_user=admin --admin_password='设置一个强密码' --admin_email=you@example.com

关于参数，我逐一解释一下：

--url：站点的访问地址，填域名或公网 IP。如果还没解析域名，先用 IP 也完全没问题，后面域名确定了可以再改。
--title：站点标题，也就是浏览器标签页上显示的名字，后台“设置 → 常规”里随时能改。
--admin_user：管理员用户名，建议不要用 admin，安全策略上尽量避开常见用户名。
--admin_password：管理员密码，命令行里可能暴露在 shell 历史里，所以这条命令如果在一个共享服务器上执行，要格外注意。实在担心的话，可以先随机生成一个密码，装完再改。
--admin_email：管理员邮箱，忘记密码时用来找回。

如果你的 PHP-FPM 进程是 www-data 用户运行，而文件归 root 所有，也可能出现权限警告。这个我们后面专门讲，先继续安装。安装成功后，终端会输出一句类似：

code复制Success: WordPress installed successfully.

这一刻，你的 WordPress 基本就“活”了。你可以直接用浏览器访问 --url 参数指定的地址，会看到默认的 WordPress 首页。但别急着开心，还有几个很重要的收尾步骤。

4.4 WordPress 目录权限调整：一个必做的安全操作

WP-CLI 安装会把源码文件的所有者设置为执行命令的用户，比如 root。但 Web 服务器（Nginx 或 Apache）通常是以 www-data 用户运行的。如果所有文件都是 root 所有，Web 服务器就无法正常写入 wp-content 目录，以后上传图片、安装插件主题都可能会报“无法创建目录”之类的错误。

所以装完要做的第一件重要的事，就是调整目录权限。业界比较推荐的安全权限方案是：

bash复制# 用户和组都设为 www-data，适配大部分 Debian/Ubuntu 服务器
sudo chown -R www-data:www-data /var/www/html/myblog

# 目录设为 755，文件设为 644
find /var/www/html/myblog -type d -exec chmod 755 {} \;
find /var/www/html/myblog -type f -exec chmod 644 {} \;

# 缓存类目录保持可写
chmod -R 775 /var/www/html/myblog/wp-content

关于权限，我多说几句心得。如果你是纯命令行运维的老手，可能会觉得把整个站点目录都 chown 给 www-data 太粗暴，因为有些安全加固方案会说“核心文件只读、wp-content/uploads 可写”才是更严格的做法。这话没错，但那是生产环境多用户、多站点的复杂场景。对于个人博客、小型企业站或者刚上线的项目，全量 www-data 授权是“够用且省心”的方案。如果你的服务器只有你一个人维护，这个方案完全没问题。等以后真有安全审计需求，再收紧也不迟。

4.5 校验安装结果：从命令行确认核心表与配置

装完之后，最好从命令行校验一下，确认所有核心数据库表都建好了。执行：

bash复制wp db check
wp db query "SHOW TABLES;" --path=/var/www/html/myblog

如果看到 wp_options、wp_posts、wp_users 等十来张表，说明数据库部分没有问题。再用：

bash复制wp option get siteurl
wp option get blogname

确认站点 URL 和标题都正确写入了数据库。这样即使浏览器访问有问题，你也能快速定位到底是数据库的问题、Nginx 的问题，还是 PHP-FPM 的问题。

5. 向生产环境迈进：安全优化与命令行日常管理

5.1 命令行修改固定链接与伪静态配置

WordPress 安装完成后，默认的固定链接是“朴素”模式：http://域名/?p=123。这种 URL 不友好，也不利于 SEO。正常我们都会改成文章结构，比如 /%postname%/ 这种。

在命令行下改固定链接，只需要一条命令：

bash复制wp rewrite structure '/%postname%/' --hard

--hard 参数会尝试直接更新 .htaccess（Apache）或 WordPress 的 rewrite 规则（Nginx 需要在 Nginx 配置里额外指定 try_files 指令）。如果你用的是 Nginx，光改 WordPress 内部是不够的，还需要在 Nginx 的 server 块里加上：

nginx复制location / {
    try_files $uri $uri/ /index.php?$args;
}

不加这条，你会发现除了首页，其他页面全是 404。这是 Nginx + WordPress 最常见的坑之一，很多人跑到后台设置里反复改动固定链接也没用，其实问题就出在 Nginx 配置少了一行。

5.2 顺手把插件和主题装好

命令行装完核心站点之后，插件和主题也完全可以命令行搞定。比如安装并启用经典 SEO 插件 Yoast SEO：

bash复制wp plugin install wordpress-seo --activate

安装主题：

bash复制wp theme install twentytwentyfour --activate

更实用的是批量操作。比如你需要装三个常用插件，可以连写三条，或者放在一个 bash 脚本里：

bash复制wp plugin install wordpress-seo --activate
wp plugin install wp-super-cache --activate
wp plugin install really-simple-ssl --activate

如果你有多个站点，甚至可以写一个 for 循环，同一套命令跑遍所有站点目录。这种批量管理能力，是用浏览器安装时压根体会不到的。

5.3 站点基础优化：清理示例内容、设置时区、关闭评论

新安装的 WordPress 自带一篇示例文章、一个示例页面和一条示例评论，这些东西在正式站点上线前最好清掉。命令行处理非常顺手：

bash复制# 删除示例文章（默认 ID 为 1）
wp post delete 1 --force

# 删除示例页面（默认 ID 为 2）
wp post delete 2 --force

# 删除示例评论（默认 ID 为 1）
wp comment delete 1 --force

这里要提醒一下，--force 参数的意思是绕过回收站直接永久删除。如果不加这个参数，会进回收站，但 WordPress 对文章和评论的回收站处理策略不尽相同，加上 --force 更干净。

再把站点时区改成上海，默认评论关闭（避免垃圾评论）：

bash复制wp option update timezone_string 'Asia/Shanghai'
wp option update default_comment_status closed

如果你的站点以后要开评论，再改回来就行，命令行改设置就是这么随意。

5.4 基于命令行部署的常规安全思路

在命令行下安装 WordPress，安全策略和图形界面安装是共通的，但命令行给了更多精细控制的机会。我整理了三个我最常用的加固操作：

后台强制使用 SSL。执行 wp option update siteurl 'https://你的域名' 和 wp option update home 'https://你的域名'，前提是服务器已经配置好 SSL 证书。
禁止修改核心文件。在 wp-config.php 中加一行（或在 WP-CLI 里执行 wp config set FS_METHOD direct 再手工改）define('DISALLOW_FILE_EDIT', true);，这个常量会隐藏后台主题和插件编辑器，防止有人拿到后台权限后直接改源码。
限制管理员登录尝试次数。可以用 WP-CLI 装一个 login-lockdown 插件，或者更轻量地在 Nginx 层面对 wp-login.php 做访问控制。

这些操作说起来简单，但每一条都能挡住一批常见的自动化攻击脚本。我在 Nginx 访问日志里，几乎每天都能看到针对 wp-login.php 的暴力尝试，做好这些基础防御非常有必要。

6. 常见问题与排查技巧实录

命令行装 WordPress，说难不难，但新手上路总会遇到一些“拦路虎”。这里我把自己实操中高频遇到的问题和排查思路整理成一张速查表，方便你遇到时直接对照。

问题现象	可能原因	排查/解决命令或方法
`wp` 命令找不到	Phar 包没进入 PATH	用绝对路径 `php /usr/local/bin/wp --info`，或确认 `/usr/local/bin` 是否在 PATH 中
`Error: Can’t connect to MySQL`	数据库账号密码错误，或 MySQL 未启动	`systemctl status mysql` 检查服务；用 `mysql -u wp_user -p` 验证账号
`Error: The site is not installed`	数据库为空，`wp core install` 未执行成功	执行 `wp db query "SHOW TABLES;"` 查看是否有表，重新执行 `wp core install`
浏览器访问出现 403	目录权限过严，或 index.php 缺失	确认 `ls -la /var/www/html/myblog/index.php`，检查目录为 755、文件为 644
WordPress 首页正常，但内页 404	固定链接与 Nginx/Apache 重写规则不匹配	Nginx 添加 `try_files $uri $uri/ /index.php?$args;` 后重载配置
图片上传提示“无法创建目录”	`wp-content/uploads` 不属于 Web 用户	`sudo chown -R www-data:www-data /var/www/html/myblog/wp-content/uploads`
`wp core install` 提示 PHP 版本过低	PHP 版本不满足 WordPress 要求	升级 PHP 到 8.1+，并确认 `php -v` 生效
下载 WP-CLI 时 SSL 报错	系统 CA 证书过期	`sudo apt install ca-certificates`，再重新下载
后台无法在线安装插件，提示需要 FTP 信息	`FS_METHOD` 未设为 direct	在 wp-config.php 加 `define('FS_METHOD','direct');`，或直接用 `wp config set FS_METHOD direct`

再单独展开一个“经典”问题，因为这个坑几乎每个用 Nginx 的人都踩过。

有一次我给一个客户部署站点，wp core install 明明提示成功了，浏览器打开首页也正常，可一点进文章页就 404。我第一反应是 Nginx 没配 rewrite，检查了一下，try_files 在。然后又想可能是固定链接结构没生成规则，重新执行 wp rewrite structure '/%postname%/' --hard 并刷新，依然 404。最后翻 Nginx 的 error.log，才发现是 location ~ \.php$ 块里的 fastcgi_pass 配的 PHP-FPM 套接字路径不对。因为服务器是编译安装的 PHP 8.2，套接字路径和 apt 安装的不一样，Nginx 找不到 PHP-FPM，动态请求全部失败。

这个问题很典型：有时候 WordPress 本身没有任何错误，问题出在 Web 服务器和 PHP 的对接上。所以遇到“首页能开、内页打不开”的情况，除了检查 rewrite 规则，还要顺手看一下 nginx -t 和 tail -f /var/log/nginx/error.log，别只看 WordPress 这一层。

还有一个很多人问过的坑：明明用 root 执行了所有命令，但安装插件时依然提示“Could not create directory”。原因就是前面提到的 Web 服务器运行用户是 www-data，而文件权限归 root，两者不匹配。解决办法就是第 4.4 节说的目录属主调整，把站点整目录交给 www-data。

最后说说 wp-config.php 的读写权限。有些安全教程建议把它改成 400 或 440，这个从安全角度看没问题。但在命令行部署阶段，我建议先保持 644，等所有配置都改完、站点稳定运行几天后再收紧。因为如果后面需要执行 wp config set 之类的命令来改配置，文件没有写权限会直接报错。这就是“先保功能，再保安全”的部署顺序问题。

7. 扩展思路：命令行部署 WordPress 还能做什么

安装只是 WP-CLI 能力的冰山一角。当你真正习惯了用命令行管理 WordPress，会发现在很多场景下效率比后台点鼠标高一个量级。

比如日常更新。以前在后台看到“有 N 个插件可更新”，你需要一个插件一个插件地点，每点一次都要等页面刷新。现在一条命令搞定：

bash复制wp plugin update --all
wp theme update --all
wp core update

如果担心更新导致兼容性问题，还可以用 WP-CLI 的数据库备份和恢复功能，在更新前一键备份：

bash复制# 备份数据库到 SQL 文件
wp db export backups/backup-$(date +%Y%m%d).sql

# 更新出错后恢复
wp db import backups/backup-20250101.sql

注意，wp db export 导出的只是数据库，主题、插件文件不在里面，完整备份还需要另外打包 wp-content 目录和配置文件。但只针对更新操作，数据库备份用在绝大多数场景下已经够用了。

再比如用户管理。当你需要在站里新建一个编辑账号时，后台点一圈非常麻烦，命令行直接搞定：

bash复制wp user create editor-user editor@example.com --role=editor --user_pass='密码'

如果你想批量查看站里所有用户，执行：

bash复制wp user list --fields=ID,user_login,user_email,roles

输出格式是表格，一目了然。

还有 cron 任务管理。WordPress 有自己的一套伪 cron 机制，它是在用户访问站点时触发检查的，流量低的站点可能会导致定时任务不准确。在命令行的世界里，你可以直接在系统 crontab 里写一行：

bash复制*/5 * * * * wp cron event run --path=/var/www/html/myblog >> /dev/null 2>&1

这样一来，定时任务完全交给系统 cron，不再依赖站点访问流量，逻辑上更可靠。很多高流量站点都是用这种方式替代 WordPress 默认的伪 cron 的。

还有个隐藏玩法：wp search-replace。假如你需要把站点的域名从 old-domain.com 换成 new-domain.com，直接改数据库替换内容即可：

bash复制wp search-replace 'http://old-domain.com' 'http://new-domain.com' --all-tables

在后台你可能得借助 Velvet Blues Update URLs 之类的插件才能完成域名替换，而且有时候还会漏掉序列化数据。WP-CLI 的 search-replace 天然考虑了序列化数据问题，执行起来非常可靠。

这些操作组合在一起，其实就是一套完整的 WordPress 服务器端管理方案。你会惊讶地发现，从安装到日常维护，根本不需要碰浏览器后台几次。

8. 我的个人体会与一点建议

我在很多台服务器上用这套流程装过 WordPress，从腾讯云轻量服务器到自己的小主机都试过。第一次用 WP-CLI 时，我还觉得命令行做这种事很别扭，等真正熟悉之后，就再不想回到浏览器安装了。不为别的，单是那种“一条命令装好一个站”的确定感，就足够让人上瘾。

有些读者可能会纠结：我连 SSH 都不太熟，直接学命令行装站会不会太跳跃？我的建议是先按文中的步骤走一遍，遇到不会的再回头补 SSH 基础，这比先啃几周 Linux 再回来装站要实际得多。实际操作会逼着你学会看报错、看日志，这些能力比工具本身更重要。

最后分享一个小技巧：在第一次执行 wp core install 之前，先去 wp-config.php 里看一眼数据库配置是否真的是你想要用的库。之前我在一台测试机上执行命令，结果发现连的是本地已有数据库，差点把别人的表给覆盖了。检查一下，避免手滑，这个习惯能帮你省下很多麻烦。