「客製一律先開子主題」這句話，在台灣站長圈流傳了快十年。早期確實如此，畢竟一改父主題的 functions.php 或樣式檔，下次主題更新就被覆蓋，整晚的工就白做。但這個習慣的時空背景是經典主題（Classic Theme）當道的年代，所有版型靠 PHP 模板組裝，樣式靠 style.css 撐起來。

到了 2026 年，多數新主題已經是區塊主題（Block Theme），核心介面交給 theme.json、HTML 模板與全站編輯器（Full Site Editing，FSE）共同接管。改顏色、字級、間距、版型結構，使用者在後台點一點，資料寫進資料庫，跟主題檔案完全脫鉤，更新時動不到。WordPress 子主題在這個架構下的角色，已經從「萬用安全網」縮成「特定場景才需要的工具」。

這篇不討論怎麼建子主題，網路上現成教學夠多。要釐清的是反方向的問題，什麼時候開子主題其實是多此一舉，什麼時候直接動父主題或全域樣式才是合理選擇，又有哪些情況到了今天依然非開不可。

子主題的本來目的，在區塊主題時代被稀釋了多少

子主題誕生的核心理由只有一個，保護客製不被父主題更新覆蓋。它的機制是讓 WordPress 載入父主題作為底，再用子主題覆寫指定檔案。主題更新時只動父主題目錄，子主題目錄安然無恙。

這個邏輯在經典主題年代成立，是因為所有客製都必須寫進主題檔案，例如 CSS 改在 style.css、版型改在 page.php、自訂功能寫進 functions.php。沒有子主題就沒有安全區，這是事實。

區塊主題把這套邏輯打破了一半。Kinsta 的技術文件指出，使用者透過站台編輯器（Site Editor）改的所有顏色、字體、版型、區塊樣式，資料都存進 wp_options 表的 wp_global_styles 系列紀錄，而不是寫回主題檔案。換句話說，這類客製從一開始就不在主題更新的射程內，子主題能保護的東西，原本就沒被威脅。

剩下還需要靠檔案層級覆寫的範圍，主要落在 theme.json 結構性調整、HTML 模板的版型重組、PHP 鉤子（Hook）邏輯、JavaScript 互動腳本。這四類確實還是子主題的守備範圍，但占整體客製需求的比例，已經跟十年前完全不同。

哪些情況改父主題反而更安全

下面這幾種需求，繞過子主題直接走站台編輯器或全域樣式，反而更穩。客製會寫進資料庫，不會因為下次主題更新而消失，也不會在父主題迭代時跟新版檔案打架。

• 顏色、字型、間距的全域調整：在站台編輯器的全域樣式（Global Styles）面板直接改，所有套用該設計代幣（Design Token）的區塊一次連動。子主題寫 CSS 覆蓋反而要追兩套來源
• 單一頁面或模板的版型微調：用區塊編輯器調整對應模板，存檔後同樣寫進資料庫的模板紀錄，父主題模板更新時兩邊獨立存在
• 特定區塊的樣式覆寫：透過區塊樣式變化（Block Style Variations）功能新增變體，資料存進資料庫，不必為了改一顆按鈕外觀去開整個子主題
• 頁首頁尾的局部更動：在站台編輯器直接編輯模板組件（Template Part），改完的版本以資料庫紀錄為準，父主題後續更新仍會帶來原始版本，但不會蓋掉你的版本
• 多套設計風格切換：直接挑父主題附的樣式變化（Style Variation），一鍵切換配色與字體組合，不必為每組風格各自建一份子主題

這幾類動作的共通點是，客製結果都落在資料庫而非檔案。主題更新動的是檔案，兩邊不相交。硬要套子主題反而會讓樣式來源變成「父主題 theme.json、子主題 theme.json、資料庫紀錄」三層疊加，未來除錯時要回頭追哪一層覆蓋哪一層，麻煩遠大於收穫。

全域樣式、樣式變化與 theme.json 各自能承載什麼

要判斷某項客製該走哪條路，先得釐清這三個入口的能力邊界。它們的設計目的不同，能承載的客製深度也不同。

往下走的判斷順序很單純，視覺層改動先試全域樣式，整套風格切換看父主題的樣式變化是否夠用，到了結構或邏輯層級才開子主題。把這個順序倒過來走，等於用大砲打蚊子。

實務上比較常見的誤判，是把單純的顏色改動寫成子主題裡的 CSS 覆蓋。這種做法在區塊主題環境下會產生兩個問題，一邊是全域樣式面板顯示的色票跟實際渲染不一致，另一邊是主題若升級了顏色變數命名規則，子主題的 CSS 又會失效，等於主動製造維護債。

真正非開子主題不可的四種場景

談完了不必開的情況，反過來看哪些場景非開不可。判斷準則一致，客製是否落在主題檔案本身，而且該檔案會被父主題更新覆蓋。

結構性修改 theme.json

要新增調色盤、改字型尺度（Type Scale）、調整全域間距變數、定義新的區塊預設值，這些動作改的是設計代幣本身。雖然部分可以透過自訂樣式變化承載，但若客製涵蓋多個結構面，或要跟程式邏輯搭配，把 theme.json 放進子主題覆寫父主題版本，是最穩的做法。

關鍵判準是，這份 theme.json 設定要不要長期跟著站台走、需不需要版本控制（Version Control）。要的話開子主題，臨時試色就停在全域樣式。

修改 HTML 模板的版型結構

區塊主題的模板是 .html 檔，存在主題 /templates/ 或 /parts/ 目錄。透過站台編輯器改模板，新版本存進資料庫沒問題，但若需求是徹底替換掉父主題附的某個模板，例如重寫單篇文章版型或商品頁結構，讓子主題提供同名 .html 檔覆蓋，整個站台後續就以子主題版本為準，不再依賴資料庫紀錄。

對需要把客製打包帶走、部署到其他站台的情況，子主題版本控制比資料庫匯出可控得多。

加掛 PHP 鉤子或自訂功能

functions.php 是子主題的傳統強項。要註冊自訂文章類型（Custom Post Type）、掛 action／filter 鉤子改變 WordPress 行為、串接外部 API、自訂短碼（Shortcode），這些 PHP 邏輯沒辦法透過站台編輯器處理。寫進父主題會被更新覆蓋，獨立外掛是另一條路但耦合度比較高，子主題仍是首選。

例外是規模較大或會跨主題共用的功能，建議獨立成外掛，跟主題解耦。

載入自訂 JavaScript 與資產

要加追蹤腳本、互動元件、第三方 SDK，路徑跟 PHP 一樣。透過子主題的 functions.php 用 wp_enqueue_script 註冊，檔案放子主題目錄，整套客製有版本、可追蹤，也不會被父主題更新覆蓋。

這四種場景的共通點是客製本質就在檔案層，跟資料庫無關。只要符合這個條件，子主題依然是 2026 年最直接的解答。

客製前的判斷順序

回到開頭的問題，子主題到底該不該開。答案不是二選一，而是判斷順序的問題。

先問客製的本質是視覺層還是結構層。改顏色、字體、間距、單頁版型屬於視覺層，先走全域樣式或樣式變化，資料留在資料庫，主題更新動不到。改 theme.json 結構、HTML 模板、PHP 邏輯、JavaScript 屬於結構層，才考慮子主題。

接著問客製要不要長期維護、要不要跨站台搬移。臨時調整的視覺差異留在資料庫足夠，要納入版本控制、要在多個環境部署的客製，檔案層級的子主題比資料庫匯出可靠。

最後問父主題本身的設計品質。設計周到的區塊主題，theme.json 結構完整、樣式變化覆蓋多種風格、模板組件切分合理，這時候子主題的必要性會再降一層；設計粗糙的父主題，連最基本的全域樣式都調不開，那也許該換主題而不是開子主題硬補。

「客製一律先開子主題」的時代過去了。WordPress 子主題在 2026 年仍有它的位置，但只在它真正能解決問題的場景上發揮，不該繼續被當成所有客製需求的預設答案。