Chrome 111+原生支持OKLCH，Safari 16.4和Firefox 115默认不支持；生产环境需用postcss-oklab转为rgb()，它保守映射并clamped超sRGB值，避免NaN或渲染异常。
OKLCH颜色在Chrome 111+能用，但Safari 16.4、Firefox 115默认不支持
OKLCH是W3C新标准颜色空间，视觉均匀、色域更广，但浏览器支持极不均衡。截至2024年中，仅Chrome 111+（含Edge）原生支持oklch()函数；Safari 16.4未启用，Firefox 115需手动开启layout.css.color-functional-notation.enabled标志——生产环境不能依赖。直接写color: oklch(0.8 0.2 30);在多数用户设备上会退为color: transparent或触发CSS解析失败，导致文本不可见。
PostCSS插件postcss-oklab可转OKLCH为OKLAB再降级为sRGB
目前最稳妥的自动化方案是用postcss-oklab（注意名字不含“ch”），它把oklch()先转成oklab()，再通过固定白点（D65）和逆向变换，输出rgb()或hsl()。它不模拟色域裁剪，而是做保守映射：超出sRGB范围的值会被clamped，避免渲染异常。
安装与基础配置：
npm install postcss-oklab --save-dev
在postcss.config.js中启用：
立即学习“前端免费学习笔记（深入）”；
module.exports = {
plugins: [
require('postcss-oklab')({
// 默认转为 rgb()，也可设为 'hsl'
outputFormat: 'rgb',
// 是否保留原始注释（调试用）
preserveComments: false
})
]
}注意：postcss-oklab不处理color-mix()或color-contrast()等新函数，只管oklch()和oklab()字面量。
转换后rgb()值可能失真，尤其高饱和蓝/绿区域
OKLCH的c（色度）在sRGB中无直接对应，转换本质是近似投影。实测发现：
-
oklch(0.5 0.3 240)（偏紫蓝）→rgb(102, 128, 255)，视觉上明显发灰 -
oklch(0.9 0.4 120)（鲜绿）→rgb(180, 255, 160)，饱和度下降约15% - 所有转换结果都经过
Math.round()取整，不会出现小数位rgb(123.4, 56.7, 201.2)
若设计稿对特定色块精度要求高（如品牌主色），建议人工校验转换后色值，必要时用/* postcss-ignore */跳过该行，手写兼容色。
不要用postcss-color-function替代
这个插件名义上支持oklch()，但实际行为不稳定：
- 它依赖
colord库，而colord对OKLCH的逆变换有精度缺陷，某些l=0.1, c=0.05组合会产出rgb(NaN, NaN, NaN) - 在PostCSS 8.4+下常报
Cannot read property 'replace' of undefined，因它错误解析带空格的oklch( 0.5 0.2 30 ) - 不支持
oklch()中的百分比写法（如c用20%而非0.2），而postcss-oklab两者都接受
线上项目已踩过坑：用postcss-color-function后，构建时无报错，但部分按钮文字在iOS Safari上变成黑色（因NaN被当0处理）。换回postcss-oklab即恢复。
OKLCH的真正落地不在编译时转换，而在浏览器原生支持普及之后；现在所有“兼容方案”本质都是妥协——关键不是转得快，是转得稳、错得明。
