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 面板逐个核验。
