CSS Mixins 原生混入教學取代 Sass 2026 完整指南

前言：等了這麼多年，原生 CSS Mixins 終於要來了

說實話，我第一次聽到「CSS 原生 Mixin」這個消息的時候，反應跟大部分前端開發者一樣——「真的假的？」。用了 Sass 快十年，mixin 幾乎是我每個專案的標配，從 RWD breakpoint 到 flexbox 佈局全靠它。但 2026 年的今天，CSS 規格的演進速度讓人驚艷，原生 mixins 已經在 CSS Functions and Mixins Module Level 1 草案裡，而且部分瀏覽器已經開始實驗性支援。

這篇文章我想從實務角度切入，聊聊原生 CSS Mixins 的語法、跟 Sass mixin 的差異、目前的瀏覽器支援狀況，以及你現在到底要不要開始轉移。如果你已經看過我之前寫的 CSS @layer 層疊圖層教學，應該對 CSS 規格近年來的大躍進有一定感受了。

什麼是 CSS Mixins？跟 Sass mixin 有什麼不同？

Sass 的 mixin 大家都熟，就是一段可以重複使用的 CSS 宣告群組，可以接受參數、做邏輯判斷，產出最終的 CSS 規則。原生 CSS Mixins 的核心概念一樣，但語法完全不同，而且是在瀏覽器端直接執行，不需要任何前處理器編譯步驟。

最關鍵的差異在於：Sass mixin 是靜態的，在編譯期就決定好了；原生 CSS Mixins 是動態的，可以跟 CSS 自訂屬性（Custom Properties）配合，在 runtime 根據繼承鏈的值改變行為。這個特性讓原生 mixins 在某些場景下比 Sass 更強大。

另一個重要背景是，CSS @property 自訂屬性的推出讓 CSS 自訂屬性有了型別系統，這為 mixins 接收參數奠定了基礎——你可以把有型別的 custom property 當作 mixin 的「參數」來使用。

CSS Mixins 語法詳解

基本語法：@mixin 宣告與 @apply 套用

根據目前的草案規格，CSS Mixins 使用 @mixin 定義，用 @apply 套用（注意：這個 @apply 跟幾年前那個廢棄的提案不一樣，是全新設計的）：

/* 定義一個 mixin */
@mixin --flex-center {
  display: flex;
  align-items: center;
  justify-content: center;
}

/* 套用 mixin */
.card {
  @apply --flex-center;
  padding: 1rem;
}

注意 mixin 名稱前面有兩個破折號 --，這跟 CSS 自訂屬性的命名規則一致，刻意設計成這樣是為了避免跟未來的 CSS 關鍵字衝突，也讓開發者看到名稱就知道這是自定義的東西。

帶參數的 Mixin

這裡是最有趣的部分。原生 CSS Mixins 透過 CSS 自訂屬性傳遞參數：

/* 帶參數的 mixin */
@mixin --button-variant {
  background-color: var(--btn-bg, #3b82f6);
  color: var(--btn-color, white);
  border-radius: var(--btn-radius, 0.375rem);
  padding: var(--btn-py, 0.5rem) var(--btn-px, 1rem);
  border: none;
  cursor: pointer;
  transition: opacity 0.2s;

  &:hover {
    opacity: 0.85;
  }
}

/* 使用時覆寫參數 */
.btn-primary {
  --btn-bg: #3b82f6;
  --btn-color: white;
  @apply --button-variant;
}

.btn-danger {
  --btn-bg: #ef4444;
  --btn-color: white;
  @apply --button-variant;
}

.btn-outline {
  --btn-bg: transparent;
  --btn-color: #3b82f6;
  --btn-radius: 9999px;
  @apply --button-variant;
  border: 2px solid #3b82f6 !important;
}

這個模式你看了會不會很眼熟？其實跟 Tailwind CSS v4 升級裡用 CSS 變數取代設定檔的思路異曲同工——把設定值放進 custom properties，讓繼承機制幫你做「參數傳遞」。

RWD Breakpoint Mixin 實戰

這是我最期待的應用場景之一。過去在 Sass 我會這樣寫：

/* Sass 寫法（舊） */
@mixin respond-to($breakpoint) {
  @if $breakpoint == 'md' {
    @media (min-width: 768px) { @content; }
  } @else if $breakpoint == 'lg' {
    @media (min-width: 1024px) { @content; }
  }
}

.hero {
  font-size: 1.5rem;

  @include respond-to('md') {
    font-size: 2rem;
  }
}

原生 CSS 目前還沒辦法在 mixin 內部包含 media query 的 @content 注入（草案仍在討論），但搭配 CSS 自訂屬性和 container queries，可以實現類似效果：

/* 原生 CSS 替代方案 */
@mixin --fluid-type {
  font-size: clamp(
    var(--type-min, 1rem),
    var(--type-fluid, 2.5vw + 0.5rem),
    var(--type-max, 1.5rem)
  );
  line-height: var(--type-leading, 1.5);
}

.heading-lg {
  --type-min: 1.75rem;
  --type-max: 3rem;
  --type-fluid: 3vw + 1rem;
  @apply --fluid-type;
}

.body-text {
  --type-min: 1rem;
  --type-max: 1.125rem;
  @apply --fluid-type;
}

瀏覽器支援現況（2026 年 Q1）

講到這裡你大概最想知道的就是：現在能不能用？坦白說，生產環境還要再等等。

截至 2026 年初，CSS Mixins 的狀態大致如下：

Chrome / Edge：實驗性旗標支援，需開啟 chrome://flags/#enable-experimental-web-platform-features
Firefox：Nightly 版本有部分支援，正式版尚未跟進
Safari：Technology Preview 開始測試，進度較保守

所以現在的最佳策略是：學習語法、做好心理準備，但專案裡繼續用 Sass 或 PostCSS。不過這話說完我要補充一點——如果你的專案已經大量使用 CSS Custom Properties，現在開始把 mixin 邏輯改寫成「透過 custom property 參數化」的模式，日後遷移會輕鬆很多。

這也呼應了我在規劃 Tailwind CSS 響應式設計實戰時的觀察：CSS 的未來是越來越「動態化」，而不是靠預處理器靜態編譯。理解這個方向，你的技術決策會更有前瞻性。

與 Sass Mixin 的功能對比

原生 CSS Mixins 勝出的地方

無需編譯步驟：直接在瀏覽器執行，減少建置複雜度
動態響應繼承：配合 custom property 的繼承特性，父元素改值、子元素套用的 mixin 自動更新
DevTools 可見：不像 Sass 編譯後難以追蹤來源，原生 mixin 在 devtools 裡清晰可見
配合 @layer 管理優先級：跟 CSS Anchor Positioning 等新特性無縫整合

Sass Mixin 目前仍有優勢的地方

@content 注入：Sass 可以在 mixin 內部注入任意 CSS 區塊，原生版本草案尚未完整支援
條件邏輯：@if / @else 的邏輯判斷能力，原生 CSS 還無法完全複製
迴圈生成：@for / @each 批次產生 class，原生 CSS 沒有對應機制
全瀏覽器支援：Sass 編譯後的 CSS 哪裡都能跑，原生 mixins 還在等普及

我的建議：現在該怎麼做？

我不建議你現在就把 Sass 從專案裡砍掉，但我會建議你開始改變寫 mixin 的思維方式。具體來說：

把 mixin 的「參數」改用 CSS Custom Properties 表達，而不是 Sass 的 $variable
避免過度依賴 @content 注入的 mixin，改用 @layer 管理層疊順序
善用 clamp()、min()、max() 等 CSS 數學函式取代部分 Sass 邏輯
關注 CSS Masonry 瀑布流原生佈局等新特性的普及狀況，它們代表 CSS 規格前進的速度

說真的，CSS 這幾年的進化速度快到有點嚇人。從 CSS Grid、Custom Properties、到 @layer、@container，再到現在的 @mixin，每一個特性出來都讓我對「要不要繼續維護這套 Sass 架構」多一分猶豫。我的判斷是：2026 年底到 2027 年，如果瀏覽器支援度達到 85% 以上，就是認真規劃遷移的時機。

總結

CSS Mixins 原生混入是 CSS 走向完整性的重要一步，語法設計上融合了 custom properties 的命名慣例，讓整體 CSS 生態系更加一致。雖然現在還不是全面取代 Sass mixin 的時機，但理解它的設計哲學、提前調整程式碼風格，絕對讓你在日後的遷移過程中省下大量時間。前端的世界就是這樣，技術永遠在跑，跑得快的人不一定追得上，但方向看對了，步伐就不會白費。