後台跑半天的批次更新、卡在「正在匯入」轉圈圈的內容搬移、外掛衝突害你連 wp-admin 都進不去——這些在瀏覽器裡讓人血壓上升的場景，換到主機端用 WP-CLI 教學裡的指令來做，往往幾秒就收工。WP-CLI 是 WordPress 官方的命令列工具，凡是你在後台點得到的功能，幾乎都能在終端機用一行指令完成，而且還能做很多後台根本辦不到的事，例如直接改資料庫字串、回滾外掛版本、一次產生測試內容。
這篇不只是把指令列出來，而是用 20 個真實會遇到的主機端情境串起來：每個情境告訴你「什麼時候該用它」「指令怎麼下」「下之前要先注意什麼」。讀者是已經會用 WordPress、手上有 SSH 權限、想把維運效率拉高的站長與接案者。看完你應該能直接在自己的主機上操作，而不是再回去後台一頁一頁點。
WP-CLI 是什麼，跟 WordPress 後台差在哪
WP-CLI 是 WordPress 的官方命令列介面，讓你透過終端機下指令來管理整個網站，不必開瀏覽器登入 wp-admin。它由開源社群維護，跟著 WordPress 核心走固定的釋出週期，每隔幾個月更新一次，持續加入新指令與效能改進。
跟後台最大的差別在三件事。第一是速度，建一個使用者、停用一批外掛，在後台要點過好幾個畫面，用指令一行就送出。第二是「後台進不去時的救援能力」，當外掛衝突或佈景主題壞掉導致 wp-admin 白畫面，你仍然可以從主機端停用問題外掛、切回預設佈景主題。第三是後台辦不到的操作，像是直接在資料庫做字串搜尋取代、回滾到外掛舊版本、批量生成假內容，這些都只有命令列做得到。
指令的基本結構是固定的，理解它你就能讀懂幾乎所有指令：
wp <主指令> <子指令> [參數] [--旗標] [--旗標=值]
每一行都以 wp 開頭，告訴系統這是一條 WP-CLI 指令，後面接主指令（例如 plugin）與子指令（例如 list）。參數是操作對象，旗標以兩個減號開頭，用來開關選項或傳值。任何指令後面加上 --help，就會印出它所有的子指令與旗標說明，這是你最該記住的一招——指令記不全沒關係，會查就好。
主機沒裝 WP-CLI 怎麼自己裝上去
先確認主機到底有沒有裝。SSH 連上主機後輸入 wp cli version，如果回傳類似 WP-CLI 2.12.0 的版本號就代表已安裝；若回傳 command not found: wp 就要自己裝。台灣常見的虛擬主機（多數 cPanel 環境）其實大多已內建，部分主機商甚至要求你用完整路徑或別名呼叫，這點稍後會談到。
要自己安裝，先確定主機有 SSH 權限、且 PHP 與 curl 可用，接著下載官方的 phar 執行檔：
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
下載後驗證它能不能跑，這一步會印出 PHP 設定資訊，沒報錯就代表正常：
php wp-cli.phar --info
最後把它搬到系統 PATH 內並改名為 wp，往後就能直接輸入 wp 呼叫：
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
有一個共享主機常見的坑要先講：在 cPanel 環境下，如果你打算用 WP-CLI 從頭建立一個全新網站，由 cPanel 管理資料庫的方式，往往會讓 WP-CLI 自己建的資料庫無法正常存取。實務做法是先在 cPanel 後台手動建好 MySQL 資料庫與使用者並給足權限，再用 WP-CLI 接手後續安裝。若主機沒給你把檔案搬進 /usr/local/bin 的權限，也可以把 phar 放在家目錄，用 php ~/wp-cli.phar 的完整路徑來跑。
在執行任何破壞性指令前該養成的習慣
這節要先講安全，因為後面好幾個情境會動到資料庫，弄錯了沒有「上一步」可以按。指令列的威力跟風險是一體兩面，後台至少還會跳確認視窗，命令列按下 Enter 通常就直接執行了。
養成三個習慣。第一、會改資料庫的指令先用 --dry-run 試跑，它只會告訴你「將會改動幾筆」而不真的寫入，確認數字合理再拿掉旗標正式執行。第二、動資料庫之前先備份，後面會教你用一行指令匯出整個資料庫。第三、避免在不清楚後果的情況下用 root 身分或 --allow-root 操作；那個旗標是讓指令能在 root 環境執行，方便沒錯，但權限全開意味著打錯字的代價更高，能用一般網站使用者身分跑就別動用最高權限。
另外提醒，WP-CLI 多數指令需要在 WordPress 安裝目錄下執行，它才找得到 wp-config.php。如果你不想每次都 cd 過去，可以在指令後面加 --path=/網站的絕對路徑 指定位置。
一行指令安裝、更新、回滾外掛
外掛管理是 WP-CLI 最有感的地方。先看現況，列出站上所有外掛、版本與是否有可更新版本：
wp plugin list
加旗標可以過濾，例如只看有更新的，或只看啟用中的：
wp plugin list --update=available
wp plugin list --status=active
安裝外掛用 install，後面接的是外掛在 WordPress.org 外掛目錄頁網址裡的 slug，可以一次裝多個，加 --activate 就連帶啟用：
wp plugin install contact-form-7 akismet --activate
更新則可以一次全部更新，並用 --exclude 排除你還沒測過、不想動的外掛：
wp plugin update --all --exclude=woocommerce
WP-CLI 還有一個後台做不到的本事：把外掛回滾到舊版本。當某次更新讓網站出狀況，你可以直接指定版本退回去，這在後台只能靠額外外掛才辦得到：
wp plugin update woocommerce --version=8.9.1
外掛衝突鎖死後台時怎麼從主機端救回來
當某個外掛更新後造成白畫面、連 wp-admin 都進不去，這正是 WP-CLI 最關鍵的救援場景。因為它不經過瀏覽器登入流程，後台壞掉它照樣能動。
最快的做法是把全部外掛先停用，讓網站回到「乾淨」狀態確認是不是外掛問題：
wp plugin deactivate --all
確認站台恢復後，再一個一個啟用，啟用到哪個出問題，元兇就是它：
wp plugin activate woocommerce
如果已經知道是哪個外掛闖禍，直接停用單一外掛即可，網站不必整批停掉：
wp plugin deactivate problematic-plugin
同樣的邏輯也適用佈景主題。若是換主題後壞掉，先切回 WordPress 預設主題救急：
wp theme activate twentytwentyfive
佈景主題的安裝、切換與子主題建立
佈景主題的指令邏輯跟外掛幾乎一樣。查看已安裝主題、安裝新主題並啟用：
wp theme list
wp theme install twentytwentyfive --activate
更新全部主題，或刪除不再使用的主題（刪不掉啟用中的主題，要先切走）：
wp theme update --all
wp theme delete twentytwentythree
如果你要客製化佈景主題又不想被主題更新蓋掉改動，正確做法是建子主題。WP-CLI 可以直接幫你產生子主題骨架，指定父主題即可：
wp scaffold child-theme my-child --parent_theme=twentytwentyfive
更新與重裝 WordPress 核心，順便驗證檔案完整性
核心管理同樣一行搞定。查目前版本、升級核心、更新資料庫結構：
wp core version
wp core update
wp core update-db
這裡有一個對安全維運很重要的指令：verify-checksums。它會去 WordPress.org 下載對應版本的官方檔案雜湊值，跟你主機上的核心檔案逐一比對，任何被竄改、被新增、被刪除的核心檔案都會被點出來。懷疑網站中了惡意程式時，這通常是第一個該跑的檢查：
wp core verify-checksums
如果比對發現核心檔案被動過手腳，與其一個一個找出來刪，更乾淨的做法是強制重新下載一份原始核心檔覆蓋上去：
wp core download --force
要提醒的是，--force 只覆蓋核心檔案，不會動你的佈景主題、外掛與 wp-content，但動手前仍建議先備份。核心被感染往往代表外掛或主題也可能藏有後門，重裝核心只是第一步，後續仍需逐項排查。
搬家換網址時用 search-replace 一次改乾淨
這是 WP-CLI 在搬站時的招牌功能。WordPress 會把網域硬寫進資料庫的各個角落——文章內容、圖片路徑、頁面連結、序列化的設定值都有。換主機或換網域後若只改 option 裡的網址，圖片與內鏈仍會指向舊網址。
search-replace 能掃過整個資料庫做字串取代，而且它懂得正確處理 PHP 序列化資料，這是手動進 phpMyAdmin 改最容易踩雷、改壞設定的地方。正式執行前一定先用 --dry-run 看會改幾筆：
wp search-replace 'old-domain.com' 'new-domain.com' --dry-run
數字合理就拿掉旗標正式跑。若你的網站用了 HTTPS，記得連協定一起換，並視情況加 --skip-columns=guid（文章的 guid 欄位是歷史識別碼，慣例上不更動）：
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --skip-columns=guid
search-replace 的取代無法復原，這也是為什麼前面一直強調先備份、先 dry-run。
資料庫的匯出、匯入與最佳化
大型網站搬家最常卡關的，就是資料庫太大、用 phpMyAdmin 匯入直接失敗，一般超過 200MB 的資料庫就容易出狀況。WP-CLI 直接從命令列吞吐資料庫，繞開了網頁介面的上傳限制與逾時。
備份就是把整個資料庫匯出成一個 SQL 檔，這也是你做任何破壞性操作前該先跑的保險：
wp db export backup.sql
匯入則是反向操作，把 SQL 檔灌回去：
wp db import backup.sql
網站用久了資料表會變得臃腫，最佳化指令可以重整資料表、回收空間：
wp db optimize
需要直接下 SQL 查詢時，wp db query 可以讓你不開 phpMyAdmin 就執行查詢，但這屬於進階操作，下手前務必清楚自己在改什麼。
重設使用者密碼與批量管理帳號
當管理員忘記密碼、信箱又收不到重設信，從主機端改密碼最直接。先列出使用者找出目標帳號的 ID 或帳號名：
wp user list
接著更新該使用者的密碼。要特別注意，WordPress 6.8 之後核心改用 BCrypt 來雜湊密碼，過去那種進 phpMyAdmin 手動塞 MD5 雜湊值的老方法已不再適用，用 WP-CLI 改才能確保密碼以正確的方式被加密儲存：
wp user update admin --user_pass='你的新密碼'
需要新增帳號、或為測試環境快速生出一批使用者時也很方便。建立單一管理員、或一次產生多個指定角色的測試帳號：
wp user create newuser user@example.com --role=administrator --user_pass='密碼'
wp user generate --count=5 --role=editor
批量建立、刪除與重新指派文章
內容操作是 WP-CLI 省時的另一個重點。要在後台一次刪掉上千篇文章是場苦差事，命令列用一行就能清空。先列出文章 ID，再把這些 ID 餵給刪除指令，--force 代表略過垃圾桶直接永久刪除：
wp post delete $(wp post list --post_type='post' --format=ids) --force
把上面的 --post_type 換成自訂文章類型的名稱，就能針對特定類型清理。
批量建立文章常用在初始化網站或建測試資料，例如建立一個發佈狀態的頁面：
wp post create --post_type=page --post_title='關於我們' --post_status=publish
當你刪除了某個作者帳號，他名下的文章需要轉移時，可以把文章重新指派給另一位使用者，避免文章變成無主孤兒。
媒體縮圖跑掉時一次重新產生
換了佈景主題、或調整了縮圖尺寸設定後，舊圖片的縮圖尺寸常常對不上新版型，導致版面破圖。後台得靠額外外掛才能批次重生縮圖，WP-CLI 內建就能做：
wp media regenerate
加上 --yes 可以略過確認、自動對所有圖片執行；只想針對特定圖片，就帶上該附件的 ID。當媒體庫圖片被卸載到 S3 之類的第三方雲端空間時，這個指令也常被用來觸發相關外掛把圖片重新上傳到雲端。
匯入內容遇到 PHP 逾時就改用命令列
用 WordPress 內建的「工具→匯入」搬文章與圖片時，檔案一大就容易撞上 PHP 執行逾時，匯到一半失敗。改用 WP-CLI 的匯入指令走的是命令列，不受網頁請求的逾時限制：
wp import content.xml --authors=create
--authors 決定遇到不存在的作者時怎麼處理：create 是自動建立對應的作者帳號，skip 則是把文章作者留空。匯入大型檔案前，這比在瀏覽器裡盯著進度條重試靠譜得多。
用 wp cron 排查與手動觸發排程任務
WordPress 的排程（WP-Cron）依賴有人造訪網站才會被觸發，流量低的站常出現排程該跑沒跑的問題。WP-CLI 讓你直接檢視與手動觸發。列出目前所有已排程事件，看看有沒有卡住或漏跑：
wp cron event list
需要立刻把到期該執行的排程跑完，不必等下一次造訪觸發：
wp cron event run --due-now
排查排程沒生效的問題時，這組指令能幫你確認到底是排程根本沒註冊、還是註冊了卻沒被觸發。
清快取、清過期暫存資料維持資料庫輕盈
網站變慢、資料庫膨脹，很多時候兇手是堆積的暫存資料（transient）與物件快取。WordPress 的過期 transient 有個特性：除非有人去存取它，否則就算過期了也不會自動從 wp_options 資料表清掉，於是越積越多。
手動清掉所有過期的 transient：
wp transient delete --expired
清空物件快取，常在改了設定卻沒生效時用來強制刷新：
wp cache flush
這兩條指令很適合搭配主機的系統排程（系統層級的 crontab）定期執行，讓清理變成自動化的維護工作，資料庫長期維持輕盈。
跑 WooCommerce 等帶有 CLI 指令的外掛任務
WP-CLI 的指令集是可以被外掛擴充的。安裝了支援命令列的外掛後，它們會把自己的指令掛進 wp 底下，讓你從主機端執行原本要進後台才能做的維運。最典型的是 WooCommerce——它提供了讓你查詢與管理商品、訂單等資料的命令列指令。
商店若使用了 Action Scheduler（WooCommerce 用來處理訂單相關背景工作的排程機制），完成的工作紀錄會持續累積在資料庫，時間一長對應的資料表會異常臃腫，直接拖累資料庫效能。從命令列定期檢視與清理這類紀錄，是維持金物流順暢的維運工作之一。這裡只是客觀說明 WP-CLI 能介入這類維運，實際的收款與結帳流程不在本文討論範圍。
要知道某個外掛開放了哪些命令列功能，最快的方法還是那招：在它的主指令後面加 --help，列出所有可用子指令與旗標。
把多條指令串成一句，初始化網站一次到位
WP-CLI 真正的生產力來自串接。你可以用 && 把多條指令連起來，前一條成功才跑下一條，等於一句話完成一連串設定。例如同時裝好兩個常用外掛與一個佈景主題並全部啟用：
wp plugin install contact-form-7 akismet --activate && wp theme install twentytwentyfive --activate
接案者常把整套初始化流程寫成一個 Bash 指令稿（shell script）：從下載核心、產生 wp-config.php、安裝 WordPress、設定時區與日期格式、安裝語言包、移除預設的範例文章與外掛，到裝上慣用外掛，全部寫進一個檔案。需要開新測試站時執行那個檔案，幾秒就生出一個配置好的繁中網站，省去每次重複點後台的工夫。
舉例來說，初始化時把語系與時區一次設定到位，符合台灣的操作習慣：
wp core language install zh_TW --activate
wp option update timezone_string 'Asia/Taipei'
wp option update date_format 'Y-m-d'
寫指令稿時請特別謹慎處理權限：不清楚後果就不要隨意把資料夾權限全開（777）或全程用 root 跑，初始化腳本一旦出錯，破壞範圍會比手動操作大得多。
從安裝到自動化，怎麼把 WP-CLI 變成日常維運的肌肉記憶
把這 20 個情境收斂成一條學習路徑：先確認主機有沒有 WP-CLI、沒有就自己裝上；接著從低風險的查詢類指令（wp plugin list、wp cron event list、wp core verify-checksums）練手感；等到熟悉了指令結構，再進到會改資料庫的操作，而且每一次都先 --dry-run、先 wp db export 備份。真正的效率不是把指令背熟，而是養成「動手前先備份、破壞性操作先試跑、權限能小就不放大」這套反射動作。
下一步，挑你最常重複做的那件事——也許是每次接案都要初始化測試站，也許是每月固定清快取與最佳化資料庫——把它寫成一個指令稿或排進系統排程。當重複勞動被自動化吃掉，你省下的就不只是點滑鼠的那幾分鐘，而是把心力挪回真正需要判斷的工作上。打開終端機，從 wp --info 開始試第一行吧。