色彩學完整指南：對比色、互補色、色相環配色技巧

挑好品牌主色後，畫面仍可能缺乏層次：標題不醒目、按鈕和背景混在一起，或文字在手機上難以閱讀。這些問題需要分別檢查色相、明暗、彩度與元素用途。

品牌網站的配色往往有同一個現象：大家把色彩學想得太玄，反而漏掉真正能動手的變數。色彩學沒有你想的那麼神秘，它是一套有明確刻度的決策系統。這篇我不講美術史，只講你打開軟體那一刻就能用的東西：色相環到底怎麼讀、對比色跟互補色差在哪、明度彩度如何決定質感、WCAG 的對比比怎麼算才會過，外加一套可以重複套用的配色工作流程，並延伸到設計系統實作、多品牌主題管理、設計與開發交接的具體交付物。

快速總覽：配色好不好看，往往取決於明度、彩度與色相之間的關係。先決定「角色的比例」（背景、區塊、強調各佔多少），再決定色相環上的關係（互補、鄰近、三等分），並讓文字與非文字內容通過各自適用的 WCAG 對比門檻。這套順序記起來，配色就不再是擲筊。若要維護設計系統，再把角色抽成 CSS custom properties，依品牌主題覆寫色票 token，就能在不改結構的前提下切換整體視覺。

先把色彩學拆成三個能動手的變數

同一個顏色可以用 RGB、HEX、HSL 或其他色彩模型表示；各模型的座標定義不同。為了實務判斷，可以先從色相、明暗與鮮豔程度三個面向理解。這三個面向才是你真正能調的旋鈕，色票本身只是結果。多數人卡在配色裡打轉，往往因為把這三個旋鈕混在一起轉，調了半天也不知道動到的是哪一個。

• 色相（Hue）：顏色的「身份」，紅、橙、黃、綠、藍、紫；在 HSL 等圓柱座標中通常以 0 到 360 度表示。無彩色的色相則沒有實質意義。這是多數人直覺會先想到的面向，也是最容易過度著墨的面向。
• 明度（Value / Lightness）：顏色的亮暗程度；Value 與 Lightness 的精確定義會隨色彩模型而異。把彩色照片轉成灰階，可以協助觀察亮暗分布，但結果仍取決於灰階轉換方法。明暗差距是建立可辨識層次的重要來源。
• 彩度（Chroma）／飽和度（Saturation）：兩者都描述顏色的鮮豔程度，但定義並不相同，且會隨色彩模型而異。同一個色相提高彩度或飽和度通常會更鮮明，降低則較接近中性色；視覺效果仍會受明度、背景與面積影響。

換個方式想。你看到一個配色「很亂」，常見原因是多個高彩度顏色同時搶麥克風，不一定只是色相選錯。你看到一個配色「沒層次」，則可能是明度太接近，所有區塊糊成一片。把這兩個直覺記下來，後面所有判斷都從這裡出發。

這裡還有一個實用的小招：眯眼測試。把畫面稍微眯著眼睛看或拉遠觀看，有助於先忽略細節、觀察大面積的亮暗結構。如果這時整個畫面糊成一片、找不到焦點，就回去檢查明度落差；這只是快速目視檢查，仍要搭配對比工具與實際裝置測試。

順帶把三個常被搞混的詞分清楚：在傳統混色術語中，把一個色相加白得到的叫淺色（tint），加黑得到的叫深色（shade），加灰得到的叫濁色（tone）。這些動作會改變明暗與鮮豔程度，但實際數值如何變化取決於色彩空間與混色方法，不能一概視為固定幅度的明度或飽和度調整。把它們對回明暗與鮮豔程度兩個面向，就能更清楚預測變體會把畫面往哪個方向帶。

如果你想從螢幕光（RGB）跨到印刷（CMYK），色相、明暗與鮮豔程度仍是重要的感知面向，但色域、座標與混色原理不同，那是另一篇的事。我這裡先聚焦在螢幕端的網頁配色，跨色域的細節可以另看RGB 與 CMYK 色彩模式指南。

色相環不是裝飾品，是配色的決策樹

色相環（Color Wheel）是把色相依所採用的色彩模型排列成圓；它不是可見光譜本身，因為像洋紅這類非光譜色也會出現在環上。它真正的價值，是用角度描述同一模型中的色相關係，這也是色相環對工程腦最友善的地方。

傳統顏料教學常用十二色相環：紅、黃、藍三原色，加上二次色與三次色。這是方便練習配色關係的簡化模型，不等同於螢幕使用的 RGB 加色系統，也不是唯一的色彩科學模型。

真正實用的是「在色相環上量角度」。兩個色相在環上的夾角，可用來描述鄰近、互補或三等分等關係；夾角大小本身不等於和諧或衝突，結果還會受明度、彩度、面積與情境影響。實務上，不建議把色相環背成圖，而是把它當成一把量角器，再把角度關係與其他視覺變數一起判斷。

色相環的完整操作手法（三原色怎麼推、冷暖怎麼分、實戰配色怎麼套），想看更細的解析，可參考色相環配色完全手冊，這裡把它當前提條件，往下談更關鍵的判斷。

冷暖色溫與構圖：為什麼有些顏色會「往前跳」

色相環除了角度，還可用暖色與冷色來描述相對感受。紅、橙、黃常被視為暖色，藍、部分綠紫常被視為冷色；「前進」或「後退」是會受明度、彩度、面積、背景與文化經驗影響的知覺效果，不是每個畫面都成立的光學定律。

設計上可以把暖冷差異當成建立層次的一種手段，但 CTA 是否醒目，主要仍取決於它與周圍的明度、彩度、面積與位置對比。暖色不必然比冷色搶眼，應在實際版面與目標裝置上測試。

色彩的冷暖也可能影響情緒聯想。暖色常讓人聯想到陽光、食物或溫度，冷色則常讓人聯想到水、科技或安靜，因此不同產業會採用不同傾向；但這些不是固定的產業規則，還會受文化、內容、明度與品牌既有識別影響。先提出色溫方向作為假設，再用目標受眾與實際版面驗證，會比漫無目的地試色票更有依據。

色溫還有一個實戰用法：拿來描述主視覺的「光線感」。偏暖的配色可能讓人聯想到午後陽光，偏冷的配色可能讓人聯想到清晨或陰天，但這些聯想會受內容、文化與個人經驗影響。同樣是賣咖啡，品牌可測試偏暖的米棕調或偏冷的中性灰等方向，再用目標受眾研究確認是否符合手作、製程或穩定度等定位。先回答「這個品牌想呈現什麼光線感」，可協助縮小色票範圍，剩下來的才是色相環上的細修與明度彩度微調。

對比色與互補色：先辨認使用的色相環

這兩個詞在中文圈經常被混著用，但把它們分清楚，是配色判斷升級的第一步。換句話說，差別只有一句：互補色是精確的位置關係，對比色是視覺效果的描述。

互補色（Complementary colors）指的是特定色相環上「正對面」的那一對，夾角為 180 度；具體配對會隨色彩模型而變。紅對綠、藍對橙、黃對紫是傳統 RYB 色相環常見的配對，RGB 加色模型則以紅對青、綠對洋紅、藍對黃為互補。對比色（Contrasting colors）的範圍更廣，只要兩個顏色在視覺上形成明顯落差，都算在內：它可能是色相差距大（但不一定正對面），也可能是明度落差大（黑跟白），或彩度落差大（鮮紅跟灰紅）。

把這個區分記住的實際好處是：當你發現畫面「太衝」，你不會只盯著色相找問題，而會回頭檢查是不是明度或彩度也在疊加衝突。互補色配在一起之所以容易翻車，往往是因為設計者同時把兩邊的彩度都拉滿、面積又各佔一半，等於三重衝突同時爆發。

要讓互補色可用，有兩個老招很有效：一是調整面積比，讓一邊當主角、一邊當點綴（例如大面積的沉穩深藍配上少量橙色按鈕）；二是降低其中一邊的彩度或調整明度，把純橙改成米橙、土橙，碰撞感通常會收斂。這兩招後面會再出現，因為它們是常用的配色調整方法。

六種常見配色關係，什麼時候用哪一種

下列六種是常見的配色關係，不是唯一分類，也不是保證和諧的公式。它們可以當成探索色相組合的起點，再依情緒、內容與實際版面調整。

實務上，如果你做的是企業形象或內容站，可以先測試分裂互補或鄰近色；如果你做的是活動登陸頁、需要明顯的按鈕，也可以測試互補關係。這些都只是起點，不保證自動和諧，仍要檢查明度、彩度、面積與內容情境；四角色配色的變數較多，通常需要更明確的角色分工。

明度與彩度：一起檢查層次和可讀性

這一節是整篇文章我最希望你帶走的觀念。色相決定「這是什麼顏色」，但明度與彩度也會強烈影響質感、層次與可讀性。一個配色被說「高級」或「廉價」，差別常出在這幾個維度如何一起控制，不能用固定比例歸因。

明暗差異可以幫助區分文字與背景，但主標、內文和按鈕的層級也能用字級、字重、位置與留白建立。標題和正文不必使用不同顏色；重要的是每段文字在實際背景上都清楚可讀，操作元素也容易辨認。

再談彩度。降低彩度通常會讓畫面更克制，但不等於品質一定更高；運動、娛樂或兒童產品可能反而需要較高彩度。先根據品牌語氣與資訊層級設定彩度範圍，再用色彩心理學與實際使用情境交叉檢查，比套用「低彩度就是高級」可靠。

CSS Color Module Level 4 定義了 oklch()，它比 HSL 更接近感知均勻，適合建立較一致的明度與彩度階梯。但它不是「數值與人眼完全線性」的保證，等距數值也不代表所有裝置、背景與色域下的視覺重量完全相同；產生色階後仍要檢查 gamut mapping、對比與實機顯示。

對比比的硬規格：WCAG 1.4.3 怎麼算、怎麼過

前面一直說「明度要拉開」，拉開到底要多少？目前的 W3C Recommendation 是 WCAG 2.2，現行 Recommendation 版本日期為 2024 年 12 月 12 日；其中 Success Criterion 1.4.3 Contrast Minimum 規範文字與背景的最低對比。

對比比（Contrast Ratio）的範圍是 1:1 到 21:1，寫法是「比值：1」。公式是把前景與背景的相對亮度（relative luminance）拿出來比：(L1 + 0.05) / (L2 + 0.05)，L1 是較亮的那邊；其中 0.05 來自規範所引用的典型觀看耀光（Typical Viewing Flare）。你不必每次手算，瀏覽器開發者工具、Figma 外掛、線上檢測器都能直接給你比值，但你要知道那個數字是怎麼來的，才不會被工具誤導。

給你一個可以用大腦估的速算感覺：在純白底上，要過 AA 4.5:1 的一般文字，灰階要到 #767676 或更深；符合大型文字定義時，3:1 的界線約為 #949494 或更深（依 WebAIM 的對比整理）。這只適用於純白背景的灰階速查，換成其他前景或背景仍要重新計算。還有一個陷阱要特別注意：彩度高的兩個顏色，例如純紅配純藍，肉眼會覺得色相差異很強，但亮度對比比約為 2.15:1，仍不符合這些文字門檻。記住 WCAG 2.x 的這項計算依據是相對亮度，跟「看起來鮮不鮮」不是同一件事。

這張表對應 WCAG 2.2 的文字與非文字對比要求。一般文字至少 4.5:1，大型文字至少 3:1，另有標誌文字、純裝飾文字、停用元件中的文字等明定例外；不能自行把不重要的內文排除。UI 元件與圖形的非文字對比則要看 SC 1.4.11：只有辨識元件、狀態或理解圖形所必要的視覺資訊，才要求與相鄰顏色至少 3:1；裝飾性或非必要的邊界不一定適用。WCAG 是否構成法律或採購要求，則依司法管轄、標案與契約而定。

還有一個常被漏掉的點：對比要求不只管文字。用來辨識控制項、狀態或圖形內容的視覺資訊要與相鄰顏色達 3:1；作者自訂且用來顯示鍵盤焦點的指示器，也要在聚焦狀態下與相鄰顏色保持足夠對比。按鈕若已由文字或其他線索清楚辨識，純裝飾邊框則不一定需要單獨達到 3:1。

量化「看起來一樣」這件事：感知均勻色彩空間與 Delta E

前面提過 oklch 比 HSL 更接近感知均勻，這只是「用數字做配色」的起點。做一整套設計系統時，仍要檢查「藍色 100、200、…、900」各階的視覺距離是否符合用途。HSL 的數字與人眼感知並不一致，例如同樣 L=50% 的黃與藍，看起來亮暗可能差很多。

感知色彩空間（OKLCH／OKLab、CIELAB）與 Delta E（ΔE）可協助描述兩色差異，數字越小通常越接近。不過可辨識門檻會受 Delta E 公式、媒材、觀察環境、顏色區域與觀察者影響，不能把單一數字當成所有情境的合格線。團隊應先固定色彩空間、公式與顯示條件，再建立自己的容許範圍。

把 Delta E 用在色階時，可以先設定相鄰色階的目標距離，再依文字對比、背景用途與狀態層級調整；沒有一個數值區間適用所有公式與產品。演算法產色只是起點，最終仍要逐一驗證對比、色域與實際介面。

給你一個快速體檢：把整組色階攤開，使用同一種 ΔE 定義比較相鄰兩階。如果距離忽大忽小，先確認是否符合文字、背景或狀態層級的刻意需求；若沒有用途上的理由，再調整色階。色階不必機械式等距，但每個差異都應能由用途與測試結果說明。

對比度之外的無障礙檢查：1.4.1、2.3、forced colors 與色覺模擬

WCAG 1.4.3 的文字對比只是色彩無障礙的一部分。同一份規範還有 1.4.1 Use of Color（顏色不能是傳達訊息的唯一方式）與 2.3.1 Three Flashes 等要求，解說見 WCAG 2.2 Understanding 文件。

1.4.1 常見問題有三種。第一，表單錯誤只把輸入框邊框變紅，沒有圖示或文字說明。第二，行內超連結若沒有底線等非色彩線索，僅靠色相區分就可能難以辨識；可加上底線，或讓連結文字與周圍正文至少有 3:1 的亮度對比。hover／focus 也應提供清楚的狀態提示，且連結文字本身仍須核對與背景的文字對比。第三，圖表只用色相區分類別，沒有形狀或標籤輔助。灰階檢查可協助找問題，仍須搭配對比工具、鍵盤操作與輔助技術測試。

2.3 那條更少人留意，會踩雷的是動態設計。WCAG 2.2 SC 2.3.1 要求頁面內容不得在任何一秒內閃爍超過三次，除非閃爍低於一般閃光或紅色閃光門檻；門檻還會考量亮度或色彩變化與閃爍區域大小，不能只看頻率。人對飽和紅色閃爍更敏感，因此規範另有 紅色閃光測試。這條對首頁 hero 動畫、活動登陸頁的特效特別相關；自動輪播或視差效果只有在構成規範所定義的閃爍時才適用。

APCA 是另一種對比研究方法，不能拿它的結果直接替代 WCAG 2 的合規判定。截至 2026 年 9 月 21 日，WCAG 3.0 的最新公開工作草案版本日期為 9 月 10 日，仍在發展中，並說明不取代 WCAG 2。專案應先確認適用的規範版本；對 WCAG 2 的文字對比要求，仍使用其指定方法。

Windows 的對比佈景主題可讓瀏覽器進入 CSS forced colors 模式，由瀏覽器把部分作者色彩替換為系統色；macOS 的「增加對比」是另一種輔助顯示設定，不能視為同一套 forced colors 機制。forced colors 下應優先保留語意化 HTML 與預設的 forced-color-adjust: auto，需要自訂時可使用 HighlightText、ButtonFace 等系統色彩；不要為了保留品牌色而全面設成 forced-color-adjust: none。做色彩系統時，應分別在目標平台的對比設定下重驗按鈕、輸入框與連結。

色覺模擬是成本較低的健檢之一。Chrome DevTools 的 Rendering 面板有「Emulate vision deficiencies」，能模擬包含 Deuteranopia、Protanopia、Tritanopia、Achromatopsia 在內的數種色覺缺陷。可定期跑模擬並截圖比對，協助找出只靠顏色傳達的訊息；但模擬不能取代與實際使用者測試。

跨文化配色：當網站要賣到不只一個市場

跨市場的配色需要連同文字、圖示與使用習慣一起檢查。同一顏色的聯想會因情境而不同；先訪談或測試目標使用者，再決定哪些語意色需要在地化，不必預設每個語言版本都要換一整套品牌色。

幾個常見但不能一概而論的例子先記下來。紅色在部分東亞情境會連結喜慶或上漲，在許多西方介面也常用於危險、停止或赤字；白色可能連結東亞部分喪葬傳統，也常出現在西式婚禮與純潔意象；綠色常被用於自然或安全，在部分伊斯蘭文化情境也有宗教意涵，在中國證券市場慣例中則常表示下跌。這些聯想會隨國家、產業與情境改變，不能只靠文化刻板印象替色，應以目標市場研究校準語意色。

金融與數據產品尤其不能用單一文化假設決定漲跌色。不同市場、交易所、資料供應商與產品慣例可能相反，應研究目標使用者並讓標籤、符號與數值共同傳達狀態。把漲跌色抽成獨立 token、與品牌色脫鉤，能降低在地化時的修改成本。

實作上可把「品牌色」與「語意色」分層管理，並按 locale 覆寫。CSS custom properties 可定義 --semantic-up 這類變數，再依語言或區域設定切換。多語系頁面若使用 hreflang，每個語言版本都要列出自己以及所有其他語言版本，互相雙向回指；缺少回傳連結時，Google 可能忽略未正確互引的標記（見 Google Search Central 的多語系網站說明）。URL 與語言對應也要保持一致，進一步可參考多語系 SEO 指南。

60-30-10 法則與配色角色：把色彩學變成可重複的系統

把顏色指派給明確角色，能讓團隊討論同一種用途，也比較容易維護。角色分工是設計系統的一種方法，並不是判定設計師專業程度的標準。

一種入門的角色分配經驗法則是60-30-10：概念上讓主導色佔最大面積（通常是中性的背景與大面積底），次要色承接區塊與表面，強調色只用在少量重點。60%、30%、10% 不是無障礙標準或必須精算的門檻，它的用途是強迫畫面分出主從；若強調色用得太多，就可能失去「強調」的作用。

再進一步，把顏色分成四種角色，每種角色有明確職責：

• 品牌色（Brand / Primary）：來自品牌識別的色彩，用在 Logo、關鍵強調、導覽列重點。數量應依品牌識別需求控制，並維持清楚的主從。
• 行動色（Action / Accent）：用在 CTA 按鈕、加入購物車、立即預約等互動重點。它可以沿用品牌色，也可以獨立設定；關鍵是搭配形狀、文字與互動狀態，讓使用者知道這裡可以操作。按鈕的對比與情緒設計，可另看CTA 行動呼籲按鈕設計指南。
• 中性色（Neutral / Surface）：背景、文字、邊框、分隔線的主要分擔者。色階數量應由實際用途決定，文字與背景的組合則要逐一驗證適用的對比門檻。
• 語意色（Semantic / Status）：介面常以綠、紅、琥珀、藍分別表示成功、錯誤、警告與資訊，但這不是固定標準，也不能只靠色相傳達狀態。若與品牌色重疊，應用文字、圖示、位置或其他視覺線索保持語意清楚。

如果你的網站要同時容納多個產品線或子品牌，這套角色制還能往外加一層：可以先共用中性色與語意色，只覆寫品牌色與行動色；若特定品牌或市場有不同的無障礙、文化或產品需求，再覆寫相應角色。這通常比各自發展互不相容的色票容易維護。大型網站常見的「一個設計系統、多個主題」做法，本質就是把色彩當成可以繼承與覆寫的變數來管理。

可以先列出背景、文字、狀態與操作所需的角色，再挑選色票；也可以從既有品牌色開始，逐步補齊用途。選色與角色配置通常要來回調整，相關策略可搭配品牌選色策略一起看。

把配色系統寫進 CSS：設計 token 架構與主題切換

色票選完之後，下一步是把它變成工程系統。多數專案卡在這裡，因為設計師交了一堆 HEX，開發直接寫死在每個元件，日後要改主色就得翻遍整個 repo。常用做法是先把色票抽成設計 token（Design Tokens），再用 CSS custom properties 管理，主題切換時只要覆寫 token 值，引用它的元件就會跟著變。

一個典型的色彩 token 架構長這樣：

:root {
  /* 品牌色 */
  --color-brand-primary: oklch(0.55 0.18 250);
  --color-brand-secondary: oklch(0.65 0.15 340);

  /* 行動色（可能等於品牌色，也可能獨立） */
  --color-action-default: oklch(0.55 0.18 250);
  --color-action-hover: oklch(0.48 0.20 250);
  --color-action-active: oklch(0.42 0.22 250);

  /* 中性色階（依實際用途增減） */
  --color-neutral-50: oklch(0.98 0.01 250);
  --color-neutral-100: oklch(0.94 0.01 250);
  --color-neutral-200: oklch(0.88 0.01 250);
  --color-neutral-300: oklch(0.78 0.01 250);
  --color-neutral-400: oklch(0.65 0.01 250);
  --color-neutral-500: oklch(0.50 0.01 250);
  --color-neutral-600: oklch(0.40 0.01 250);
  --color-neutral-700: oklch(0.30 0.01 250);
  --color-neutral-800: oklch(0.22 0.01 250);
  --color-neutral-900: oklch(0.16 0.01 250);

  /* 語意色 */
  --color-semantic-success: oklch(0.65 0.15 145);
  --color-semantic-error: oklch(0.55 0.20 25);
  --color-semantic-warning: oklch(0.70 0.18 85);
  --color-semantic-info: oklch(0.60 0.18 250);

  /* 文字色（由中性色階衍生，仍需依實際背景驗證） */
  --color-text-primary: var(--color-neutral-900);
  --color-text-secondary: var(--color-neutral-600);
  --color-text-tertiary: var(--color-neutral-500);
  --color-text-inverse: var(--color-neutral-50);

  /* 背景色 */
  --color-bg-primary: var(--color-neutral-50);
  --color-bg-secondary: var(--color-neutral-100);
  --color-bg-tertiary: var(--color-neutral-200);
}

/* 暗色模式覆寫 */
[data-theme="dark"] {
  --color-text-primary: var(--color-neutral-100);
  --color-text-secondary: var(--color-neutral-300);
  --color-text-tertiary: var(--color-neutral-400);
  --color-text-inverse: var(--color-neutral-900);

  --color-bg-primary: var(--color-neutral-900);
  --color-bg-secondary: var(--color-neutral-800);
  --color-bg-tertiary: var(--color-neutral-700);
}

/* 子品牌主題覆寫 */
[data-brand="b"] {
  --color-brand-primary: oklch(0.50 0.20 180);
  --color-action-default: oklch(0.50 0.20 180);
}

這段 CSS 是角色命名與主題覆寫的起點，並非已驗證的完整色票。元件必須實際引用對應 token，主題才會生效；切換品牌時，hover、active、文字和背景的組合也要一起檢查。Figma Variables 可用 collections 與 modes 管理不同情境，再透過支援的匯出流程與開發工具銜接。

可把 token 分成原始色票與用途兩層，例如 --color-blue-500 保留色值，--color-action-default 表達操作用途。元件優先引用用途 token，能降低改色時的修改範圍；原始色票使用視覺名稱並沒有錯，也不必把所有特殊圖像或圖表都硬塞進相同命名。

多品牌與多產品線：色彩系統怎麼 scale

如果你的公司有多個品牌或產品線，色彩系統的維護成本會隨變體增加。常見的失敗模式是每個品牌各自發展互不相容的色票，導致共用元件的同一項修改必須重複處理。常用的 scale 策略是「核心共用、品牌覆寫」。

核心設計系統可定義共用元件、間距、字階，以及品牌色、操作色和語意色的角色。實作時應提供可用的預設值，或確保每個使用情境都載入完整主題，避免缺值導致宣告失效。

第二層是品牌主題層，每個品牌覆寫角色色值。品牌 A 的 brand-primary 是藍，品牌 B 是橙，但兩者都用同一個按鈕元件，只是引用的 --color-brand-primary 不同。實作上可以用 CSS modules、Sass maps 或 JavaScript 動態注入，看你的技術棧而定。

同品牌的不同產品若有實際需求，可以再增加變體層；方案名稱本身並不決定深淺或配色。先評估是否真的需要另一套色票，否則會增加驗證與維護成本。

給你一個具體結構範例：

/* 預設主題，避免缺少品牌屬性時沒有可用值 */
:root {
  --color-brand-primary: oklch(0.55 0.18 250);
  --color-neutral-50: oklch(0.98 0.01 250);
}
[data-brand="b"] {
  --color-brand-primary: oklch(0.50 0.20 30);
  --color-neutral-50: oklch(0.96 0.01 30);
}
/* 僅為結構示例，所有實際前景／背景組合仍需驗證 */
[data-brand="b"][data-variant="alternate"] {
  --color-neutral-50: oklch(0.94 0.01 30);
}

共用元件與角色 token 可以減少重複實作，但新增品牌仍要驗證字型、圖像、元件狀態和可讀性。Design Tokens Community Group 的 2025.10 格式規格已於 2025 年 10 月發布 Final Community Group Report，供工具交換 token 使用；它不是 W3C Recommendation，工具之間支援的型別與轉換流程仍須確認。

行動裝置與暗色模式：配色會在不同載體上變形

配色應在目標使用者的裝置、螢幕亮度與環境光下測試。Statista 的全球行動流量資料可以提供市場背景，但不能直接代表本站流量；安排測試裝置時，應搭配自己的分析資料與使用者需求。

第一，對比比不要只壓線。WCAG 的數值是合規門檻，不保證所有戶外環境、面板與字型都同樣好讀；在不破壞設計的前提下可適度高於門檻，並以實機驗證。第二，高彩度色要在目標裝置上檢查，因為不同面板的色域、亮度與色彩管理可能讓觀感改變，不能預設小螢幕一定更刺眼或固定要降一階彩度。第三，層次不能只靠色相或彩度，還要同時檢查明度、尺寸、間距與文字標示。更多版面層次的考量可以看響應式網頁設計。

暗色模式（Dark Mode）不是把顏色直接反相。純白配純黑的對比比是 21:1，但是否刺眼會受字級、字重、環境光與使用者差異影響；灰白文字可以是設計選擇，仍要符合適用門檻，不能把 #E0E0E0 當成通用標準（見 WebAIM 的對比說明）。高彩度顏色在暗底上的觀感也可能改變，因此品牌色的明度與彩度要依背景、用途與對比結果逐一調整，而不是一律降低固定階數。設計系統可用語意 token 為亮色與暗色模式提供不同值。

實作暗色模式時，純黑（#000000）在能關閉個別像素的 OLED 面板上可能較省電，但它不會因此產生所謂的「色域溢出」。純黑或近黑背景各有不同的對比與觀感，應依產品定位、內容密度與目標裝置實測，沒有一個通用的 OKLCH 明度值。

色彩學不只是好看：它可能影響操作與轉換

從轉換優化的角度來看，色彩可能影響可辨識性、操作與品牌感受，但對流量、名單或成交的實際效果不能只由配色推定，仍要用可用性研究與轉換資料驗證。這點可以另看企業形象網站的價值分析。

先看連結。一個超連結如果跟正文顏色太接近、又沒有底線，使用者可能把它當成普通文字而錯過下一步。這是可用性與轉換問題，不應進一步把分析工具中的停留或跳出率直接說成 Google 排名訊號。讓連結以清楚的顏色、底線與 focus／hover 狀態辨識，是成本很低的改善。

再看 CTA。很多業主糾結「按鈕要紅的還是綠的」，關鍵通常是它跟周圍環境的對比、文案、位置與互動狀態，而不是色相本身。把頁面截圖轉成灰階，可初步檢查主 CTA 是否仍有明顯層級；最終仍要用點擊與轉換資料驗證。

看視覺動線。部分文字密集頁面的眼動研究會觀察到類似 F 型的掃視模式，但使用者路徑會隨版型、任務、內容與裝置改變，Z 型也不是所有頁面的固定規律。高對比、位置、尺寸與留白都可能影響元素的顯著性，暖色則不必然最先被看見。把重要轉換訊息放在容易辨識的位置能改善可用性，但不能據此宣稱是 Google 排名訊號。想從轉換漏斗的角度把按鈕與表單的位置想清楚，可以接著看登陸頁轉換優化指南。

表單與狀態訊息是色彩影響操作的重要場景。輸入欄位的 focus 態如果沒有清楚的視覺回饋，使用者可能不確定目前焦點；錯誤訊息若只用紅色、又跟裝飾色混在一起，也可能不易辨識。把成功、錯誤、警告、聚焦等狀態視為獨立任務，依適用規範檢查對比，並加上圖示或文字輔助，別只靠顏色傳達。這能改善無障礙與可用性；是否提高轉換率仍應用資料驗證。

圖表與資料視覺化的色彩學是另一門功課

如果你的網站會放數據圖表（後台儀表板、銷售報表、案例分析），還要考慮資料的尺度與語意，因為圖表的顏色可能承載類別、順序或正負方向，而不只是好看。

圖表配色可先分三種任務。類別型資料（彼此沒有大小關係的分類）適合用彼此可區分的類別色盤，不能只要求彩度接近；順序型資料（有大小或時間先後）適合用明度或感知亮度單向變化的順序色盤，可以是單一色相，也可以是經過設計的多色相色盤；發散型資料（有明確中點、正負意義，例如年增率）適合讓兩側從中性中點往不同方向展開，中點可依背景與語意選擇淺色、深色或低彩度色。未經校正的彩虹色階通常不適合表示連續順序，因為其感知亮度不單調，還可能製造不存在的視覺邊界。

第二個重點是色覺差異。紅綠辨色障礙是常見類型，但比例會受族群、性別與統計口徑影響，不宜用單一數字概括所有使用者。圖表不要只用紅綠區分「好」與「壞」；可加上形狀、標籤、網底紋路或位置，並以實際模擬與使用者測試檢查。

這裡給你一個跨界的小提醒：圖表的網格線、座標軸、標籤這些輔助元素通常應降低視覺權重，讓資料點維持清楚層級；不一定只能用中性灰，但要確保文字與必要圖形達到對比要求。若網格線比資料更鮮明，就容易讓雜訊跟訊號搶麥克風。

Figma 的工作流程：從色票到交付

Figma 的 Styles 與 Variables 可協助管理共用色彩。交付時要核對設計稿、token 檔與實際介面是否一致，而不是只傳一張色票截圖。

第一步，在 Figma 建立 local styles 或 variables。別用隨意選取的色塊當色票，應該每個色票都對應一個命名：Brand Primary、Action Default、Neutral 100、Semantic Success。Figma 2023 年釋出的 Variables 功能可用 collections 與 modes 表示亮暗主題、裝置尺寸或品牌等不同情境；可用的 mode 數量會依方案而異。

第二步，把所有元件的文字、填色、邊框都改為引用 Styles 或 Variables，不要寫死 HEX。這樣做有兩個好處：未來改色票，所有引用該色票的元件會跟著變；開發要查某個顏色，在 Figma 右側面板就能看到它的名稱，不用猜對應的色值。

第三步，若團隊方案與席次可使用 Dev Mode，在 Inspect 面板確認開發看到的是什麼。Code section 會產生對應的程式碼片段，套用到所選物件的 Variables 也會出現在片段中；Figma 可能為了符合 CSS 語法而正規化變數名稱。你要做的是設定並核對 code syntax，例如 Figma 變數叫 brand-primary，CSS 使用 --color-brand-primary，減少翻譯成本。

第四步，匯出色票表。在提供 modes 的 Figma 方案中，可於 Variables view 對單一 mode 選「Export mode」，或對 collection 選「Export modes」，匯出符合 Design Tokens Community Group 格式的 JSON；也可透過 Variables REST API 或 Plugin API 串接，操作細節見 Figma Learn 的 Modes for variables 說明。這個 JSON 可交給 Style Dictionary 等工具產出 CSS、Sass 或平台程式碼；Tokens Studio 則是另一種管理與同步 Figma 設計 token 的工作流，實際支援範圍取決於方案與設定。

第五步，在交付文件寫下「色彩約束」。除了色票表，還要告訴開發：哪些地方必須用語意色（錯誤、成功）、哪些地方可以用品牌色、哪些地方必須用中性色。這份約束比色值本身重要，因為它防止「某個工程師覺得這個按鈕用紅色比較好」的隨意覆寫。

給你一個交付檢查清單：

• 共用色票有清楚命名，元件引用方式一致。
• 若產品支援多主題，逐一確認其變數與元件狀態。
• 核對匯出名稱、code syntax 與程式端映射，處理工具的命名正規化。
• 交付文件說明品牌、操作、中性與語意色的用途。
• 附上文字、必要非文字資訊及互動狀態的對比檢查，另行完成其他無障礙驗證。

配色失敗的七種典型

以下七種情況可作為配色檢查的起點。是否需要調整，要看實際任務、元素用途與測試結果。

1. 全部高彩度：每個區塊都用飽和色，畫面像調色盤打翻。救法：比較降低部分背景彩度或減少重點數量後，主次是否更清楚。
2. 灰字配灰底：設計稿上看得到，上手機可能看不清。救法：量對比比，一般文字至少 4.5:1，符合大型文字定義者至少 3:1，並留意規範例外。
3. 互補色各佔一半：兩組顏色若在實際畫面中爭奪注意力，可調整面積、明度與彩度；不必為符合 60-30-10 而硬改比例。
4. 漸層缺乏控制：色標過多、位置不當或跨越不合適的色彩空間，都可能出現髒帶或不自然邊界。救法：依目的精簡色標，並檢查插值色彩空間、明度走向與實機顯示；沒有固定的色相數量上限。
5. 強調色用太氾濫：CTA、標題、圖示、邊框全用同一個品牌色，結果沒有清楚主次。救法：把最高視覺權重保留給主要動作或少數重要資訊；強調色不必只用於可點擊元素。
6. 語意只靠顏色區分：品牌色與成功色相同時，如果沒有文字、圖示或位置線索，使用者可能分不清裝飾與狀態。救法：加入非顏色線索，必要時再調整明度、彩度或色相。
7. 暗色模式直接反相：直接反轉亮色模式的色值，可能破壞原有層級、語意與品牌色對比。救法：為暗色背景重新驗證每個語意 token 的明度、彩度與對比；灰白文字或降低品牌色彩度只是選項，不是固定規則。

這七個解法反覆使用同一組工具：面積比例、明度落差、彩度控制與角色分工。配色可用的核心動作不多，差別在於何時採用哪一種。更多網站視覺常見問題，可交叉比對網頁設計常見錯誤。

系統級的維護陷阱：Token 爆炸與技術債

配色不只是設計問題，長期來看也是維護問題。以下是三個大型網站常見的系統級陷阱。

第一個陷阱叫「Token 爆炸」。如果每個新功能都新增一個專用色，久而久之就會累積大量命名相近、重複或已廢棄的 token。對策是建立新增、命名與棄用規則：角色與色階數量要由產品用途決定，而不是套用固定上限；任何新需求先問「能不能用現有角色」，不行才考慮新增。

第二個陷阱叫「視覺與語意分離失效」。某天工程師為了趕功能，直接在元件裡寫死一個紅色 #FF0000，沒有用 --color-semantic-error。這個硬編碼色值可能在日後修改語意色時被漏掉。對策是在 CI 加入適合團隊規範的檢查，或用 stylelint 規則偵測未引用 token 的顏色宣告。

第三個陷阱叫「跨工具漂移」。設計師在 Figma 更新了色票但沒有同步前端，或前端改了 token 卻沒有同步回 Figma，兩邊的品牌色就可能逐漸不同。對策是建立單一來源真實：色票的定義放在一個符合團隊流程的 token 檔或服務中，Figma 與前端都由同一份資料同步或產出。Delta E 只有在指定色彩空間、公式與觀看條件後才有意義，不應用任意數值描述漂移。

從概念到落地：一份可執行的配色工作流程

把前面全部串起來，給你一份可重複的配色流程。它不是唯一的路，但能把主要判斷點排成較容易檢查的順序。

1. 鎖定品牌色與情緒定位：先決定一個主品牌色，並寫下這個網站要傳達的情緒（沉穩？活潑？專業？溫暖？）。把這些感受當成設計假設，之後用目標使用者的回饋檢查。
2. 挑配色關係：參考前面的六種色相關係，選幾組可比較的方向（例如分裂互補）。這一步只決定色相之間的角度，不挑色票。
3. 展開中性色階：用 oklch 或設計工具依實際用途建立中性色階，作為背景、文字、邊框的池子。
4. 分配角色比例：可借用 60-30-10 的主從概念，把中性、次要、強調的位置標出來，先有骨架再填色，不必把比例當成硬規格。
5. 填入色票並調明度彩度：才開始挑具體顏色。填完後回頭檢查明度落差與彩度一致性，該壓的壓、該拉開的拉開。
6. 驗對比比：依 WCAG 1.4.3 檢查一般文字 4.5:1、大型文字 3:1；另依 1.4.11 檢查辨識 UI 元件、狀態與圖形所必要的非文字資訊是否與相鄰色達 3:1。可在不破壞設計的前提下高於最低門檻，但沒有通用的 5:1 或 6:1 額外標準。
7. 做行動版與暗色模式對照：在目標手機，以及產品有提供的暗色模式中依實際背景重新調整明度、彩度與語意 token，並驗過適用的對比門檻才定稿。
8. 抽成 CSS token 架構：把色票轉成 --color-* custom properties，定義角色（brand/neutral/semantic/action）。
9. 交付文件與驗收：導出色票 JSON、寫下色彩約束、附上對比比檢測報告，確認開發收到的資訊完整。

這份流程的好處是每一步都有明確的驗收標準，你可以交給團隊、可以重複執行，不必每次配色都從感覺重新開始。如果你正在找幫你快速產生與管理色票的工具，配色工具整理與網站配色方案指南可以接著看；想從整體版面而非單一色彩切入，那麼網頁版面設計指南與UI/UX 設計指南是比較好的下一步。

診斷你的現有配色：三個快速檢查表

給你三個快速診斷，用來判斷你的現有配色系統是否健康；實際所需時間會依頁面與 token 數量而異。

檢查一：角色一致性

打開你的網站首頁，用開發者工具或 Figma，把所有顏色分成四堆（品牌、行動、中性、語意）。沒有適用所有產品的固定色值上限；真正的警訊是用途相同卻出現重複或近似色，或某些顏色無法歸類。下一步是確認它們是否有獨立用途，再決定保留、合併或棄用。

檢查二：對比比覆蓋率

用 axe DevTools 或 WAVE 逐頁檢查代表性頁面，因為瀏覽器外掛不等於自動掃描整個網站。一般文字低於 4.5:1、符合大型文字定義者低於 3:1，或必要的非文字視覺資訊低於適用門檻，都應列入修正；不能用「超過幾處」才算有問題。自動工具也無法涵蓋所有狀態與背景影像，仍要人工檢查互動狀態。

檢查三：Token 重複率

如果你的專案已經用 CSS custom properties，跑一次簡單的 script 統計哪些 --color-* 變數實際被使用。未被引用不一定代表可以直接刪除，它也可能供執行期主題、外部套件或尚未納入掃描的檔案使用；先確認依賴與棄用流程，再移除真正無用的 token 或合併語意重複的角色。

把色彩學用對，配色就不必再擲筊

回到一開始那個問題：為什麼別人配的色就是比較高級？關鍵不只在天分，也在是否知道自己正在調整哪個面向。多數人卡在色相裡打轉，以為換個顏色就會變好看；但質感還受明度與彩度影響，可用性也要看對比、非顏色線索與實際測試，能不能重複則仰賴角色分工。把這幾件事分開練，判斷會更有依據。

色相環、明度與彩度提供調色的參考；角色 token 有助於維護；WCAG 則提供部分可測量的無障礙要求。把這些工具用在具體任務，再用實際介面與使用者回饋調整，比只憑色票判斷更有依據。

1. 今天就挑一個你手上的頁面，把所有顏色分成「品牌、行動、中性、語意」四種角色，數一下各佔多少面積。
2. 用開發者工具或檢測器量每一段文字的對比比，依一般文字、大型文字與例外條件標出不符合適用門檻的組合。
3. 挑一個彩度最高的區塊，調整彩度後比較畫面層級，並確認品牌語氣與可辨識性是否更合適。
4. 把這些色票抽成 CSS custom properties，定義成 --color-brand-primary 這類語意命名，為未來的主題切換做準備。

把這四個動作做完，你會更清楚看見色彩學不是玄學，而是一組可以動手、測量與驗證的變數。