一個有經驗的前端工程師評估一個新專案，通常做兩件事：打開 package.json 看一下依賴，再打開 styles/ 目錄聞一下味道。後者比前者更能預測這個專案六個月後會變成什麼樣子。
CSS 架構是那種「立竿見影」不明顯，但「後果爆發」很嚴重的事情。一開始隨便寫寫感覺沒什麼，等到 Design System 有三十個元件、二十個頁面、七個開發者同時在上面動工時，CSS 的技術債才開始以失控的速度累積。
為什麼 CSS 架構問題在 2026 年變得更尖銳
過去兩年，CSS 的能力邊界經歷了幾次重大擴展：Cascade Layers、Container Queries、:has() 選擇器——這三個功能加在一起，讓很多過去必須靠 JavaScript 或後端處理的響應式邏輯，現在純 CSS 就能做到。
但能力的擴展也帶來了複雜性的上升。當你可以用 @layer 控制優先順序、用 @container 讓元件自己響應父容器、用 :has() 查詢子元素狀態時，你的 CSS 架構決策空間變得比以往任何時候都大——相應地，決策錯誤的代價也變得更高。
舉例來說：如果你的設計系統一開始沒有规划好 @layer 的結構，後來加入任何第三方 UI 框架時，你就會發現你的樣式被別人的 !important 吃得死死的，而且根本沒有乾淨的方式解套。
Cascade Layers：設計系統的「分區自治」
Cascade Layers（@layer）是 CSS 2022 年就推出的功能，但一直到 2025 年才開始被多數台灣前端團隊實際採用。原因很簡單：在那之前，用 !important 或特定的 class 命名規範（像是 BEM）也能解決大部分優先順序問題。
但 !important 不是辦法，BEM 也有極限。當你的設計系統要同時容納「基礎樣式」、「元件庫」、「主題層」、「頁面特定樣式」這四個不同優先順序的群組時，@layer 提供的是語法層級的解決方案，而不是約定層面的。
實際的做法大概是這樣：
@layer base, components, patterns, utilities, overrides;
@layer base {
*, *::before, *::after { box-sizing: border-box; }
body { margin: 0; font-family: system-ui, sans-serif; }
}
@layer components {
.btn { padding: 0.75rem 1.5rem; border-radius: 6px; }
.card { background: white; border-radius: 12px; box-shadow: 0 2px 8px rgba(0,0,0,0.08); }
}
@layer patterns {
.product-grid { display: grid; gap: 1.5rem; }
}
@layer utilities {
.sr-only { position: absolute; width: 1px; height: 1px; overflow: hidden; }
}
@layer overrides {
/* 第三方外掛或特殊頁面的覆蓋，放在最後 */
}
這樣的結構下，任何第三方程式庫只要寫進 overrides layer，就不會干擾你的 components 和 patterns。而當你需要強制覆蓋任何東西時，你可以用 @layer overrides 裡的 !important——因為你知道這個覆蓋是有範圍的。
Container Queries 正在改變「響應式元件」的定義
在 Container Queries 出現之前，「響應式設計」的邊界是視窗（viewport）。你要嘛讓整個頁面的佈局響應視窗寬度，要嘛用 JavaScript 動態計算父容器寬度再手動切換 class。
Container Queries 把響應式設計的邊界，從「視窗」擴展到了「任意父容器」。這件事看起來是 CSS 語法的改進，實際上是元件化開發的一個重大突破。
過去同一張卡片元件，要同時在側邊欄（全寬）、主內容區（雙欄）、首頁 Hero 區（三欄）呈現，你需要對每一個使用情境寫不同的 HTML class 或包不同的 wrapper。現在只需要這樣：
.card-wrapper {
container-type: inline-size;
container-name: card;
}
.card {
display: flex;
flex-direction: column;
}
@container card (min-width: 480px) {
.card { flex-direction: row; }
.card-image { width: 40%; }
}
@container card (min-width: 720px) {
.card { display: grid; grid-template-columns: 1fr 2fr; }
}
同一個 HTML 元件，在任何父容器下都自動響應——不需要 JavaScript，不需要多個 class，只需要 CSS 的父容器查詢能力。
設計 Token：用 Custom Properties 把設計決策集中化
一個網站的設計系統，如果所有的間距、顏色、圓角、陰影都直接寫死在元件 CSS 裡，每次調整品牌視覺都是一場噩夢。你需要全域搜尋 replace，而且很容易漏掉某些極端情況。
CSS Custom Properties（又稱 CSS Variables）提供了解決這個問題的標準機制。很多設計系統（如 IBM Carbon、Shopify Polaris）都已經用 Custom Properties 做設計 token，但多數中小型專案還是把具體數值直接寫進樣式裡。
一個基本的設計 token 系統大概長這樣：
:root {
--space-1: 0.25rem; --space-2: 0.5rem; --space-3: 1rem;
--space-4: 1.5rem; --space-5: 2rem; --space-6: 3rem;
--color-brand-50: #eff6ff; --color-brand-500: #3b82f6;
--color-brand-900: #1e3a8a;
--color-neutral-100: #f5f5f5; --color-neutral-900: #171717;
--shadow-sm: 0 1px 2px rgba(0,0,0,0.05);
--shadow-md: 0 4px 6px -1px rgba(0,0,0,0.1);
--shadow-lg: 0 10px 15px -3px rgba(0,0,0,0.1);
--radius-sm: 4px; --radius-md: 8px;
--radius-lg: 12px; --radius-full: 9999px;
}
設計 token 的核心價值不在於「現在」讓你少寫幾個數字，而在於「未來」讓你能以最小成本調整整站的視覺系統。如果你知道 --color-brand-500 控制了網站裡所有主要按鈕的背景色、Logo 的主色、Selected 狀態的高亮，那麼「品牌主色從藍色換成綠色」這件事，影響範圍是清楚可控的。
架構選擇的實際代價：當你選了錯誤的路
我曾經看過一個電子商務網站，用 Sass @extend 語法建立了大量元件變體。剛開始看起來很整潔，但當他們需要支援「白色星期五」促銷主題時，發現沒有乾淨的方式注入另一套色彩系統。最後的解法是在每個相關 class 裡加 !important，然後再用另一層 CSS 覆蓋回來——代價是樣式表從 3,000 行膨脹到 12,000 行，三個工程師同時修改開始出現 conflict。
另一個例子是一個 SaaS 後台系統，從第一天就採用 CSS Custom Properties 做設計 token，加上 @layer 控制層級。兩年內設計系統從 20 個元件擴展到 80 個，中間經歷了三次品牌重塑，每次調整的技術債都接近零——因為所有色彩、間距、圓角都集中在一個 token 檔案裡。
這兩個故事說的是同一件事：CSS 架構的代價不是「當下」的，是「六個月後」的。現在選對路，未來節省的是整個團隊的時間。
從今天開始的具體行動
如果你的專案現在沒有任何 CSS 架構可言，從今天開始不需要急著重寫。選一個最實際的切入點：
第一步：建立設計 token。把網站目前使用的顏色、間距、字體大小全部抽出來，寫成一組 CSS Custom Properties。這個工作不需要動到任何現有樣式，只是用變數把現有值包起來，但這是所有後續改進的基礎。
第二步：選定一個簡單元件（例如按鈕或輸入框），把其中的魔法數字（像是 padding: 13px、margin-bottom: 47px）換成你的 token 變數。體會一下改了一個 --space-3 的值，該元件自動跟著調整的感覺。
第三步：引進一個 @layer 結構。把你的 styles 分成 base、components、utilities 三層，用 @layer 宣告優先順序。之後加入任何新樣式時，都放在 components 或 utilities 層。
這三步不需要任何新工具，不需要學任何新框架——瀏覽器 DevTools 就是你現成的 CSS 架構視覺化工具。Cascade Layers、Container Queries、Custom Properties——這些語法在 2026 年已經是所有主流瀏覽器的基本配備。
