color-mix()不能取代SCSS的mix()，因二者本质不同：mix()是编译期sRGB线性插值，输出确定静态色值；color-mix()是运行时计算，需指定色彩空间，in srgb易致明度塌陷，in oklch更符合人眼感知但兼容性有限且必须提供fallback。
color-mix() 不是加深函数，它根本不是 mix() 的替代品
直接说结论：color-mix() 不能取代 SCSS 的 mix()，因为两者解决的是完全不同的问题。你拿它去“代替加深”或“模拟 Sass 混合”，大概率会得到视觉上更脏、更不可控的结果，尤其在深色+亮色混合时。
SCSS 的 mix($a, $b, 70%) 是在 sRGB 下对 R/G/B 通道做线性插值，结果可预测、可复现，且编译后就是静态值（比如 #3a5f8c），不依赖浏览器支持；而 color-mix() 是运行时计算，必须指定色彩空间，且默认的 in srgb 混合常导致明度塌陷——比如 color-mix(in srgb, black 50%, #ff6b35 50%) 得到的不是中间调橙灰，而是偏暗发浊的棕褐。
-
mix()输出确定值，适合配色系统固化、设计令牌冻结的场景 -
color-mix()输出动态值，适合响应用户偏好（如prefers-color-scheme）、配合 CSS 变量实时推导悬停/禁用态 - 想“加深一个品牌色”，
darken($color, 15%)或change-color($color, $lightness: -15%)更直接；用color-mix(in lch, $color 80%, black 20%)虽可行，但需验证 LCH 插值是否真让“看起来更暗”，而非只是数值变小
真正能“原生实现 mix”效果的，是 OKLCH + color-mix()
如果你坚持要用原生 CSS 实现接近 mix() 的视觉一致性，别碰 in srgb，改用 in oklch。OKLCH 是当前唯一被 Chrome/Firefox/Safari 主流支持的感知均匀空间，它的 L（亮度）通道与人眼感受基本线性对应，C（彩度）和 H（色相）插值也更自然。
例如，混合 #007bff（蓝色）和 #28a745（绿色）：
立即学习“前端免费学习笔记（深入）”；
color-mix(in srgb, #007bff 50%, #28a745 50%); /* 浑浊黄绿，偏灰 */ color-mix(in oklch, #007bff 50%, #28a745 50%); /* 鲜亮、通透的青绿色 */
注意：Firefox 119+ 才原生支持 oklch() 和 color-mix(in oklch, ...)，且需开启 layout.css.color-mix.enabled 标志（默认未开）；Chrome 111+ 和 Safari 16.4+ 已默认启用。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- OKLCH 混合不保证 RGB 值居中，但保证“看起来”是中间调
- 它无法还原 SCSS 中
mix(#000, #fff, 20%)这种精确灰阶控制——因为 OKLCH 的黑/白定义与 sRGB 不同 - 若输入色本身来自 sRGB 十六进制，先转成 OKLCH 再混合，比硬套
in oklch更稳妥（可用在线工具或 PostCSS 插件预处理）
@supports + fallback 是硬性要求，不是可选项
写 color-mix() 不加降级，等于主动放弃 Firefox 用户和所有旧版 Edge/Chrome。目前没有 PostCSS 插件能准确模拟 OKLCH 混合逻辑，@supports 是唯一可靠手段。
正确写法必须是：
button {
background-color: #007bff;
background-color: color-mix(in oklch, #007bff 85%, white 15%);
}而不是反过来，否则不支持的浏览器会直接丢弃整条声明。
-
@supports (color: color-mix(in srgb, red, blue))可检测基础支持，但无法区分oklch是否可用 - 不要把
color-mix()塞进background复合属性里，容易因解析失败导致整个背景失效 - 如果项目仍需兼容 IE 或 Android WebView
color-mix() 动态性的代价：它无法读取 currentcolor 或未解析变量
这是最容易踩的坑：你以为 color-mix(in oklch, currentcolor 60%, white 40%) 能让文字随父级颜色自动变浅，结果发现它根本不工作——currentcolor 在 color-mix 计算阶段尚未解析，浏览器直接静默忽略整条声明。
同样，var(--primary) 若未在 :root 或作用域内明确定义为有效颜色值（比如写成 --primary: 120;），color-mix() 也会失败，且无任何错误提示。
- 必须确保传入
color-mix()的每个颜色都是已知、静态、可解析的（十六进制、命名色、rgb()等） - 想用变量驱动？得先用
@property注册为color类型，并显式声明语法：@property --primary { syntax: "<color>"; inherits: false; initial-value: #007bff; } - JS 动态改权重？只能走内联样式：
el.style.backgroundColor = "color-mix(in oklch, #007bff " + weight + "%, white " + (100-weight) + "%)"，但注意字符串拼接必须带%单位
真正难的从来不是写对语法，而是判断什么时候该用 color-mix()，什么时候该老老实实用 mix() 编译出确定值。前者适合“活”的色彩系统，后者适合“稳”的设计交付。混用或强替，只会让颜色更不可控。
