CSS Color Level 4 函数是解决配色失控的基础设施：color-mix()需显式指定色彩空间，oklch()实现感知均匀亮度控制，color-contrast()仅选最高达标对比度且需polyfill；rgb()新语法空格敏感，Safari支持不全，构建流程须严格校验。
color-mix()、oklch()、color-contrast() 这些函数不是“锦上添花”，而是解决真实配色失控问题的基础设施——当你需要让文字在动态背景上始终可读，或让一组按钮在深色/浅色模式下保持视觉重量一致，旧 CSS 颜色模型就直接失效。
rgb() 逗号写法在现代构建流程中会静默失败
Chrome 117+ 和 Firefox 119+ 已默认启用 CSS Color Level 4 解析器，它优先匹配 rgb(255 0 0)，而把 rgb(255, 0, 0) 当作 legacy fallback 处理。问题在于：很多构建工具（如 PostCSS、esbuild）压缩时会抹掉空格，把 rgb(255 0 0) 变成 rgb(255 0 0)（少一个空格），导致浏览器无法识别。
更麻烦的是 Safari 17.4 —— 它对 rgb(255 0 0) 支持不完整，但又不报错，el.style.color = 'rgb(255 0 0)' 在 JS 中直接被忽略。必须用 CSS.supports('color', 'rgb(0 0 0)') 检测后降级。
- 不要全局搜索替换逗号为空格：旧写法
rgb( 255 , 0 , 0 )是合法的，新语法要求参数间**仅一个空格且无环绕空白** - Sass 等预处理器默认输出逗号版，需改用插值：
rgb(#{$r} #{$g} #{$b})，或升级到支持 Level 4 的 color 模块 - CI/CD 流程里加一条检查：grep -r "rgb([^)]*,[^)]*)" src/ && echo "found legacy rgb"
oklch() 不是“更好看的 HSL”，而是亮度可控的工程必需品
HSL 的 lightness: 50% 对黄、蓝、红给出的视觉亮度天差地别；而 oklch(0.6 0.2 260) 的 L 值是感知均匀的——0.6 就是 0.6，不管色相怎么变，人眼感受到的明暗基本一致。
这意味着你能真正做「亮度锚定」：比如设计一套主题色，要求所有主色在深色模式下自动变亮、浅色模式下自动变暗，只需统一调整 L 值，不用为每种颜色单独调参。
立即学习“前端免费学习笔记（深入）”；
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
-
oklch()的L范围是 0–1，不是百分比；写成oklch(60% 0.2 260)会解析失败 - 灰色系必须用
oklch(L 0 H)构建，而不是gray()—— 后者在 Safari 中仍部分不可用 - 和
color-mix(in srgb, ...)混用时，若混入hsl()或rgba()，整个表达式会因语法不一致被丢弃
color-contrast() 的 fallback 机制常被误读
color-contrast(var(--bg), white, black, #333) 并不保证返回列表中第一个满足 WCAG AA 的颜色。它实际行为是：计算每个候选色与背景的对比度，选最高者——哪怕只有 2.1:1（刚好过 AA），而跳过对比度更高但未达 AA 的（如 3.8:1 但色差太大）。这不是 bug，是规范明确写的“highest contrast that meets minimum”。
更关键的是：该函数目前仅 Chrome Canary 和 Firefox Nightly 实验性支持，生产环境必须 polyfill。但 polyfill 无法复现原生函数的 contrast 计算精度（尤其在 display-p3 色域下）。
- 不要依赖
color-contrast()做核心可访问性保障，它应作为增强层存在 - polyfill 库如
color-contrast-polyfill会注入 JS 计算逻辑，但无法处理color-mix()输出的 OKLCH 值，需先转回 sRGB - 测试时务必用真实设备色域（非 sRGB 模拟），MacBook Pro 的 P3 屏幕会让很多基于 sRGB 的对比度计算失效
color-mix() 的 in 关键字决定色彩空间，不能省略
color-mix(in oklch, red 50%, blue 50%) 和 color-mix(in srgb, red 50%, blue 50%) 结果完全不同。前者混合的是感知均匀空间中的亮度与色度，后者是在非线性 sRGB 中做简单加权平均——后者容易产生灰浊、偏暗的中间色。
问题在于：如果你混用不同色彩空间的输入，比如 color-mix(in srgb, oklch(0.5 0.2 260) 50%, #ff0000 50%)，浏览器会尝试转换，但转换精度取决于当前渲染上下文，Safari 甚至直接拒绝解析。
- 所有
color-mix()必须显式声明in参数，省略即无效 - 同一行声明中，所有颜色值必须属于同一语义流：要么全用
oklch()+in oklch，要么全用srgb+ 传统函数 - PostCSS 插件如
postcss-color-mix目前不支持in oklch，需手写 fallback 或禁用压缩
oklch()”，而是当设计系统同时用到 color-mix(in oklch, ...)、color-contrast() 和动态 CSS 变量时，任何一个环节混入 legacy 颜色写法，整条颜色链就会在 Safari 或旧版 Chrome 中断裂——而且没有任何错误提示。 
