3 種操作 · 3 種不同承諾
先決定工具可以改動到哪一層。
格式化、語法檢查與壓縮都從可解析的樣式表開始，接著走向不同結果。共用前處理只針對 declaration boundary 的舊式 ; !important 次序，並不是通用自動修復；選好需要的結果後，仍要判斷輸出是否適合專案。
格式化
Prettier parser → 可讀 CSS依縮排與列寬重新排版
語法檢查
Parser → 語法訊號回報解析結果與現代語法計數，不是 lint
壓縮
保守清理 / CSSO收緊空白，或進一步清理、縮寫及重整結構
現代 CSS 壓力樣本
拿今天的 CSS 語法來檢驗 formatter。
這些片段涵蓋 cascade layer、原生巢狀、自訂屬性、feature query、數學運算與感知色彩，不只測試傳統的屬性宣告。
@layer
@layer components { … }格式化時保留原始 layer 順序
原生巢狀
.card { &:hover { … } }父選擇器仍連接原本的巢狀規則
設計 token
:root { --space: 1rem; }保留自訂屬性名稱
@supports
@supports (color: oklch(0 0 0))條件規則維持原本的巢狀位置
數學運算
width: calc(100% - var(--space))重新排出容易閱讀的運算間距
現代色彩
color: oklch(72% .18 145)交由 parser 識別色彩函式 token
位元組預算流程
檔案變小是一條處理路徑，不等於排版變漂亮。
格式化可能增加檔案大小。預設 conservative 會移除一般註解並收緊空白，不合併規則；主動選擇 maximum 才會交由 CSSO 清理、縮寫，並以 restructuring 合併宣告或規則。
輸入
基準
保留原始空白、註解與換行
格式化
可能變大
為閱讀重新排版，位元組增加並不意外
保守壓縮
通常較小
保留 /*! 註解、收緊空白，不重整規則
Maximum
需主動選擇
CSSO 會清理、縮寫，並可能合併宣告或規則
Parser 定位線索
先看 parser 報出的第一個斷點。
未閉合的區塊可能改變後續 token 的解析方式。Prettier parser 拒絕輸入時，先從它回報的位置修正；瀏覽器本身的 CSS 錯誤復原規則不一定相同。
.card {
color: var(--ink);
&:hover {
color: oklch(70% .2 145);
/* 少了結尾大括號 */先補上巢狀規則與父規則的結尾，再重新執行語法檢查；不要把 parser 訊息當成瀏覽器相容性結論。
Cascade 邊界法庭
解析成功，仍然無法證明這些事
Specificity 是否符合意圖
合法的選擇器仍可能蓋掉不該覆寫的規則。
選擇器是否實際使用
工具看不到應用程式最後渲染出的 DOM。
目標瀏覽器是否支援
Parser 能讀取現代語法，不代表目標瀏覽器會執行。
畫面是否等價
尤其使用 CSSO restructuring 後，仍須以渲染與視覺回歸測試確認。