MAMP 本機架 WordPress：從測試環境到搬家上線的完整流程

為什麼我堅持「本機先做、上線再做一次」這套雙軌流程

仔細盤點，不少人都曾經在正式上線的 WordPress 後台，直接按下一個外掛的「啟用」，結果整個網站瞬間白畫面，連後台都進不去，心臟差點跳出來？我自己遇過太多次這種驚嚇場面，無論是早年自己不懂事亂裝，還是後來接手別人搞砸的網站，教訓都很一致：在正式主機上直接實驗，等於在高速公路上換輪胎。每一次「應該沒事吧」的僥倖，最後都要花十倍的時間收拾。

這篇要教你的是另一種工作方式：用 MAMP 在你自己的電腦上把 WordPress 跑起來，改版、裝外掛、換主題與 SEO 結構可先在本機驗證，再於 staging 核對正式主機差異。本機環境能隔離許多測試風險，但連外金流、寄信與 API 要使用測試設定，也需備份及限制存取。我會把 Mac 與 Windows 兩條路徑一次講清楚，這部分在 WordPress 架站全攻略 的本機架站段有整體脈絡，並補上大多數教學略過不談的虛擬主機、正式主機對齊、SEO 測試流程，還有出問題時的排查手冊。

先給你一個快速重點整理：

• MAMP 是 Mac 與 Windows 都能用的本機伺服器套件，一次裝好 Apache、MySQL、PHP。
• 建立資料庫、把 WordPress 檔案放入實際 Document root，再執行安裝精靈；完成時間會受環境設定與除錯影響。
• 進一步用虛擬主機，可以讓每個專案擁有 myproject.test 這種乾淨網址，不必再寫 localhost/資料夾名。
• 把本機環境調整得跟正式主機一致，你在本機測出來的結果搬上線才不會走樣。
• 本機驗證後，先在 staging 測試遷移與相容性，再規劃正式上線；已有訂單或會員資料的網站要避免整庫覆寫造成新資料遺失。

依 W3Techs 的統計（2026 年 6 月），WordPress 是使用廣泛的內容管理系統，背後有龐大的主機、主題與外掛生態。外掛更新或 PHP 版本變動可能造成相容問題，因此先在本機或 staging 測試，是降低正式站風險的一道安全網，但本機環境仍無法完全複製正式主機。

MAMP 到底是什麼：把一台伺服器塞進你的筆電

MAMP 這個名字拆開來看，其實就是四個字的縮寫：Mac、Apache、MySQL、PHP。換句話說，它就是把一個網站伺服器需要的所有零件，打包成一個你點兩下就能啟動的應用程式。你不用自己一個一個去裝 Apache、去設定 MySQL、去煩惱 PHP 版本對不對，MAMP 一次幫你搞定。

這裡有個容易混淆的地方要先講清楚：名字雖然以 Mac 開頭，但它同時有 Mac 與 Windows 兩個版本，核心用途相近，但安裝路徑、介面與部分功能會因作業系統及版本而異。所以不管你是 macOS 還是 Windows 陣營，都可以用同一套工具、同一套流程，這也是我推薦它給跨平台團隊的主因。同一份交接文件，Mac 與 Windows 同事都能照著走，不會雞同鴨講。

MAMP 分成免費版與 MAMP Pro。免費版可啟動伺服器、跑 WordPress、建立資料庫並用 phpMyAdmin 管理資料表；Pro 版提供較完整的圖形化主機、HTTPS 與環境管理功能。版本功能可能調整，採購前應核對官方比較頁；是否升級要看專案數量與環境需求，不必用固定站點數判斷。

如果你是第一次接觸本機架站，我會建議直接從免費版開始，等真的被「手動改設定檔」這件事煩到了，再回頭升級 Pro。工具是來服務你的工作流程的，不是來炫技的。與其花錢買一堆用不到的功能，不如先把基礎打穩。

下載與安裝：Mac 與 Windows 兩條路徑的完整走法

Mac 上的下載與安裝

到 MAMP 官網下載 macOS 版本。目前官方流程會先取得 MAMP & MAMP PRO Downloader.zip，解壓縮後開啟 Downloader，再由安裝程式把 MAMP 安裝到「應用程式」中的 MAMP 資料夾。MAMP 官方列出 Intel 與 Apple Silicon Mac 的支援條件；實際系統需求與安裝檔格式仍應以下載頁當下說明為準。

macOS 12 Monterey 起不再內建 PHP；若電腦另有 Apache、Docker 或其他本機工具，仍可能與 MAMP 使用相同埠。啟動失敗時先看日誌及占用程序，再停用確認可安全停止的服務或改埠，不要未確認原因便停掉系統服務。

Windows 上的下載與安裝

Windows 版同樣從官網下載 .exe 安裝檔，雙擊執行，一路下一步即可。安裝過程中它會問你要不要安裝額外元件，維持預設勾選就好，沒有需要特別調整的地方。

Windows 上常見問題之一是埠號衝突。80 埠（HTTP）與 443 埠（HTTPS）可能被 IIS、其他網頁伺服器或安全軟體占用。如果 MAMP 啟動時 Apache 顯示錯誤，先查埠號與日誌，再判斷是否為衝突。

可以先用 netstat -ano | findstr :80 找出程序代碼（PID），確認是可安全停止的已知服務後，再從該服務本身或工作管理員停用；不要只看到 PID 就強制結束系統程序。另一條路是把 MAMP 改用其他埠，例如 Apache 8888、MySQL 8889。改埠後網址與部分設定也要帶上埠號，因此仍需重新測試。

啟動伺服器並建立 WordPress 專屬資料庫

安裝完成，打開 MAMP，你會看到一個很陽春的啟動畫面，上面一個大大的「Start Servers」按鈕。按下去，MAMP 會把 Apache 與 MySQL 同時啟動，兩個小燈轉成綠色，就代表伺服器跑起來了。啟動後它通常會自動開啟瀏覽器、連到 MAMP 的歡迎頁（http://localhost 或 http://localhost:8888，視你的埠設定而定），看到這個畫面，代表你的筆電現在已經是一台網站伺服器了。

下一步是幫 WordPress 建一個專屬資料庫。WordPress 所有的文章、頁面、設定、使用者資料，全都存在 MySQL 資料庫裡，所以你得先幫它準備好這個存放空間。流程是這樣：

1. 從 MAMP 的 WebStart／歡迎頁工具選單開啟 phpMyAdmin，避免直接假設其網址與埠號。
2. 進入 phpMyAdmin 後，點左側的「New」，或上方「資料庫」分頁。
3. 在「建立新資料庫」欄位輸入一個名字，例如 wp_local，編碼選 utf8mb4_unicode_ci，按下「建立」。

教學常見的 MAMP 預設 MySQL 帳號與密碼是 root／root，但實際值可能因版本、平台或使用者設定不同，應以 MAMP 歡迎頁或設定畫面顯示的資訊為準。本機也不應假設永遠不會對外開放；若啟用區域網路存取或 tunnel，仍要改用安全憑證。正式環境則應使用獨立且權限受限的資料庫帳號。

編碼為什麼要選 utf8mb4？它和普通 utf8 的差別在於：utf8mb4 能儲存 4 位元組的字元（包含 emoji 與部分罕用漢字），傳統 utf8 做不到。選 utf8mb4 可以避免日後出現「文章裡打了個 emoji，存檔後變成問號亂碼」這種詭異狀況。WordPress 從 4.2 版起也以 utf8mb4 為標準。

放進 WordPress 檔案，跑完五分鐘安裝程序

資料庫準備好，接著把 WordPress 本體放進來。到 WordPress.org 下載最新版（有繁體中文版可選），解壓縮後會得到一個 wordpress 資料夾，裡面就是所有核心檔案。這個步驟和你在正式主機上安裝 WordPress 的流程其實一模一樣，差別只在於檔案放的位置：本機的 htdocs，而非遠端主機的公開目錄。

MAMP 的網站根目錄叫做 htdocs。Mac 上預設在 /Applications/MAMP/htdocs/，Windows 上預設在 C:\MAMP\htdocs\。你要做的，就是把 WordPress 的檔案放進這個 htdocs 裡。有兩種放法：

• 放在根目錄：把 WordPress 資料夾內的檔案放入設定的 Document root；以 Apache 8888 埠為例，網址是 http://localhost:8888/。覆寫既有 index.php 前先確認目錄中沒有要保留的專案。
• 放在子資料夾：把 WordPress 放入 Document root 下的專案資料夾，例如 mystore。若 Apache 使用 8888 埠，網址就是 http://localhost:8888/mystore/。

檔案放好後，用 MAMP 的 My Website 入口或含實際埠號的專案網址開啟安裝精靈。輸入剛建立的資料庫名稱與 MAMP 顯示的帳號、密碼及主機資訊；官方預設示例是 root／root 與 localhost，若曾改過設定，應填實際值。最後設定網站名稱與獨立的 WordPress 管理員密碼。

整個安裝精靈跑完，你會看到「安裝完成」的祝賀畫面，並拿到後台登入網址（在網址後面加上 /wp-admin）。登進去，你的筆電上現在跑著一個完整的 WordPress 網站了。如果你是第一次接觸 WordPress 後台，建議先花十分鐘熟悉左側選單的邏輯，文章、頁面、外觀、外掛、設定這幾個大區塊的位置搞清楚，後續所有調整都會快很多。想用更快的方式把一個能看的站搭起來，30 分鐘快速架站可作為內容與外觀設定的參考；主機、網域、HTTPS 與寄信設定仍須依本機環境調整。

設定虛擬主機與 .test 網域：給每個專案一個乾淨的家

到這裡你的本機 WordPress 已經能跑了，但網址是 localhost/mystore 這種帶子路徑的形式。老實說，它工作起來沒問題，可是有兩個讓我受不了的地方。第一，某些外掛與主題在判斷「網站根網址」時，對子路徑的處理不太乾淨，本機測沒事、搬上線卻出問題，因為正式站通常是用根網址。第二，同時跑三個專案時，網址列全是 localhost/xxx，切來切去很容易搞混現在改的是哪一站。

解法是虛擬主機（Virtual Host）。它的概念很簡單：讓你的 MAMP 伺服器根據「網址」來決定要顯示哪一個資料夾的網站。設定好之後，你在瀏覽器輸入 mystore.test，它就打開 A 專案；輸入 clientb.test，就打開 B 專案，每個專案都像一個獨立的網站，各自擁有乾淨的根網址。如果你想更深入理解背後的運作邏輯，可以參考虛擬主機的完整介紹，這裡我直接給你在 MAMP 上的實作步驟。

三步把一個 .test 網域指向你的專案

1. 改 hosts 檔。Mac 打開終端機，執行 sudo nano /etc/hosts；Windows 以系統管理員身分打開記事本，編輯 C:\Windows\System32\drivers\etc\hosts。在檔案最下方加一行：127.0.0.1 mystore.test，存檔離開。這一行的意思是：告訴你的電腦，以後看到 mystore.test 這個網址，不要去問網際網路，直接連到本機。
2. 改 Apache 的虛擬主機設定。打開 MAMP 的設定（Preferences），找到 Apache 的設定檔 httpd-vhosts.conf（Mac 在 /Applications/MAMP/conf/apache/extra/，Windows 在 C:\MAMP\conf\apache\extra\）。在檔案裡加入一段設定，告訴 Apache：mystore.test 這個網址的文件根目錄指向 htdocs/mystore 那個資料夾。同時記得把 httpd.conf 裡 vhosts 的 include 那行取消註解，設定才會生效。
3. 重啟並核對網址。先確認 Apache 的 Listen 與 VirtualHost 埠一致，再重啟 MAMP。若使用 8888 埠，網址須寫成 http://mystore.test:8888/。既有 WordPress 專案也要備份後更新網站網址及需替換的舊網址，否則可能重新導回 localhost。

第二步裡的 vhosts 設定可以拆成一組 <VirtualHost> 區塊：ServerName 填 hosts 檔加入的網址，DocumentRoot 指向專案資料夾，再用 <Directory> 區塊設定該路徑。若網站依賴 .htaccess 重寫規則，AllowOverride 需允許相應指令；權限也可依需要縮小，不必無條件套用 All。固定連結 404 時，還要一起檢查 rewrite 模組與主機區塊是否真的載入。

Apache 會以相同 IP／埠中的第一個 VirtualHost 處理未匹配的名稱，所以要明確設定 localhost 與各專案的主機區塊，並檢查載入順序。不能假設每版 MAMP 都已附上正確的 localhost 區塊。可用開發者工具查看重新導向與請求網址。

為測試專案使用 .test 可避免與公開 DNS 的一般網域混淆；它是 IANA 列出的特殊用途網域，仍須自行設定 hosts、伺服器與埠。.local 用於 mDNS，不宜當成可任意替換的開發後綴；.dev 則是公開網域，使用時還要處理網域所有權與 HTTPS。

讓本機環境「長得像正式主機」的四個關鍵調整

很多人架完本機站就開始埋頭測試，卻忽略了一個致命問題：你的本機環境跟正式主機長得不一樣。本機的 PHP 版本可能是 8.2，正式主機卻還跑 7.4；本機的記憶體限制很寬鬆，正式主機卻卡得很緊。這會造成一種最讓人抓狂的狀況：本機測一切正常，搬上線卻壞掉，因為兩個環境根本是兩個世界。

要避免這種「本機過、上線掛」的悲劇，你必須在架完站之後，立刻做下面四個對齊動作。這也是我在接手別人的爛攤子時，第一件會檢查的事。

一、把 PHP 版本對齊正式主機

先查正式主機的 PHP 版本與必要擴充，再選擇 MAMP 可提供的相同環境。若正式主機仍使用已停止安全支援的 PHP，不要只複製舊環境就結束；另建測試環境驗證受支援版本的升級。可選版本依 MAMP 版本與平台而異。

二、調高但不要無限放大記憶體限制

WordPress 的記憶體常數與 PHP 實際限制可能不同；預設值也會受現有 PHP 設定及是否 Multisite 影響。先查外掛需求與用量，再核對 WP_MEMORY_LIMIT、WP_MAX_MEMORY_LIMIT 及 PHP memory_limit。256M 或 512M 只是可能的配置，不是所有網站通用的最低值或上限。

三、開啟除錯模式，把錯誤逼出來

本機或 staging 都可用來除錯。可開啟 WP_DEBUG 與 WP_DEBUG_LOG，並用 WP_DEBUG_DISPLAY 控制是否在頁面顯示；含敏感資料的日誌應限制存取。正式站不應向訪客公開錯誤，平時也不宜長期啟用開發除錯設定。

四、固定永久連結結構

?p=123 網址也可被索引。測試站的永久連結應與正式站的既有結構一致；新站可依可讀性選擇結構。Apache 的重寫還取決於模組、主機區塊及 AllowOverride 權限，應依實際指令開放，不需一律設成 All。

這四個動作做完，你的本機環境才算是「可信的測試場」，而非一個會給你假信號的歡樂泡泡。

把本機專案放進版本控制與定時快照

可用 Git 保存自訂主題、程式與不含秘密的設定範本，另記錄外掛版本。不要把資料庫密碼、金流憑證或正式客戶資料提交到版本庫；完整還原還需要資料庫、uploads 與其他必要檔案的備份，SQL 備份不能取代媒體檔案。

這套做法的好處在於：當某次大改把站搞壞了，你能用 Git 的版本紀錄快速回溯「上週這套主題與外掛組合是正常的」，把問題範圍立刻縮小到這幾天的變動。這比憑記憶回想「我到底動了什麼」可靠太多。即便你不用 Git，至少養成每隔幾天就用 phpMyAdmin 匯出一次資料庫、把 htdocs 專案資料夾壓縮一份帶日期的快照丟到雲端硬碟的習慣。本機硬碟不會壞的錯覺，是每一個等到壞了才後悔的人都曾經相信過的事。

在本機安全測試主題、外掛與 SEO 設定的實戰流程

本機架好、環境對齊，接下來就是它真正發揮價值的地方：拿來測試所有你「不敢在正式站上直接做」的事。我把本機最常用的測試場景整理成一套流程，這也是我日常工作的標準動作。

測主題：先試裝、再決定

換主題是 WordPress 最危險的操作之一，因為主題掌控了整個前端的版面與樣式，一換下去選單、頁面模板、小工具位置全部可能走樣。在本機你可以盡情安裝並啟用候選主題，實際套上你的內容看效果，不喜歡就直接刪掉，完全不影響正式站。如果你還在挑選階段，主流 WordPress 主題的比較可以幫你先縮小範圍；像 Astra 這類輕量、SEO 友善的主題，很適合拿來當本機測試的基準，可以用來比較不同頁面編輯器的呈現；即使是常用主題，也仍需驗證目前外掛、版本及客製設定，不能直接排除它造成衝突。

測外掛：衝突排查的黃金戰場

外掛衝突可在備份後的測試環境排查：先建立可重現的步驟，再停用外掛及改用預設主題，比較問題是否仍存在。逐一或分組啟用能縮小範圍，但外掛之間有相依或交互作用時，仍須測試相關組合。挑選值得安裝的 WordPress 外掛清單中的工具，也應先驗證核心流程；若要把 WordPress 資料庫重置回初始狀態，須先確認備份與重置範圍。

測 SEO 結構：網址、Schema、速度都在這裡先驗

這是本機對 SEO 工作者最有價值的一面。Google 把頁面體驗（page experience）納入排名考量已經是多年的事（2020 年 5 月的 頁面體驗評估公告），而行動版載入速度更早就是行動搜尋的排名因素之一（2018 年 1 月的 行動搜尋速度公告）。再加上 Google 已全面採行動優先索引（mobile-first indexing），桌機與行動版的呈現都會被拿來評估（2023 年 10 月的 行動優先索引公告）。

這些因素告訴我們一件事：你不能等上線了才發現網站慢、結構亂。在本機你可以放心地實驗各種 SEO 設定，例如調整永久連結結構、測試不同的標題與中繼描述寫法、啟用結構化資料標記，然後用瀏覽器開發者工具檢查渲染結果。完整的 SEO 優化脈絡可以對照WordPress SEO 全攻略，把裡面的每一項都在本機跑過一次，再挑穩定的部分搬上線。速度方面的調校，像是快取與圖片壓縮的先後順序，也能先在本機對照載入速度優化全攻略做一輪實驗，找出對你的主題與外掛組合最有效的配置。

本機 Lighthouse 是實驗室測試，不能替代真實使用者的 Core Web Vitals 資料。本機仍可能載入第三方腳本，但網路、CPU、快取與訪客條件和正式環境不同；先用它找出資源與呈現問題，上線後再查看實際資料。

結構化資料（Schema）是另一個非常適合在本機先打磨的環節。無論你用佈景主題內建的 Schema 設定，還是額外安裝 SEO 外掛來產生 JSON-LD，本機都能讓你反覆檢視原始碼、對照 Google 官方的結構化資料文件，確認 Article、Breadcrumb、FAQ 這些標記的欄位是否填得正確、有沒有多餘或衝突的標記。等到標記乾淨了再上線，能省下「上線後才被 Search Console 回報結構化資料錯誤」的來回修正。行動版呈現也一樣：MAMP 跑出來的頁面，你可以直接用瀏覽器的裝置模擬工具切換到手機視窗，檢查字級、按鈕間距、選單摺疊在各種寬度下的表現，確認行動版的可讀性與可用性都到位，這在行動優先索引的時代是必修課。

快取與圖片這兩大效能變數，也建議在本機建立一套固定的測量基準。先記下「未裝快取外掛」時首頁的請求數與傳輸量，再逐一啟用你要測的快取方案與圖片壓縮工具，每啟用一項就重新量一次，你會清楚看見每一個工具到底替你省下多少傳輸量、又是否反而拖慢了後台的反應。這份對照表搬到正式站上就是現成的效能調校藍圖，不必在上線後邊摸索邊冒險。

MAMP、Local、DevKinsta、Docker 我會怎麼選

MAMP 不是唯一的本機架站方案。這幾年市面上出現了好幾個各有強項的替代品，我常被問到底該選哪一個。與其丟出一句「看情況而定」的空話，我選擇直接把選擇邏輯講清楚。這張表是我實際用過這幾套工具之後的比較。

如果重視快速建站，自動處理虛擬網域與 HTTPS 的本機工具通常比手動設定 MAMP 省事；主機商提供的開發工具也可能簡化推送流程，但不能保證與正式環境完全一致。團隊若需要可重現環境，可評估 Docker。換工具仍要處理檔案、資料庫、網址與版本差異，成本不一定很低，應先用小型測試站驗證。

這篇以 MAMP 為主，因為手動設定 hosts、virtual hosts 與 PHP 版本，有助於理解本機伺服器的組成。它適合想接觸底層設定的人；若目標只是快速建立可用環境，其他工具可能更合適，沒有單一方案是所有學習者的最佳入口。

MAMP 出問題時的排查手冊：埠號、MySQL、白畫面

本機架站常見問題可以先分成三類，以下整理成可直接執行的排查步驟。若錯誤涉及檔案權限、版本或第三方服務，仍可能需要查看日誌或官方文件。

狀況一：Apache 或 MySQL 啟動失敗（燈號不轉綠）

啟動失敗不只可能是埠號衝突，也可能涉及設定語法、資料目錄或權限。先分別查看 Apache／MySQL 日誌，再確認 MAMP 實際埠號是否被占用。不要強制結束未知的 MySQL 程序，以免影響其他專案或資料庫。

狀況二：安裝精靈卡在資料庫連線錯誤

畫面顯示「Error establishing a database connection」，代表 WordPress 連不上資料庫。依序檢查資料庫名稱、MAMP 顯示的實際帳號密碼、MySQL 服務與埠號。如果 MySQL 不是預設 3306，wp-config.php 的資料庫主機可能要寫成 localhost:埠號，實際格式以當前環境為準。

狀況三：白畫面（White Screen of Death）

整個畫面一片空白、沒有任何錯誤訊息，常見原因是 PHP 錯誤未顯示，也可能涉及記憶體、檔案權限或伺服器設定。先查看 PHP 與 WordPress 除錯日誌，再依下列步驟縮小範圍：

1. 先查 PHP 與 WordPress 日誌；需要時在本機或 staging 啟用除錯記錄，不能保證只打開 WP_DEBUG 就會在頁面看到所有錯誤。
2. 透過檔案管理員，把 wp-content/plugins 資料夾整個改名（例如改成 plugins_off），這會一次停用所有外掛。如果畫面恢復，代表是某個外掛造成的，再把資料夾改回原名，逐一重新啟用找出兇手。
3. 如果停用外掛後仍失敗，可在備份後測試已安裝且相容的預設主題。不要只改名目前主題就假設一定能正常回退，也不要刪除作用中子主題依賴的父主題。
4. 如果以上都沒用，檢查 PHP 記憶體限制是不是設太低，以及 MAMP 的 PHP 版本是不是跟你的 WordPress 版本與外掛相容。

這套排查邏輯不只適用本機，正式站出問題時也是同一套思路，差別只在於正式站你動作要更謹慎、一定要先做好完整備份再動手。本機能降低影響正式訪客的機會，但匯入的個資、郵件與金流 API 仍可能連到真實服務；測試前應遮罩敏感資料並停用正式通知與交易。

從本機搬上正式主機前的最後檢查

本機測試全部通過，接下來就是把站搬上正式主機。這一步我不在這篇展開細節，因為從本地端搬家到線上主機的完整教學已經把流程拆得很清楚，包含資料庫匯出匯入、網址替換、檔案傳輸的每一個步驟。這裡我要強調的是搬家之前的檢查清單，因為這些項目如果漏了，搬上去再來補會非常痛苦。

• 確認永久連結結構已經固定，不要等上線才改，否則所有內部連結與分享出去的網址都可能失效。
• 確認所有測試用的假資料是否要保留。如果是給客戶的站，測試文章與佔位圖片記得清掉，避免上線後看起來像半成品。
• 確認 WP_DEBUG 已關閉，正式站不應該把 PHP 警告暴露給訪客。
• 上線時檢查 WordPress 搜尋引擎可見性與實際 noindex 輸出；解除限制不保證收錄。本機或 staging 若可從外部存取，還要使用驗證及存取控制，不能只靠 noindex 保護資料。
• 確認正式主機已備好 SSL 憑證。HTTPS 已是基本配備，Google 也明確將其納入排名與瀏覽器信任的考量，搬家前先搞定SSL 憑證與HTTP 升級 HTTPS的設定，才不用上線後再緊急處理混合內容的問題。

趁搬家這個節點，順手把主機層的事一起想清楚，也會省下之後的麻煩。如果你還在比較不同類型主機的差異，主機類型完整比較可以幫你釐清共享、VPS、虛擬主機之間的取捨；日後若需要再換主機商，WordPress 搬家到新主機的流程也與本機到正式主機的邏輯相通。

開始你的第一個本機 WordPress 專案

本機架站真正的威力，不在於它免費、不在於它離線可用，而在於它給了你一個可以犯錯的安全空間。每一個我在正式站上成功避免的災難，背後都是先在本機踩過坑、學會了、才不再犯。把這個習慣建立起來，你對 WordPress 的掌握度會以完全不同的速度成長，因為你不再被「怕弄壞」綁住手腳，敢去碰那些你一直迴避的設定頁面與外掛組合。

還有一個長期下來更值錢的副作用：當你反覆在本機拆解過伺服器、資料庫、PHP 與 WordPress 之間的關係，你對整個網站技術棧的理解會從「按下按鈕等結果」升級成「看得出每個環節在幹什麼」。這份底子，是日後判斷主機方案、排查正式站效能瓶頸、評估外掛品質時最可靠的依據，別人給不了你，只能靠一次次本機實作累積出來。

現在，照著這份行動清單，把你的第一個本機站開起來：

1. 下載並安裝 MAMP（Mac 或 Windows 版），啟動伺服器，確認 Apache 與 MySQL 兩個燈都轉綠。
2. 在 phpMyAdmin 建一個資料庫，命名 wp_local，編碼選 utf8mb4_unicode_ci。
3. 下載 WordPress 繁體中文版，解壓縮後放進 MAMP 的 htdocs 資料夾。
4. 跑完安裝精靈，填入資料庫連線資訊，設定管理員帳號密碼，登入後台。
5. 做四個對齊動作：PHP 版本、記憶體限制、WP_DEBUG、永久連結結構，全部對齊你的正式主機。
6. 挑一個你不敢在正式站上做的實驗，例如裝一個一直想試的外掛、換一套主題、或重排一次選單，在本機放手去做。

完成這些步驟後，你就有一個可備份、可重建的本機測試環境。每次實驗前確認資料副本與連外服務設定，記錄改動，再把通過驗證的內容帶到 staging 與正式上線流程。