變數還活著，編譯器先走了：Sass 的招牌絕活，被原生 CSS 一項項搬走

先把日期補上。2026 年 9 月 21 日，掘金出現一篇標題相當嗆的文章：「Sass 和 Less 在 2026 年徹底多餘了嗎？」作者 ErpanOmer 把 Sass 與原生 CSS 的演進並排放在一起比對，結論偏向殘酷：當年讓 Sass 封神的那串能力，如今原生 CSS 幾乎都用更順手的方式做到了。這種「某個老工具是不是該退休了」的討論，在前端圈從來不缺流量，因為每個人的專案裡都還躺著幾千行 .scss 檔案，誰也說不準明天要不要動它。

2012 年的那場救援

文章從 2012 年說起。那個年代的原生 CSS 沒有變數、沒有嵌套、沒有顏色函數，也沒有模組化。想換一套主題色，你得在幾十個檔案裡硬編同一個色碼，改品牌色的流程是全域搜尋替換，然後祈禱沒有哪個角落被漏掉。Sass 和 Less 的出現，等於給石器時代的工具裝上電動馬達。變數、嵌套、Mixin、顏色計算、迴圈，這些東西讓 CSS 第一次有了工程化的樣子。

這段歷史前端圈的人都記得，所以文章一出，留言區很快分成兩派。一派點頭如搗蒜，說自己的新專案早就純原生 CSS 了；另一派則提醒，老專案的遷移成本、團隊慣性與瀏覽器支援的長尾問題，都不是一句「多餘了」就能解決的。

變數：一個已死，一個活著

作者挑的第一個對照點是變數，也是他認為最早被超越的能力。Sass 變數的本質是編譯時替換：$primary 在編譯那一刻就被換成具體色碼，輸出的 CSS 裡變數本身已經不存在了。換句話說，它在瀏覽器端是死的。

CSS Custom Properties 則是執行時的活物。它存在於瀏覽器的 CSSOM 裡，可以被 JavaScript 動態修改、被繼承、被覆蓋，也能跟著 data-theme 屬性切換。想不刷新頁面就換整套主題色，一行 JS 呼叫 setProperty 就搞定。這是 Sass 那套編譯期機制在原理上永遠做不到的事，因為東西在編譯完就已經定型了。

嵌套：最後一道心理防線

嵌套被作者形容為 Sass 留住用戶的最後一道心理防線。這道防線在 2023 年底正式失守，Chrome、Firefox、Safari 全數支援了原生 CSS Nesting。

書寫體驗上，兩者已經幾乎一致。原生嵌套同樣能寫子選擇器、同樣支援 & 符號引用父選擇器，@media 也可以直接寫進規則塊裡。而原生方案有一個編譯型工具先天給不了的優勢：不需要編譯。你在 DevTools 裡看到的就是你寫的結構，除錯時不必在腦中做一次編譯還原。對每天跟樣式 bug 搏鬥的人來說，這點比任何語法糖都實際。

顏色函數與那剩下的尾巴

顏色計算是文章著墨的另一塊。darken()、lighten()、mix() 這些函數曾經是做主題色階梯的唯一方案，改一個主色、自動派生出一整套 hover 與 active 狀態。如今原生 CSS 的顏色函數逐步補齊，這塊招牌也岌岌可危。

不過文章標題用的是問句，作者自己也沒把話說死。Sass 生態裡還有些東西短期內沒有完全對等的原生替代，例如成熟的模組化方案、Mixin 的複用模式，以及大量存在於設計系統與元件庫裡的既有序程式碼。這也呼應了前端圈這幾年的整體氣氛：工具鏈一直在換心，像 npm 生態那場 Rust 換心手術一樣，底層靜靜地換，使用者多半是後知後覺。樣式這邊的變化只是同一齣戲的另一幕。

多餘與退役之間，隔著一個存量世界

把幾件事並排看，味道就出來了。技術上，Sass 的核心賣點確實被原生 CSS 一項項搬走，從變數、嵌套到顏色計算，每一項都有更輕、更直觀的原生做法。但現實中，「新專案不再需要」和「舊專案可以拔掉」是兩回事。一個跑了八年的電商前臺，裡面的 mixin 和嵌套盤根錯節， rewrite 的風險遠大於收益，留著編譯器反而理性。

所以 2026 年的答案大概是：Sass 和 Less 在新專案的必要性格確實趨近於零，但「徹底多餘」這四個字，要等最後一批存量專案自然退場才成立。工具的死亡很少是槍斃式的，多半是這種慢性告別。這也是為什麼這類文章每隔幾年就會再被拿出來討論一次，每次討論，贊成「可以退場」的聲音都比上一次更大一點，而反對的聲音裡，越來越多是「同意，但還不行」。

對還在寫樣式的人來說，與其糾結要不要立刻搬家，不如把新起的元件直接用原生寫法試一遍。變數、嵌套、顏色函數都摸過一輪之後，你自然會知道自己的專案還缺什麼，而那個缺口，往往比想像中小得多。