UI 色彩系統是什麼？它和一般配色有什麼不同？
UI 色彩系統是讓設計與開發共用的一套顏色規則，重點不只在 UI 配色是否好看，而是品牌色、語意色、狀態色、文字色、背景色與 Design Tokens 是否能長期一致、可維護、可擴充。
很多產品一開始只會有幾個品牌色和幾組 HEX 色碼，畫面看起來也許成立，但當元件變多、狀態變多、深色模式出現，顏色很快就會失控。真正的 UI 色彩系統要回答的是：這個顏色用在哪裡、代表什麼語意、在 Figma 和程式碼裡叫什麼、換主題時要不要跟著變。
一般配色解決「好不好看」，色彩系統解決「能不能維護」
一般配色常從視覺感受出發，例如主色、輔色、點綴色是否協調。色彩系統規劃則要把顏色放進產品流程：按鈕 hover 要用哪一階、錯誤訊息要不要和 danger button 共用、文字色和背景色是否符合可近用性。
| 比較項目 | 一般 UI 配色 | UI 色彩系統 |
|---|---|---|
| 核心目標 | 畫面協調、品牌感明確 | 讓產品介面可維護、可擴充 |
| 管理單位 | 色碼或色票 | 色階、語意 token、元件 token |
| 使用情境 | 單一頁面或視覺稿 | 多頁面、多元件、多平台 |
| 常見風險 | 不同設計師各自挑色 | 若命名與治理不足，token 仍會漂移 |
一套 UI 色彩系統要支援品牌、層級、狀態、互動與可近用性
品牌色負責識別，中性色負責介面結構，語意色負責成功、警告、錯誤與資訊，狀態色負責 hover、active、focus、disabled、selected 等互動。少了其中一層，設計師就會開始借色，工程師也會開始在程式碼裡補色碼。
我的判斷是，色彩系統最容易壞掉的地方不是主色選錯，而是邊框色、背景色、disabled、focus ring 這些看似細小的狀態沒有被定義。這些地方每天都會被用到，卻常被當成視覺細節處理。
配色工具只能給靈感，不能直接取代色彩系統
配色工具可以協助探索色相與氛圍，但工具產出的色票通常不會知道你的產品是否有高密度表格、錯誤流程、深色模式、品牌限制或前端框架。工具是起點，不是規則本。
規劃 UI 色彩系統前，要先決定哪些設計條件？
規劃 UI 色彩系統前，要先確認產品類型、品牌色角色、介面密度、使用情境、平台限制與可近用性要求。這些條件會決定顏色該偏向品牌表達，還是偏向狀態辨識與操作效率。
產品是行銷網站、App、SaaS 還是 B2B 後台？
行銷網站通常需要更強的品牌色與視覺節奏；App 需要穩定的操作狀態；SaaS 與 B2B 後台則更重視資料可讀性、表格層級、狀態標籤與長時間使用的舒適度。產品類型不同，品牌色的使用比例也不同。
顏色主要用來表達品牌，還是傳達狀態與層級？
如果產品主要靠內容與操作完成任務，顏色應該先服務狀態與層級，再服務裝飾。品牌色可以出現在主要操作、焦點狀態、關鍵導覽，但不應該填滿每個卡片、每個 icon、每個背景。
| 規劃條件 | 要確認的問題 | 對色彩系統的影響 |
|---|---|---|
| 產品類型 | 是展示型、交易型，還是工作型介面？ | 決定品牌色與中性色比例 |
| 介面密度 | 畫面是否有大量表格、篩選器、狀態標籤？ | 影響背景、邊框、文字色階需求 |
| 使用情境 | 使用者是短時間瀏覽，還是長時間工作？ | 影響對比、彩度與視覺疲勞控制 |
| 可近用性 | 是否需要符合 WCAG 或內部無障礙標準？ | 影響文字、按鈕、狀態與圖表色 |
B2B 產品的色彩使用邏輯：少裝飾、多回饋、清楚標示狀態
B2B 產品的 UI 色彩規劃通常不適合過度情緒化。顏色應該幫使用者快速判斷任務狀態，例如資料是否異常、操作是否成功、權限是否受限、目前是否選取某筆資料。
高密度資料介面要保留更多中性色與邊框色
高密度介面需要多組 neutral、surface、border 與 text token，才能做出清楚但不吵的層級。若只有一個灰色，表格線、卡片背景、次要文字、分隔線很快會互相混用。
重要操作不能只靠顏色辨識
刪除、送出、付款、停用、核准這類操作，不能只靠紅色或綠色讓使用者判斷。文字、icon、位置、確認流程與 focus 狀態都要一起設計，否則色盲情境與低對比螢幕會放大風險。
一套 UI 色彩系統應該包含哪些顏色？
完整的 UI 色彩系統至少要包含品牌色、中性色、語意色、狀態色、文字色、背景色、邊框色與資料視覺化色。主色、輔色、點綴色只能處理品牌表達，無法支撐完整產品介面。
品牌色：建立產品識別與主要操作焦點
品牌色通常包含 primary、secondary 或 accent。primary 適合用在主要 CTA、連結焦點、選取狀態與少數品牌識別區塊。若品牌色彩度很高，最好另外建立可用於按鈕、背景與文字的色階，而不是直接把 Logo 色塞進所有元件。
中性色：支撐背景、文字、邊框與介面層級
中性色是 UI 色彩系統的骨架。背景、surface、分隔線、邊框、主要文字、次要文字、placeholder、disabled 幾乎都仰賴中性色。很多介面看起來凌亂，不是品牌色太弱，而是中性色沒有分工。
語意色：成功、警告、錯誤、資訊不能只靠主色延伸
語意色要讓使用者一眼理解狀態。success、warning、danger、info 應該有自己的色階與對比檢查，不能把品牌色調亮調暗後勉強當錯誤或警告使用。錯誤就是錯誤，品牌色不該搶語意色的工作。
狀態色：hover、active、focus、disabled、selected、loading
狀態色負責互動回饋。button hover、input focus、table row selected、disabled button、loading background 都需要明確 token。若沒有狀態色，設計檔容易出現十幾種相近但用途不明的藍色或灰色。
資料視覺化色：圖表顏色要能彼此辨識
圖表色需要考慮分類辨識、順序關係、色盲情境與標籤輔助。資料視覺化色不一定要跟品牌色完全一致，但要能和整體 UI 協調，並避免和 danger、warning 等語意色混淆。
必放表格欄位：顏色類型、用途、常見 token、使用範例、注意事項
| 顏色類型 | 用途 | 常見 token | 使用範例 | 注意事項 |
|---|---|---|---|---|
| 品牌色 | 主要識別與操作焦點 | color-primary-500 | 主要按鈕、連結 | 避免到處當背景色 |
| 中性色 | 介面層級與文字 | color-neutral-700 | 正文、次要文字、邊框 | 需要足夠階數 |
| 語意色 | 傳達成功、警告、錯誤、資訊 | color-danger-600 | 錯誤提示、警示訊息 | 不要和品牌色混用 |
| 狀態色 | 互動與選取回饋 | color-focus-ring | hover、focus、selected | 互動狀態也要檢查對比 |
| 圖表色 | 資料分類與趨勢辨識 | color-chart-1 | 折線圖、長條圖 | 加上標籤與形狀輔助 |
如何從品牌色建立可用的 UI 色階？
從品牌色建立 UI 色階時，先選一個基準色作為 primary-500 或 primary-600，再延伸 50 到 950 的亮階與暗階，並為每一階指定用途，例如背景、邊框、按鈕、hover、active、深色模式。
先選基準色：通常用 primary-500 或 primary-600 當品牌主色
基準色應該是品牌識別最穩定、也最常出現在互動元件上的顏色。若品牌色過亮，可能不適合當主要按鈕背景；若品牌色過暗，可能不適合用於 focus 或 selected 背景。這時可以保留品牌原色，但另定 UI 使用基準色。
再建立亮階與暗階：50、100、200 到 900、950
50 到 200 多用於背景與提示區塊，300 到 500 可用於邊框、圖示或次要狀態，600 到 700 常用於主要按鈕與連結，800 到 950 則適合文字、hover、active 或深色模式中的高對比元素。
不要只調透明度，要確認每一階的用途
只用透明度做色階，在不同背景上會產生不可預期的顏色，也會讓工程實作變得難以控管。比較好的做法是定義實色 token，再說清楚每一階對應的產品用途。
淺色階：背景、提示區塊、選取底色
primary-50、primary-100、success-50、warning-100 這類淺色階，適合用在 selected row、alert 背景、空狀態提示、輕量區塊。它們要柔和，但仍要讓使用者看得出狀態。
中間階：主要按鈕、連結、焦點狀態
primary-500 或 primary-600 常是主要按鈕背景與連結色的候選。這些顏色要同時通過品牌一致性與文字對比檢查，不能只看色票漂亮。
深色階：文字、hover、active、深色模式補強
primary-700 到 primary-950 可用在 hover、active、深色文字、強調狀態與深色模式的補強色。深色階過度接近黑色時，品牌感會消失；過度彩色時，長時間閱讀會疲勞。
| 色階 | 常見用途 | 規劃提醒 |
|---|---|---|
| 50 至 100 | 背景、提示區塊、選取底色 | 要避免與白色背景差異太小 |
| 200 至 300 | 淡邊框、輕量 icon、輔助狀態 | 適合做低干擾回饋 |
| 400 至 600 | 主要按鈕、連結、焦點 | 優先檢查文字對比 |
| 700 至 950 | hover、active、深色文字、深色模式 | 避免一律拉到接近純黑 |
為什麼現代 UI 色彩系統開始使用 OKLCH？
現代 UI 色彩系統開始使用 OKLCH，是因為它比 HSL 更接近人眼對明度與彩度的感受，較適合建立視覺上連續的 UI 色階。OKLCH 不必立刻取代所有 token，但很適合用於新系統或大型重整。
HEX 適合儲存色值，不適合規劃色階
HEX 是常見的色值格式，適合儲存在設計檔、CSS 或 token JSON 裡，但它不容易讓人判斷明度、彩度與色相的關係。只看 #2563EB 或 #1D4ED8，很難知道它們在色階中的視覺距離是否穩定。
HSL 容易讓黃色、橘色、藍色的明度看起來不平均
HSL 把色相、飽和度、亮度拆開，操作上比 HEX 直覺，但不同色相在相同 lightness 數值下，看起來不一定一樣亮。黃色常顯得更亮，藍色常顯得更暗，這會讓色階在 UI 裡出現不連續感。
OKLCH 更適合建立視覺上連續的 UI 色階
OKLCH 是一種較符合感知一致性的色彩空間，L 代表明度，C 代表彩度，H 代表色相。用它規劃色階時，比較容易讓 primary、success、warning、danger 的明暗變化看起來一致。
什麼情況值得導入 OKLCH，什麼情況先用現有 token 即可
若團隊正在建立新 Design System、重做品牌色階、支援深色模式，或需要大量語意色與圖表色，OKLCH 很值得納入流程。若現有產品 token 已穩定、元件庫完整、問題只集中在少量頁面，先改善命名、用途與對比，通常比全面改色彩空間更實際。
| 格式 | 適合用途 | 限制 |
|---|---|---|
| HEX | 儲存與交付色值 | 不利判斷明度和彩度關係 |
| HSL | 快速調整色相與亮度 | 不同色相的感知明度不穩定 |
| HCL | 較接近人眼感受的色彩規劃 | 團隊理解成本較高 |
| OKLCH | 建立連續色階、深色模式與現代 token | 需要前端與設計流程配合 |
UI 色彩系統如何套用到元件與介面狀態？
UI 色彩系統要透過語意 token 和元件狀態套用到 button、input、alert、badge、link、navigation、surface 與 border。顏色不能停在色票層，必須進入元件規則才算真正可用。
Button：primary、secondary、danger、disabled、loading
按鈕至少要定義 primary、secondary、danger、disabled、loading，並處理 default、hover、active、focus。danger button 不應該借用 primary 色階，否則刪除、停用、取消這類高風險操作會失去清楚語意。
Input：default、hover、focus、error、disabled
輸入框要有 default border、hover border、focus ring、error border、disabled background 與 placeholder color。表單狀態是色彩系統的壓力測試，因為它同時牽涉文字、邊框、提示訊息與互動回饋。
Alert：success、warning、danger、info
alert 應該使用語意色，而不是品牌色。success、warning、danger、info 各自需要背景、邊框、icon、標題文字與正文文字的色彩組合，並確認在淺色與深色模式中都能辨識。
Background / Surface：用中性色建立層級，不要到處用品牌色
surface 是介面承載資訊的底。頁面背景、卡片背景、浮層、側欄、表格列、選取底色都需要明確區分。若每個區塊都放品牌色，使用者會分不出哪個區塊真的重要。
60-30-10 可以作為版面比例參考，但不能取代 token 規劃
60-30-10 可以幫助初期抓主色、中性色、點綴色比例，但它無法處理 focus、disabled、error、selected、loading，也無法告訴工程師 token 名稱。把它當版面參考可以，當色彩系統核心就會太薄。
| 元件 | 需要的狀態 | 建議 token 類型 |
|---|---|---|
| Button | default、hover、active、focus、disabled、loading | component token |
| Input | default、hover、focus、error、disabled | semantic token 與 component token |
| Alert | success、warning、danger、info | semantic token |
| Surface | page、card、popover、selected | semantic token |
UI 色彩系統的三個檢查標準：層級、可讀性、品牌表達
檢查 UI 色彩系統時，最實用的三個標準是層級、可讀性與品牌表達。好的色彩系統會讓使用者知道重點在哪裡、文字能不能讀、品牌是否一致但不干擾操作。
層級：使用者是否知道哪個資訊最重要？
層級不是把顏色加重，而是讓視覺優先順序清楚。主要操作、次要操作、危險操作、資訊提示、背景分區都要有穩定規則。常見失敗是每個 CTA 都使用高彩度品牌色，結果所有元素都在搶注意力。
可讀性：文字、背景、互動狀態是否清楚？
可讀性要分開看正文、小字、按鈕文字、錯誤訊息、placeholder、badge、圖表標籤。只檢查一組正文對比不夠，因為真正出問題的常是小字、disabled、hover 與暗背景上的文字。
品牌表達：品牌色是否穩定但不過度使用？
品牌表達應該像穩定的方向感，而不是每個角落都刷上主色。品牌色過度使用會降低操作辨識，也會讓 danger、warning、info 等語意色失去位置。
常見失敗：每個 CTA 都在搶注意力
如果畫面上同時有三個以上高彩度按鈕，使用者通常不會覺得選擇更多，只會更難判斷主行動。色彩系統應該限制 primary action 的使用條件，讓真正重要的操作留下視覺重量。
如何檢查可近用性、對比與深色模式？
檢查 UI 色彩系統的可近用性，要同時看 WCAG 對比、APCA、互動狀態、色盲情境、圖表輔助與深色模式。可近用性不是只檢查正文對比，而是檢查使用者能否完成任務。
文字與背景對比：正文、小字、按鈕文字分開檢查
正文、caption、小字、按鈕文字、badge 文字要分開檢查。WCAG 是常見基準，APCA 則提供另一種更接近閱讀感受的對比評估方向。團隊不一定要一開始就導入所有標準，但不能只靠肉眼判斷。
互動狀態對比：focus、hover、selected 也要可辨識
focus ring、hover background、selected row、active tab 都要讓使用者看得出差異。鍵盤操作使用者尤其依賴 focus 狀態，如果 focus 只是一圈很淡的灰線，實務上等於沒有回饋。
色盲情境：錯誤與成功不能只靠紅綠分辨
success 和 danger 不應只靠綠色與紅色區分。文字標籤、icon、圖案、位置與訊息內容都要一起提供線索。這一點在表單驗證、狀態 badge、資料圖表中尤其重要。
深色模式：不是把顏色反轉，而是重建 surface、text、border 階層
深色模式需要重新定義 surface、text、border、overlay、focus 與語意色。把淺色模式直接反轉，常會造成對比刺眼、品牌色螢光感太重、邊框層級消失。深色模式應該是一組獨立語意映射，而不是濾鏡。
圖表色要加上標籤、形狀或線型輔助
圖表不能只靠顏色讓使用者分辨資料系列。分類標籤、線型、點型、圖例、直接標註都能降低誤讀。資料視覺化色若和 UI 語意色衝突，也應優先保留語意色的辨識位置。
| 檢查項目 | 檢查內容 | 常見問題 |
|---|---|---|
| 文字對比 | 正文、小字、按鈕文字、badge | 小字和次要文字太淡 |
| 互動狀態 | focus、hover、selected、active | 鍵盤 focus 幾乎看不見 |
| 色盲情境 | success、danger、warning、圖表 | 只靠紅綠判斷狀態 |
| 深色模式 | surface、text、border、語意色 | 直接反轉造成刺眼或層級消失 |
從 Figma 到程式碼：色彩系統如何落地？
UI 色彩系統要落地，需要把 Figma Variables、Design Tokens、CSS variables 與 Tailwind theme 串起來。設計端管理 primitive 與 semantic token，開發端用變數接住，避免 Figma 和程式碼各自長出一套顏色。
設計端：用 Variables 管理 color primitive 與 semantic token
Figma Variables 可以把色彩從單純色票提升成可切換、可命名、可維護的變數。primitive token 保存基礎色階，例如 blue-500；semantic token 表達用途，例如 text-primary、surface-default、border-subtle。
開發端：用 CSS variables 或 Tailwind theme 接住 token
前端可以用 CSS variables 管理全站色彩，也可以把 token 接到 Tailwind theme。重點是工程師不直接在元件裡寫死 HEX，而是引用語意變數。這樣品牌色調整、深色模式切換、元件狀態更新才不會散落在各處。
命名規則：不要讓 token 名稱綁死單一顏色
token 命名要避免把用途綁死在顏色名稱上。color-text-primary 比 color-gray-900 更適合作為語意 token，因為淺色模式可能對應 gray-900，深色模式可能對應 gray-50。這是設計到開發一致性的關鍵。
Primitive token 範例：--color-blue-500
primitive token 保存色階本身，適合放在基礎層，不直接要求設計師在元件中大量使用。
Semantic token 範例：--color-text-primary
semantic token 表示用途，適合用於頁面、文字、背景、邊框與狀態。大多數設計與開發應優先引用這一層。
Component token 範例：--button-primary-bg
component token 把語意色套到特定元件狀態，例如主要按鈕背景、hover、active、disabled。元件庫越成熟，這一層越重要。
:root { --color-blue-500: #2563eb; --color-blue-600: #1d4ed8; --color-neutral-50: #f8fafc; --color-neutral-900: #0f172a;—color-text-primary: var(—color-neutral-900); —color-surface-default: var(—color-neutral-50); —color-action-primary: var(—color-blue-500);
—button-primary-bg: var(—color-action-primary); —button-primary-bg-hover: var(—color-blue-600); }
[data-theme=“dark”] { —color-text-primary: #f8fafc; —color-surface-default: #111827; —color-action-primary: #60a5fa; }
建立 UI 色彩系統的完整流程
建立 UI 色彩系統的流程是：盤點現有色值、定義品牌色與語意色、建立 50 到 950 色階、轉成 Design Tokens、套用到元件、檢查可近用性與深色模式，最後建立版本管理。
Step 1：盤點現有色票與硬編碼色值
先整理 Figma、CSS、Tailwind theme、元件庫與舊頁面裡的色值。目標不是立刻刪除，而是看出哪些顏色重複、哪些只差一點點、哪些沒有明確用途。
Step 2：定義品牌色、中性色、語意色
把顏色分類成 primary、secondary、neutral、success、warning、danger、info、surface、border、text。分類時要先看用途，再看色相。用途清楚，後面命名才會穩。
Step 3：建立 50-950 色階與用途
為 primary、neutral 與主要語意色建立色階，並標明每一階用途。不是每個色相都一定要做滿，但常用色至少要能支援背景、文字、邊框、互動與深色模式。
Step 4：轉成 primitive、semantic、component token
primitive 保存色值，semantic 表達用途，component 對應元件狀態。這三層可以避免設計端只看色票、開發端只看色碼，最後兩邊對不起來。
Step 5：套用到 button、input、alert、surface
先選最常用、最容易暴露問題的元件套用，例如 button、input、alert、badge、surface。這些元件能快速驗證狀態色、語意色、中性色與對比是否足夠。
Step 6：檢查 WCAG / APCA、色盲情境與深色模式
對比檢查要覆蓋文字、元件、圖表與互動狀態。深色模式要用 semantic token 重新映射，不要讓工程端靠臨時覆寫補洞。
Step 7：建立版本管理與使用規則
色彩系統要有版本、變更紀錄、例外申請與回收機制。否則每次新活動、新頁面、新功能都會新增一兩個臨時色，半年後又回到不可維護的狀態。
常見錯誤：為什麼色彩系統最後還是失控？
色彩系統失控，通常不是因為一開始選色不好，而是硬編碼 HEX、token 命名混亂、例外色沒有回收、深色模式缺策略，導致設計檔與程式碼慢慢漂移。
錯誤 1：直接在程式碼寫死 HEX
寫死 HEX 會讓顏色散落在元件、頁面與樣式檔中。短期很快，長期每次改品牌色或深色模式都會變成搜尋與替換。修正方式是把色值集中到 token，再讓元件引用變數。
錯誤 2：token 名稱用顏色而不是用途
如果元件直接引用 blue-500，當主色從藍色換成紫色時，命名就會失真。blue-500 適合作 primitive，button-primary-bg 才適合作元件用途。
錯誤 3：只做淺色模式，沒有深色模式策略
只為淺色模式規劃色彩，後續深色模式很容易變成補丁集合。應該在 semantic token 層就預留 theme mapping，讓 text、surface、border、action、danger 都能切換。
錯誤 4：狀態色與品牌色互相混用
品牌色用來建立識別，狀態色用來傳達結果與風險。把主色拿去當 warning 或 danger，會讓使用者判斷錯誤，也會讓產品語意變得模糊。
錯誤 5：新增例外色卻沒有回收機制
例外色不是不能有，但要知道誰新增、為什麼新增、使用在哪些元件、何時檢查是否回收。沒有治理的例外，很快就會變成下一代技術債。
UI 色彩系統和 UI 配色有什麼差別？
UI 配色多半處理畫面是否協調，UI 色彩系統則處理顏色如何被命名、分類、套用到元件、轉成 Design Tokens，並在設計與程式碼中保持一致。
一套 UI 色彩系統最少需要哪些顏色？
至少需要品牌色、中性色、文字色、背景色、邊框色、語意色與主要互動狀態色。若產品有圖表或深色模式，也要另外規劃資料視覺化色與深色模式 token。
主色、輔色、點綴色還夠用嗎？
不夠。主色、輔色、點綴色可以處理品牌視覺，但無法完整支援 hover、focus、disabled、error、surface、border、text、dark mode 等產品狀態。
UI 色階一定要做 50-950 嗎？
不一定。50-950 是常見且好溝通的色階結構，適合團隊協作與前端實作。小型產品可以先做常用階數，但每一階仍要有明確用途。
OKLCH 比 HSL 適合做 UI 色彩系統嗎？
多數情況下，OKLCH 更適合建立視覺上連續的 UI 色階，因為它對明度與彩度的控制較接近人眼感受。若團隊目前 token 穩定，也可以先改善用途與命名，再逐步導入。
Figma Variables 和 Design Tokens 有什麼關係？
Figma Variables 是設計端管理變數的工具，Design Tokens 是跨設計與開發共用的資料結構。Variables 可以承載 token 概念，讓顏色在設計檔中不只是色票，而是有用途的變數。
CSS variables 可以怎麼管理 UI 色彩？
CSS variables 可以把 primitive、semantic、component token 寫成可重用變數，例如 --color-text-primary、--color-surface-default、--button-primary-bg。深色模式也能透過 theme selector 重新映射變數。
深色模式要重新做一套色彩系統嗎？
深色模式不一定要重新命名一套系統，但需要重新定義 token 對應。text、surface、border、action、danger 在深色背景上的色值通常要另外映射，不能直接反轉淺色模式。
UI 色彩系統需要符合 WCAG 嗎？
建議需要。WCAG 是文字與介面對比的常見基準，能降低可讀性問題。若產品有高可近用性要求，也可以搭配 APCA、色盲模擬與鍵盤 focus 檢查。
配色工具產出的色票可以直接拿來做產品嗎？
不建議直接使用。配色工具可以提供靈感，但產品還需要語意色、狀態色、對比檢查、元件套用、token 命名與深色模式策略。
UI 設計需要深入學 RGB、CMYK 嗎？
UI 主要面向數位螢幕，所以基本理解 RGB、HEX、HSL、OKLCH 會更直接。CMYK 主要用於印刷輸出，除非專案同時包含大量印刷物，否則不用把 CMYK 當成 UI 色彩系統核心。
為什麼不建議大量使用純黑與純白？
純黑與純白對比很強，少量使用沒有問題，但大量使用容易造成視覺疲勞，也會讓 surface、border、文字層級缺少緩衝。多數 UI 會使用接近黑與接近白的中性色，讓畫面更穩定。