CSS 主题按钮怎么用 color-mix() 派生 hover 与浅底：对比度和 fallback 实战

设计稿里只有一枚品牌蓝，代码却很快长出 hover、浅色背景、边框和禁用态四套颜色。过去常把这些值手工抄进 CSS，改一次主色就要全局搜索；现在可以把派生关系留在样式表里，用 color-mix() 计算，再把对比度检查放到验收环节。

先把手工色值换成可追踪的 token

实际开发里大家的问题通常不是不会写 color-mix()，而是直接把它塞进按钮规则里，导致品牌色、背景色和交互逻辑缠在一起很难维护。先拆出基础 token，后续调色时只需要改一处定义就行：

:root {
  --brand: #2457d6;
  --surface: #ffffff;
  --text: #172033;
  --border: #d6def1;
}

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

这里的核心是保留一个稳定的 --brand，不要提前写出 --brand-hover、--brand-soft 之后再靠命名反推它们的来源。后续所有派生色都要能从代码里直接读出“由哪两个颜色按什么比例混合得到”的逻辑。

用 color-mix() 表达 hover、浅底和边框关系

color-mix() 接收颜色空间配置和颜色混合比例。针对主题色派生场景，建议先从可读性更好的 oklab 写法入手，别把颜色空间当成默认细节藏起来：

:root {
  --brand: #2457d6;
  --brand-hover: color-mix(in oklab, var(--brand) 86%, #000);
  --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 里做插值，得到的中间色结果可能完全不一样。项目里不用为每个组件争论“哪个颜色空间绝对正确”，但要提前定好团队统一规则：主题色派生场景全部用同一个颜色空间，特殊品牌插值需求再单独开例外。

我自己的习惯是先在 MDN 的 Color mixer 工具里对比不同配置的输出，再把最终确定的选型落地到 CSS token。对于大部分按钮和信息提示组件，oklab 更容易得到视觉上连续顺畅的明暗变化；正式上线前还是要在浅色、深色、高对比度模式下逐一复核，毕竟“看起来过渡顺滑”不等于叠加文字后能保证可读性。

把对比度验收放到派生色之后

派生色最容易出问题的环节是文字和背景的组合展示，而不是变量本身的数值。可以把各类组合整理成验收表，开发阶段逐项测试，不要只对着色板截图校验：

W3C 对 WCAG 1.4.3 的规范说明里，把 4.5:1 和 3:1 作为通用对比度阈值。这个数字是最低合格线，不是视觉质量的上限；部分浅灰色、细字和小字号文本哪怕刚好卡过阈值，放在真实用户的各类屏幕上仍可能很难看清。

为旧环境保留静态 fallback

动态派生的新值不能让低版本浏览器里的整个按钮连背景都没了。先写一个稳定可用的十六进制色值打底，再用新语法做覆盖；浏览器不认识后面的新声明时，会自动保留前面的兼容结果：

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

如果你的 token 体系依赖多个还没做兼容的变量，fallback 也要用独立的、可直接解析的可读颜色，不要写另一个同样无法被旧浏览器解析的长表达式。发布前至少做两轮检查：关闭新 CSS 特性后的页面样式是否仍可用；开启新特性后，按钮文字和背景的对比度是否达到项目预设阈值。

迁移清单：从一枚品牌色扩展到整套主题

• 在 :root 与深色主题中分别定义基础色和页面底色。
• 只为有明确语义的状态派生 token，不要生成几十个没有实际使用场景的中间色。
• 统一选定颜色空间，并在设计系统文档里写明各类场景的混合比例。
• 对文字、按钮、提示框和边框分别做组合验收，不能用色板截图代替真实组件测试。
• 保留静态 fallback，确认兼容检查全部通过后，再清理已经没用的重复旧色值。

相关问题

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

不能简单一对一替换。两者底层的颜色空间和计算逻辑不一样，迁移的时候要以最终组件的实际展示效果和对比度结果为准，不能只对比函数名称直接替换。

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

先确认颜色空间配置、混合比例和底层底色，再确认设计稿里是不是用了透明度或者其他不同的色彩配置。相同的十六进制输入，不代表能得到完全一致的插值结果。

旧浏览器一定要放弃动态 token 吗？

不必。用静态声明做最低可用性保障，再让支持 color-mix() 的浏览器自动覆盖成动态派生值，新的主题能力和基础可用性可以同时兼顾。

最后的判断

把 color-mix() 当成“可解释的派生关系描述工具”，而不是新的自动色值生成器，整套主题系统后续会更容易扩展。先固定好 token、颜色空间和验收阈值，再逐个组件做迁移；当动态计算的结果不满足对比度要求时，回退到可读性优先的固定色，比为了保留公式完整性牺牲用户体验要稳妥得多。