color-mix() 在 Chrome 111+、Firefox 112+、Safari 16.4+ 支持但行为不一致,需显式声明色彩空间如 in srgb;旧版 Safari 完全忽略,须配降级方案;@supports 检测应优先用 oklch() 或完整 color-mix() 语法。

Chrome/Firefox/Safari 对 color-mix() 的支持现状
现在直接用 color-mix() 写渐变中间色,Safari 16.4+ 才认,Chrome 111+ 和 Firefox 112+ 虽已支持,但默认行为不一致:Firefox 默认按 srgb-linear 混合,Chrome 和 Safari 用 srgb。没声明空间时,同一行代码在 Firefox 里颜色偏灰,视觉上就“不对”。
- 必须显式写全语法:
color-mix(in srgb, red 50%, blue 50%),不能省略in srgb - 旧版浏览器(包括 Safari 16.3 及更早)完全忽略该函数,会回退到声明的前一个有效颜色值,所以得配降级方案
- 不要指望
color-mix()在伪类或动画中动态生效——部分 Safari 版本对它在:hover里的重计算有延迟或跳变
用 @supports 安全启用现代色彩函数
别用 UA 判断,也别靠 JS 检测,@supports 是唯一靠谱的 CSS 原生路子。但它对色彩函数的支持检测有陷阱:只写 @supports (color: color-mix(...)) 会被所有浏览器当语法错误直接丢弃,必须用字符串形式绕过解析。
- 正确写法是:
@supports (color: oklch(0% 0 0)) { ... }或@supports (background: color-mix(in srgb, red, blue)) { ... } - 检测
oklch()比检测color-mix()更稳——前者是基础色函数,后者依赖混合引擎,兼容性梯度更陡 - 如果同时要用
color-mix()和oklch(),优先按oklch分组,再在内部嵌套color-mix规则,避免多层嵌套失效
prefers-color-scheme 和 color-scheme 配合系统色的坑
设了 color-scheme: light dark 并不等于浏览器会自动把 Canvas、input、button 的边框/阴影换成对应主题色——它只影响表单控件的**默认渲染逻辑**,而自定义背景、文字色仍需手动适配。
-
prefers-color-scheme: dark查询在 Windows + Chrome 115 之前版本可能返回空值,建议加兜底:@media (prefers-color-scheme: no-preference) { :root { --text: #333; } } - 系统深色模式下,
Canvas的默认背景是黑色,但若你设了background: Canvas,Safari 会把它当白色处理,结果文字看不见——得用background: CanvasText反推 - 别在
:root里直接用color-scheme做变量开关,它不触发 CSS 变量重计算;改用媒体查询包裹--primary: ...声明
HEX/RGB 与 oklch() 混用时的亮度错位
把设计稿给的 #4a6fa5 直接替换成 oklch(60% 0.18 250) 看起来差不多,但在深色背景下,oklch 的 L 值是感知亮度,而 HEX 的灰度是线性计算,实际可读性差一截——尤其小字号文本。
- 转换时别信在线工具一键结果,用
oklch(from #4a6fa5 l c h)语法让浏览器自己算,比预设值可靠 - 同一组件中混用
rgb()和oklch()会导致 color interpolation 异常:CSS 动画过渡时,Chrome 会强制转成 sRGB 插值,Safari 可能卡在起点 - 深色模式下,
oklch(30% ...)文字容易发灰,实测 L 值低于 35% 就需加描边或提高对比度,别硬撑
最麻烦的不是写法,是不同浏览器对「同个色彩函数」的解析粒度差异——比如 Safari 把 oklch(0.5 0.2 120) 当非法(少写了 %),而 Chrome 放行。这种细节只能靠真实设备+DevTools 的 computed 面板逐个核验。
前端入门到VUE实战笔记:立即使用
在学习笔记中,你将探索 前端 的入门与实战技巧!











