文檔站、行銷落地頁與手寫 HTML 往往把第三方皮膚、設計符記、活動頁補丁堆進同一份樣式表，最終只能靠 !important 或更高特異性「硬壓」。CSS 層疊層（@layer）在作者來源內引入明確優先順序，它在特異性之前就決定哪一組宣告獲勝，從而讓工具類不必再武裝到牙齒。本文面向交付 MPA 或靜態產生 CSS、又沒有執行時打包器的團隊，並強調必須在真實 Safari／WebKit 上簽核。排期時請結合 靜態元件的容器查詢 與 Safari Technology Preview 對比穩定版 一起安排質檢。
層疊層不會減少瀏覽器解析的宣告條數，但能顯著減少「誰覆蓋誰」的心智負擔；漸進增強仍要保留——不支援 @layer 的環境應仍能閱讀核心內容。
心智模型：層在特異性之前
級聯對宣告的排序是固定的：先來源與重要性，再層順序，然後特異性，最後來源順序。把規則寫進 @layer utilities { … } 後，該區塊中所有宣告作為一個整體參與比較。於是 utilities 裡單類選擇器也能壓過 reset 裡長鏈選擇器，因為層比較更早發生。靜態站若把 Tailwind 或自研原子類正確放進 utilities，就可以刪掉大量防禦性 !important——前提是不要把半套框架留在未分層區域。
/* 入口 CSS 頂端只宣告一次順序 */
@layer reset, vendor, components, utilities;
@import "normalize.css" layer(reset);
@import "legacy-cms.css" layer(vendor);
@layer components {
.card { border-radius: 12px; }
}Eleventy、Hugo、Astro 靜態輸出應保證每個最終 CSS 只有一份「層清單」。多處重複 @layer 宣告無害，但若局部片段各自列出衝突的順序表，半年後無人能懂。把層清單當契約：重新命名或調整順序時寫變更日誌。
層順序決策表
評審時若有人問「這個 SaaS 小元件放哪？」答案很少應該是「未分層，因為很小」。
| 來源 | 推薦層 | 理由 |
|---|---|---|
| Normalize／現代重設 | reset | 一般優先順序最低，不應壓過元件。 |
| 供應商 UI、舊 CMS | vendor | 隔離歷史債務，可按供應商版本整體替換。 |
| 產品元件（卡片、導覽） | components | 穩定類名的自有模式。 |
| 間距、色票、活動實驗 | utilities | 可預期的覆蓋層。 |
| 線上緊急熱修 | 未分層（暫時） | 會贏過分層規則；必須開工單遷到 utilities。 |
省略 vendor 層時，市場部門嵌入的迷你 CSS 往往把特異性戰爭帶回主站。給這類檔案單獨一層，並在清單裡排在 utilities 之前，設計同事才能用原子類改邊框色而不用碰內嵌指令碼。
未分層與分層作者 CSS
未分層的作者規則在一般重要性下排在所有分層規則之後，是強力但危險的逃生艙：本機 Chrome 看起來一切正常，問題只在 Firefox／Safari 的匯入順序邊緣情況裡冒頭。靜態站應盡量單一入口打包，正式環境避免深度執行時 @import，否則 FOUC 與層順序會隨網路抖動變化。
遷移策略：新樣式先進層，遺留整體暫留未分層；基線測試通過後再分批搬進 vendor 或 components。監控體積——層本身幾乎不增位元組，刪掉的重複選擇器才會減負。對預覽環境跑 Lighthouse：LCP 未必變，但 CLS 可能因衝突的 margin 消失而改善。
!important 陷阱
!important 不會繞過層。在作者來源內，important 比較會反轉層順序：較早宣告層裡的 important 反而壓過較晚層的 important。舊 CMS 裡習慣用 important 當槌子的人，分層後會發現「關鍵熱修」突然輸給 reset 裡的 important。正確做法是拿掉 important 或把規則移到合適層，而不是在 utilities 再疊一層 important。
使用者代理與使用者樣式仍遵循各自來源規則；不要為了「蓋過」無障礙樣式去鑽層空子。結合 容器查詢 做元件縮放時，要確保焦點環在查詢容器收縮後仍滿足對比度。
重設、元件、工具類
- reset：盒模型、排版預設值、元素歸一；不要寫品牌色，保持結構級。
- vendor：無法逐行稽核的第三方 CSS；檔名帶版本號便於 diff。
- components：BEM 區塊、Web 元件的無 Shadow 後援、跨語言共用的靜態 partial。
- utilities：原子類與活動覆蓋；限制每條工具宣告的屬性數量，避免變 INLINE 災難。
在 README 寫明層清單，外包同事才知道新英雄區該放哪。靜態站失敗常見原因不是缺功能，而是兩種 card 實作同頁互撞——分層讓勝者可預測。
效能上瀏覽器仍要比對每條選擇器；層只最佳化級聯階段。配合淺層 DOM 與謹慎 defer 非關鍵 CSS。安全方面層不消毒 HTML，逸出仍在伺服器端。
瀏覽器矩陣
| 引擎 | @layer | 靜態質檢提示 |
|---|---|---|
| Chromium 99+ | 穩定 | 開發者工具展示層樹，適合 CI 截圖基線。 |
| Safari 15.4+ | 穩定 | 小版本需迴歸；WebKit 修正常先出現在 STP。 |
| Firefox 97+ | 穩定 | 匯入重排層時警告清晰。 |
| 舊 WebKit（如 iOS 14） | 無 | 把層當作增強，核心排版不得依賴層。 |
企業靜態站遙測裡仍有約 6–9% 瀏覽器無層支援，每季驗證後援。
雲端 Mac 上的 Safari 流程
Linux CI 無法認證次像素反鋸齒與 WebKit 字型後援。每週留 30–45 分鐘 真機：穩定 Safari 做合約級簽核，Safari Technology Preview 查 WebKit 新修復。Web Inspector 級聯面板展開截圖，方便設計看清哪一層獲勝。
採購卡硬體時可租 Apple Silicon Mac mini：SSH 部署、VNC 看 Safari，風險操作前做快照。短租日均約 16.9 美元，比國際郵寄樣機便宜。預覽環境鏡像正式 Content-Security-Policy，讓分層 @import 失敗提前暴露。
國際化：RTL 與邏輯屬性混用時，層衝突表現為輕微 padding 翻轉而非硬錯誤，阿語希伯來範本要在穩定 Safari 與 STP 雙測。列印樣式應去掉假設深色背景的工具類，用 @media screen 包裹彩色符記。
流程上每個 PR 附兩分鐘 Safari 與 Chromium 雙錄影；發行說明記錄 Safari 建置號與層清單版本，方便對照工單。無障礙評審在層重構後要重跑 VoiceOver：outline 可能從 components 挪到 utilities，動畫長度也會變。
市場常喊「再多一版」英雄區；層能防止實驗汙染核心元件，但未分層熱修仍要有工單號，便於程式碼搜尋追責。分析團隊若追蹤樣式實驗，請在層遷移前後分段取樣，避免把效能波動誤讀為行銷效果。
最後，靜態 CDN 上的快取策略要與層清單版本連動：檔名雜湊變更時清邊緣節點，否則使用者會短時間看到半新半舊的層順序。維運可把層清單版本寫進健康檢查回應標頭，快速判斷灰階是否一致。
常見問題
層疊層會取代特異性嗎？
不會。層是更靠前的排序鍵；同一層內仍比較特異性，繼承規則不變。
!important 與 @layer 如何互動？
作者來源內 important 依層順序反轉比較；優先刪除 important 而不是繼續堆疊。
可以把分層 CSS 與未分層遺留檔案混用嗎？
可以，但未分層一般宣告會壓過分層宣告——謹慎使用並計畫遷移。
Mac mini 仍是 WebKit 質檢的安靜基準：色彩準、輸入法原生、長時間跑 Safari 發熱可控。MacHTML 提供裸金屬 Apple Silicon 租用與 SSH／VNC，靜態團隊可在衝刺期租機取證，通過後即釋放資源。