Drush 完全指南：Drupal 開發者的命令列瑞士刀
前言
對任何長期經營 Drupal 網站的人來說，Drush（Drupal Shell）幾乎是不可或缺的工具。它讓你可以透過命令列完成絕大多數原本需要在瀏覽器後台一步步點擊才能做到的事：清除快取、匯出匯入設定、跑資料庫更新、管理模組與使用者、甚至直接在 Drupal 的執行環境裡跑一段 PHP 程式碼。對於日常維運多個 Drupal 網站、或是需要透過 SSH 遠端操作伺服器的開發者而言，Drush 節省的時間往往是以「小時」而非「分鐘」計算的。
這篇文章會從 Drush 的基本概念開始，逐步介紹安裝方式、核心指令、site alias 的遠端操作機制，以及它在實際部署流程中扮演的角色，最後談談使用上需要注意的安全考量。
Drush 是什麼、為什麼需要它
Drush 官方的自我介紹是「a command-line shell and scripting interface for Drupal」，也就是說它不只是一組指令集合，而是一個能夠完整載入 Drupal 執行環境（bootstrap）並在其中操作的腳本介面。這一點很關鍵：Drush 執行任何指令時，實際上都是先把 Drupal 的核心、資料庫連線、模組系統等一併載入，才在這個已經初始化好的環境裡執行對應的邏輯。這也是為什麼 Drush 能做到「清快取」「跑 update hook」「操作實體（entity）」這類必須依賴 Drupal 內部狀態的工作，而不只是單純操作資料庫或檔案系統的外部工具。
比起在瀏覽器後台操作，用 Drush 的好處很直接：可以寫成腳本重複執行、可以透過 SSH 對遠端伺服器批次操作多個網站、可以整合進 CI/CD 部署流程、也不受限於後台介面的逾時或分頁限制（例如要一次匯入上千筆設定變更）。
安裝與版本
現在的標準作法是透過 Composer 把 Drush 安裝成專案的開發相依套件，而不是像早期版本那樣全域安裝一套獨立於專案之外的 Drush：
cd /path/to/your/drupal/project
composer require drush/drush
安裝完成後執行檔會放在專案的 vendor/bin/drush，之後所有指令都建議透過這個路徑執行（或是把 vendor/bin 加進 PATH），這樣可以確保每個專案使用的 Drush 版本跟該專案的 Drupal 版本相容，不會因為全域版本不一致而出錯。
截至目前，Drush 的主線版本是 13.x（如 13.7.6），需要 PHP 8.3 以上，對應支援 Drupal 10.4 以後的版本與 Drupal 11.x。如果專案還停留在較舊的 Drupal 8 或 9，則需要對應使用 Drush 10 或 11 系列，版本之間的相依關係在升級專案時必須特別留意，通常 composer require drush/drush 會自動幫你解出相容版本，但混合升級 Drupal 核心與 Drush 時仍建議分開處理、逐步驗證。
安裝完成後，第一件事通常是確認 Drush 有沒有正確認出網站的狀態：
drush status
簡寫是 drush st，這個指令會列出 Drupal 版本、PHP 版本、資料庫連線狀態、網站根目錄、預設的 site alias 等資訊，是排查任何問題時的第一個動作——如果 drush status 都跑不出正確資訊，後面的指令基本上也不用試了。
日常最常用的指令分類
快取管理
drush cache:rebuild（簡寫 drush cr）是使用頻率最高的指令，沒有之一。舉凡改了設定檔、路由（routing）、外掛的定義、或是任何看起來「明明改了但畫面沒變」的情況，第一反應通常都是先清快取。舊版 Drush（7.x 以前對應 Drupal 7）用的是drush cache-clear all，但在 Drupal 8 以後的架構下，drush cr 已經是慣用的標準做法。
模組與佈景主題
啟用、停用、解除安裝模組是另一組高頻指令：
drush pm:enable module_name # 簡寫 drush en
drush pm:uninstall module_name # 簡寫 drush pmu
drush pm:list # 列出所有模組與主題的啟用狀態
設定（Configuration）管理
Drupal 8 之後導入的 Configuration Management 系統，讓網站的設定可以用 yml 檔案的形式匯出、版本控制、再匯入到另一個環境，這也是 Drush 發揮最大價值的地方之一：
drush config:export # 簡寫 drush cex，把資料庫中的設定匯出成 yml
drush config:import # 簡寫 drush cim，把 yml 檔匯入資料庫
實務上的標準流程通常是：在本地開發環境調整設定 → drush cex 匯出 → 提交進版控 → 部署到正式站後執行 drush cim 套用。這一組指令搭配 Git，基本上取代了過去「開發者要手動記得在正式站重複點一次後台設定」的做法，也大幅降低了環境之間設定漂移（configuration drift）的風險。
資料庫更新
模組如果帶有 hook_update_N()，在部署新版程式碼後必須執行：
drush updatedb # 簡寫 drush updb
一個常見的完整部署流程會是 composer install（更新程式碼與相依套件）→ drush updatedb（跑資料庫結構更新）→ drush config:import（套用設定變更）→ drush cache:rebuild（清快取），這四個步驟的順序通常不能任意調換，因為後面的步驟可能依賴前面步驟已經完成的資料庫結構或設定狀態。
資料庫操作
drush sql:dump # 匯出整個資料庫
drush sql:cli # 直接進入資料庫的命令列介面
drush sql:sync @production @local # 在不同環境之間同步資料庫（需搭配 site alias）
sql:sync 特別適合用在「把正式站資料庫拉到本地除錯」的情境，省去手動 dump、傳輸、import 的繁瑣步驟。
使用者管理
drush user:login # 簡寫 drush uli，產生一次性登入連結
drush user:password # 重設密碼
drush user:block / user:unblock
drush uli 是本地開發時最實用的指令之一：不需要記密碼，直接產生一條有時效性的登入連結，貼到瀏覽器就能以管理員身份登入，對於忘記密碼或是剛部署好的新環境特別方便。
日誌與除錯
drush watchdog:show # 簡寫 drush ws，查看系統日誌（相當於後台的 Recent log messages）
drush watchdog:tail # 持續監看新產生的日誌，類似 tail -f
直接執行 PHP
drush php:eval "return \Drupal::state()->get('system.cron_last');"
drush php:script my-script.php
這組指令讓你可以直接在 Drupal 完整 bootstrap 過的環境裡執行任意 PHP 程式碼，等於擁有了跟寫模組程式碼幾乎同等的存取權限，常用在一次性的資料修復腳本、批次更新內容等場景。也因為權限極高，這類指令特別需要謹慎使用（詳見後面的安全性段落）。
Cron
drush core:cron # 手動觸發一次 cron 執行
在伺服器上通常會用系統的 crontab 排程呼叫這個指令，取代 Drupal 早期依賴使用者瀏覽觸發 cron 的機制，讓排程任務可以穩定地在背景執行，不受站點流量影響。
Site Alias：遠端與多站點操作的核心機制
如果只在單一環境操作，前面介紹的指令已經很夠用；但 Drush 真正強大的地方在於 site alias 機制。透過在專案中定義 drush.yml 設定檔，可以把不同環境（本地、測試站、正式站）的連線資訊（SSH 主機、網站根目錄路徑等）分別命名，之後就能用同一套指令搭配 @別名 對任何一個環境下指令：
drush @production status
drush @production cache:rebuild
drush sql:sync @production @local
這對於管理多個環境、甚至同時維護多個客戶網站的開發者來說非常實用——不需要每次都手動 SSH 進去再切目錄執行指令，一行指令就能對指定的遠端環境操作，也讓「把正式站資料庫同步到本地除錯」這類原本繁瑣的流程變成一條指令。
進階：自訂指令與 drush generate
Drush 9 以後採用 Symfony Console 作為底層指令框架，讓開發者可以在自訂模組裡用標準的 Symfony Command 寫法擴充 Drush 指令，也提供了 drush generate 系列指令，可以快速產生模組、外掛（plugin）、事件訂閱者等程式碼骨架，省去手動建立目錄結構與樣板程式碼的時間：
drush generate module my_module
drush generate plugin:block my_block
這對於需要頻繁建立自訂模組的開發流程來說，是個容易被忽略但相當實用的功能。
安全性考量
因為 Drush 是直接在 Drupal 完整權限的環境下執行，它等同於（甚至可能超過）網站管理員帳號的權限——drush php:eval 可以執行任意 PHP、drush user:password 可以重設任何人的密碼、drush sql:cli 可以直接操作資料庫。因此，能執行 Drush 的 SSH 帳號等於是網站的最高權限入口，實務上需要注意幾件事：不要把正式站的 SSH 存取權限開放給不需要的人；透過 CI/CD 執行 Drush 指令時，部署金鑰與環境變數（尤其是資料庫密碼）要妥善管理，避免寫死在版控裡；drush sql:sync 把正式站資料庫拉到本地時，記得本地環境的資料保護規範是否也涵蓋這些真實使用者資料，必要時搭配 drush sql:sanitize 做資料去識別化處理後再使用。
結語
Drush 之所以能在 Drupal 生態圈中維持這麼長時間的核心地位，關鍵在於它把「操作 Drupal」這件事從瀏覽器點擊變成可重複、可腳本化、可版本控制的流程。無論是日常維運時的清快取、模組管理，還是部署流程裡的設定同步與資料庫更新，或是多環境之間的資料庫同步與遠端操作，Drush 幾乎都能找到對應的指令一次到位。熟悉這套工具，對任何長期經營 Drupal 網站或同時維護多個 Drupal 專案的開發者來說，都是提升效率的必要投資。
Drush 完全指南：Drupal 開發者的命令列瑞士刀
前言
對任何長期經營 Drupal 網站的人來說，Drush（Drupal Shell）幾乎是不可或缺的工具。它讓你可以透過命令列完成絕大多數原本需要在瀏覽器後台一步步點擊才能做到的事：清除快取、匯出匯入設定、跑資料庫更新、管理模組與使用者、甚至直接在 Drupal 的執行環境裡跑一段 PHP 程式碼。對於日常維運多個 Drupal 網站、或是需要透過 SSH 遠端操作伺服器的開發者而言，Drush 節省的時間往往是以「小時」而非「分鐘」計算的。
這篇文章會從 Drush 的基本概念開始，逐步介紹安裝方式、核心指令、site alias 的遠端操作機制，以及它在實際部署流程中扮演的角色，最後談談使用上需要注意的安全考量。
Drush 是什麼、為什麼需要它
Drush 官方的自我介紹是「a command-line shell and scripting interface for Drupal」，也就是說它不只是一組指令集合，而是一個能夠完整載入 Drupal 執行環境（bootstrap）並在其中操作的腳本介面。這一點很關鍵：Drush 執行任何指令時，實際上都是先把 Drupal 的核心、資料庫連線、模組系統等一併載入，才在這個已經初始化好的環境裡執行對應的邏輯。這也是為什麼 Drush 能做到「清快取」「跑 update hook」「操作實體（entity）」這類必須依賴 Drupal 內部狀態的工作，而不只是單純操作資料庫或檔案系統的外部工具。
比起在瀏覽器後台操作，用 Drush 的好處很直接：可以寫成腳本重複執行、可以透過 SSH 對遠端伺服器批次操作多個網站、可以整合進 CI/CD 部署流程、也不受限於後台介面的逾時或分頁限制（例如要一次匯入上千筆設定變更）。
安裝與版本
現在的標準作法是透過 Composer 把 Drush 安裝成專案的開發相依套件，而不是像早期版本那樣全域安裝一套獨立於專案之外的 Drush：
cd /path/to/your/drupal/project
composer require drush/drush
安裝完成後執行檔會放在專案的 vendor/bin/drush，之後所有指令都建議透過這個路徑執行（或是把 vendor/bin 加進 PATH），這樣可以確保每個專案使用的 Drush 版本跟該專案的 Drupal 版本相容，不會因為全域版本不一致而出錯。
截至目前，Drush 的主線版本是 13.x（如 13.7.6），需要 PHP 8.3 以上，對應支援 Drupal 10.4 以後的版本與 Drupal 11.x。如果專案還停留在較舊的 Drupal 8 或 9，則需要對應使用 Drush 10 或 11 系列，版本之間的相依關係在升級專案時必須特別留意，通常 composer require drush/drush 會自動幫你解出相容版本，但混合升級 Drupal 核心與 Drush 時仍建議分開處理、逐步驗證。
安裝完成後，第一件事通常是確認 Drush 有沒有正確認出網站的狀態：
drush status
簡寫是 drush st，這個指令會列出 Drupal 版本、PHP 版本、資料庫連線狀態、網站根目錄、預設的 site alias 等資訊，是排查任何問題時的第一個動作——如果 drush status 都跑不出正確資訊，後面的指令基本上也不用試了。
日常最常用的指令分類
快取管理
drush cache:rebuild（簡寫 drush cr）是使用頻率最高的指令，沒有之一。舉凡改了設定檔、路由（routing）、外掛的定義、或是任何看起來「明明改了但畫面沒變」的情況，第一反應通常都是先清快取。舊版 Drush（7.x 以前對應 Drupal 7）用的是drush cache-clear all，但在 Drupal 8 以後的架構下，drush cr 已經是慣用的標準做法。
模組與佈景主題
啟用、停用、解除安裝模組是另一組高頻指令：
drush pm:enable module_name # 簡寫 drush en
drush pm:uninstall module_name # 簡寫 drush pmu
drush pm:list # 列出所有模組與主題的啟用狀態
設定（Configuration）管理
Drupal 8 之後導入的 Configuration Management 系統，讓網站的設定可以用 yml 檔案的形式匯出、版本控制、再匯入到另一個環境，這也是 Drush 發揮最大價值的地方之一：
drush config:export # 簡寫 drush cex，把資料庫中的設定匯出成 yml
drush config:import # 簡寫 drush cim，把 yml 檔匯入資料庫
實務上的標準流程通常是：在本地開發環境調整設定 → drush cex 匯出 → 提交進版控 → 部署到正式站後執行 drush cim 套用。這一組指令搭配 Git，基本上取代了過去「開發者要手動記得在正式站重複點一次後台設定」的做法，也大幅降低了環境之間設定漂移（configuration drift）的風險。
資料庫更新
模組如果帶有 hook_update_N()，在部署新版程式碼後必須執行：
drush updatedb # 簡寫 drush updb
一個常見的完整部署流程會是 composer install（更新程式碼與相依套件）→ drush updatedb（跑資料庫結構更新）→ drush config:import（套用設定變更）→ drush cache:rebuild（清快取），這四個步驟的順序通常不能任意調換，因為後面的步驟可能依賴前面步驟已經完成的資料庫結構或設定狀態。
資料庫操作
drush sql:dump # 匯出整個資料庫
drush sql:cli # 直接進入資料庫的命令列介面
drush sql:sync @production @local # 在不同環境之間同步資料庫（需搭配 site alias）
sql:sync 特別適合用在「把正式站資料庫拉到本地除錯」的情境，省去手動 dump、傳輸、import 的繁瑣步驟。
使用者管理
drush user:login # 簡寫 drush uli，產生一次性登入連結
drush user:password # 重設密碼
drush user:block / user:unblock
drush uli 是本地開發時最實用的指令之一：不需要記密碼，直接產生一條有時效性的登入連結，貼到瀏覽器就能以管理員身份登入，對於忘記密碼或是剛部署好的新環境特別方便。
日誌與除錯
drush watchdog:show # 簡寫 drush ws，查看系統日誌（相當於後台的 Recent log messages）
drush watchdog:tail # 持續監看新產生的日誌，類似 tail -f
直接執行 PHP
drush php:eval "return \Drupal::state()->get('system.cron_last');"
drush php:script my-script.php
這組指令讓你可以直接在 Drupal 完整 bootstrap 過的環境裡執行任意 PHP 程式碼，等於擁有了跟寫模組程式碼幾乎同等的存取權限，常用在一次性的資料修復腳本、批次更新內容等場景。也因為權限極高，這類指令特別需要謹慎使用（詳見後面的安全性段落）。
Cron
drush core:cron # 手動觸發一次 cron 執行
在伺服器上通常會用系統的 crontab 排程呼叫這個指令，取代 Drupal 早期依賴使用者瀏覽觸發 cron 的機制，讓排程任務可以穩定地在背景執行，不受站點流量影響。
Site Alias：遠端與多站點操作的核心機制
如果只在單一環境操作，前面介紹的指令已經很夠用；但 Drush 真正強大的地方在於 site alias 機制。透過在專案中定義 drush.yml 設定檔，可以把不同環境（本地、測試站、正式站）的連線資訊（SSH 主機、網站根目錄路徑等）分別命名，之後就能用同一套指令搭配 @別名 對任何一個環境下指令：
drush @production status
drush @production cache:rebuild
drush sql:sync @production @local
這對於管理多個環境、甚至同時維護多個客戶網站的開發者來說非常實用——不需要每次都手動 SSH 進去再切目錄執行指令，一行指令就能對指定的遠端環境操作，也讓「把正式站資料庫同步到本地除錯」這類原本繁瑣的流程變成一條指令。
進階：自訂指令與 drush generate
Drush 9 以後採用 Symfony Console 作為底層指令框架，讓開發者可以在自訂模組裡用標準的 Symfony Command 寫法擴充 Drush 指令，也提供了 drush generate 系列指令，可以快速產生模組、外掛（plugin）、事件訂閱者等程式碼骨架，省去手動建立目錄結構與樣板程式碼的時間：
drush generate module my_module
drush generate plugin:block my_block
這對於需要頻繁建立自訂模組的開發流程來說，是個容易被忽略但相當實用的功能。
安全性考量
因為 Drush 是直接在 Drupal 完整權限的環境下執行，它等同於（甚至可能超過）網站管理員帳號的權限——drush php:eval 可以執行任意 PHP、drush user:password 可以重設任何人的密碼、drush sql:cli 可以直接操作資料庫。因此，能執行 Drush 的 SSH 帳號等於是網站的最高權限入口，實務上需要注意幾件事：不要把正式站的 SSH 存取權限開放給不需要的人；透過 CI/CD 執行 Drush 指令時，部署金鑰與環境變數（尤其是資料庫密碼）要妥善管理，避免寫死在版控裡；drush sql:sync 把正式站資料庫拉到本地時，記得本地環境的資料保護規範是否也涵蓋這些真實使用者資料，必要時搭配 drush sql:sanitize 做資料去識別化處理後再使用。
結語
Drush 之所以能在 Drupal 生態圈中維持這麼長時間的核心地位，關鍵在於它把「操作 Drupal」這件事從瀏覽器點擊變成可重複、可腳本化、可版本控制的流程。無論是日常維運時的清快取、模組管理，還是部署流程裡的設定同步與資料庫更新，或是多環境之間的資料庫同步與遠端操作，Drush 幾乎都能找到對應的指令一次到位。熟悉這套工具，對任何長期經營 Drupal 網站或同時維護多個 Drupal 專案的開發者來說，都是提升效率的必要投資。