CSS color-mix 怎么控制主题色过渡：混合空间、透明度与降级验收

主题色真正难维护的地方，往往不是主色本身，而是 hover、浅色提示框、边框和禁用态越写越多。用 color-mix() 可以把这些颜色重新表达成“由谁和谁按什么比例混合”，但混合空间、透明度和浏览器兼容性必须一起验收，不能只看一张色板截图。

先把基础色和派生色分开

不要一上来就把一长串 color-mix() 写进按钮规则。先确定主题系统的基础输入，后面查问题时才能知道是哪一个 token 改变了最终颜色。

:root {
  --brand: #2457d6;
  --surface: #ffffff;
  --text: #172033;
  --muted: #63708a;
  --line: #d6def1;
}

.button {
  color: #ffffff;
  background: var(--brand);
  border: 1px solid var(--brand);
}

深色主题也应该重新定义基础色，而不是把浅色主题的派生值全部反转。这样做虽然多几行变量，却避免了透明度叠加后出现“同一个 token 在两个背景上表现完全不同”的问题。

用 color-mix() 描述交互状态

color-mix() 的第一个参数可以明确指定颜色空间，后面再写参与混合的颜色和比例。下面这组值把 hover、浅底和分隔线都保留成可读的来源关系：

:root {
  --brand: #2457d6;
  --surface: #ffffff;
  --brand-hover: color-mix(in oklab, var(--brand) 86%, #000000);
  --brand-soft: color-mix(in oklab, var(--brand) 12%, var(--surface));
  --brand-line: color-mix(in oklab, var(--brand) 36%, var(--surface));
}

.button:hover {
  background: var(--brand-hover);
}

.notice {
  background: var(--brand-soft);
  border-left: 3px solid var(--brand-line);
}

这里的比例不是“越大越好”。hover 颜色要与按钮文字一起检查，浅底要与正文和链接一起检查，边框还要看它在相邻背景上是否仍然可辨认。派生变量只表达计算关系，合格与否要交给组件验收。

为什么要固定混合空间

同一对输入色在 srgb、hsl 和 oklab 中插值得到的中间色并不相同。团队如果有人按 srgb 写、有人按 oklab 写，设计稿里看起来相近的状态，落到组件上就可能出现明暗跳变。

实践中可以先选定一套默认规则：主题色的明暗派生统一使用 oklab，品牌有明确色彩规范的特殊组件再单独说明。不要把选择藏在工具生成的长 CSS 里，变量声明本身就应该能让维护者看懂。

验收时至少比较三组环境：浅色背景、深色背景和高对比度模式。如果中间色在色板上平滑，但叠加小字号文字后读不清，就应该调整比例或换成固定回退色。

透明度混合要看最终背景

透明度是最容易造成误判的地方。一个带 alpha 的派生色不是固定的“半透明品牌色”，它会继续和下面的背景合成。相同的 token 放在白色卡片、灰色页面和深色主题上，最终 RGB 值可能完全不同。

.badge {
  color: var(--brand);
  background: color-mix(in oklab, var(--brand) 16%, transparent);
}

如果这个徽标中的文字必须稳定可读，不能只验徽标变量的颜色值。要把徽标放进真实页面，分别检查正文、图标和边界线；对必须严格通过的组合，宁可使用不透明的固定色。

把对比度检查放到派生之后

W3C 对普通文字通常采用 4.5:1 的最低对比度门槛，大号文字通常采用 3:1。它们是合格线，不是视觉质量的上限；细字体、低亮度屏幕和不同显示器仍可能让刚好过线的颜色显得吃力。

• 按钮文字与正常态、hover 态背景分别核验。
• 提示框正文与浅底、链接与浅底分别核验。
• 禁用态不要只降低透明度，还要确认信息不会变成无法辨认。
• 边框和图形的可辨识要求按组件用途单独确认，不能用正文阈值机械替代。

为不支持新语法的浏览器保留 fallback

静态声明要放在动态声明前面，并且本身必须是浏览器能够直接解析的颜色：

.button {
  background: #2457d6;
  background: color-mix(in oklab, #2457d6 86%, #000000);
}

如果派生值依赖多个新特性变量，fallback 不要再套一层同样无法解析的表达式。发布前关闭新 CSS 特性做一次基础可用性检查，再在支持新语法的环境中检查主题切换和对比度。

一份可以落地的迁移清单

1. 列出品牌色、背景色、正文色等基础 token，并为浅色和深色主题分别确认输入。
2. 为每个派生 token 写清颜色空间、参与颜色和比例，避免只留下一个神秘十六进制值。
3. 把按钮、提示框、徽标和边框放进真实组件，检查透明度叠加后的最终效果。
4. 按普通文字 4.5:1、大号文字 3:1 的最低线做对比度复核，并记录例外。
5. 保留静态 fallback，再检查旧环境、主题切换和动态更新三条路径。

相关问题

color-mix() 能直接替代 Sass 的 lighten() 吗？

不能按函数名直接替换。两者的颜色空间和计算逻辑可能不同，迁移时应以真实组件的最终颜色、对比度和主题切换结果为准。

为什么同样的两个颜色混合后和设计稿不一样？

先确认颜色空间、比例、透明度和底层背景，再确认设计稿是否使用了另一套色彩配置。输入色相同，不代表插值结果相同。

有了 fallback 还需要测试旧浏览器吗？

需要。fallback 只是保证基础声明可用，变量依赖、主题切换和组件状态仍可能暴露兼容问题，至少应在项目支持的最低浏览器环境走一遍关键页面。

把动态颜色当成可验证的关系

color-mix() 的价值不在于少写几个十六进制值，而在于让派生颜色的来源、比例和主题关系重新可追踪。先固定混合空间，再把透明度、对比度和 fallback 纳入组件验收，动态主题才不会变成一组只能凭感觉调整的颜色。