rgb() 和 hsl() 的空格语法是 CSS Color Level 4 正式标准，非风格偏好；逗号写法为仅兼容的 legacy syntax，现代浏览器优先解析空格+斜杠形式（如 rgb(255 0 0 / 0.5)），缺斜杠或误用逗号将导致静默失效。
rgb() 和 hsl() 的空格语法不是“更简洁”，而是解析规则变了
浏览器现在用两套规则并行解析颜色函数：逗号写法 rgb(255, 0, 0) 被标记为 legacy syntax，仅作向后兼容；空格+斜杠写法 rgb(255 0 0 / 0.5) 才是 CSS Color Level 4 正式定义的现代语法。这不是风格偏好，而是解析器优先匹配空格形式——Chrome 117+、Firefox 119+、Safari 17.4 都已启用该行为。
关键差异在于结构语义：
-
255 0 0是三个独立参数，空格是**强制分隔符**，不是可选空白 -
/ 0.5是命名参数（alpha channel），斜杠是语法必需前缀，不能省略或替换成逗号 -
rgb(255 0 0 0.5)是非法的：第四个值无意义，会被忽略
为什么逗号写法在构建流程里容易静默失败
很多构建工具（PostCSS、esbuild、Tailwind JIT）会在压缩阶段抹掉冗余空格，把 rgb(255 0 0) 变成 rgb(255 0 0)（少一个空格），而 Safari 17.4 对这种紧凑空格格式支持不全，el.style.color = 'rgb(255 0 0)' 在 JS 中直接被忽略，也不报错。
更隐蔽的问题出在预处理器和变量插值中：
立即学习“前端免费学习笔记（深入）”；
- Sass 默认输出逗号版，
rgb($r, $g, $b)无法生成合法的空格语法 - 插值写成
rgb(#{$r} #{$g} #{$b} / #{$a})时，若$a为空，会产出rgb(255 0 0 / )→ 解析失败 - PostCSS 插件如
postcss-color-function若版本低于 6.x，会把空格语法自动转回逗号，导致上线后颜色偏差
@supports 检测 oklch() 或 rgb() 空格语法时最容易漏掉的细节
检测必须用带单位的最小有效值，否则所有浏览器都返回 false：
- ✅ 正确：
@supports (color: oklch(0% 0 0))、@supports (color: rgb(0 0 0 / 0)) - ❌ 错误：
@supports (color: oklch(0 0 0))（缺%）、@supports (color: rgb(0, 0, 0))（逗号写法不触发新解析器） - fallback 必须写在
@supports块外部且上方，否则降级色不会生效
别用 @supports not：安卓 WebView 存在解析 bug；也别用 oklab() 检测，目前所有主流浏览器都返回 false。
oklch() 的 L 值不能照搬 hsl() 的 L，这是感知模型的根本差异
hsl(0, 100%, 50%)（纯红）和 hsl(120, 100%, 50%)（纯绿）在 CIE Y 明度上差三倍，人眼看着亮度完全不同；但 oklch(0.5 0.32 0) 和 oklch(0.5 0.32 120) 才真正视觉等亮。
所以迁移时不能简单替换：
-
hsl(240, 100%, 50%)≈oklch(0.54 0.32 240)，不是oklch(0.5 0.32 240) -
oklch()的 L 必须带单位：oklch(50% 0.28 258.5)✅，oklch(0.5 0.28 258.5)仅高版本支持，oklch(50 0.28 258.5)（缺 %）会被所有浏览器静默忽略 - DevTools 的 computed 样式永远只显示降级后的 sRGB 十六进制值，真值只能靠肉眼比对 + 控制
C ≤ 0.28防止色域漂移
真正麻烦的不是写法转换，而是团队里有人手写逗号、有人用工具输出空格，再经压缩器混淆，最终线上颜色只在深色模式或高对比度下才暴露偏差——它不报错，只悄悄变色。
