OKLCH在Tailwind v4中默认启用但旧浏览器不支持，必须用@csstools/postcss-oklab-function插件生成多层fallback（如rgb→display-p3→oklch），且preserve:true需显式开启，否则现代色域优势丢失。
OKLCH 颜色在 Tailwind v4 中是默认启用的，但直接写 oklch(0.62 0.15 274) 并不能保证所有用户看到一致效果——旧版 Safari、Firefox ≤111、部分安卓 WebView 会完全忽略该声明，导致背景/文字变透明或回退到初始色。关键不是“能不能用”，而是“怎么让不支持的浏览器有合理 fallback”。
为什么 @theme 里写 OKLCH 不够用
Tailwind v4 的 @theme 块（如 --color-primary: oklch(0.62 0.15 274);）只定义 CSS 变量，不生成降级色值。浏览器读到不认识的 oklch() 就跳过整条声明，变量值为空，后续 var(--color-primary) 会 fallback 到继承值或初始值（比如 currentColor 或 transparent），而不是你期望的 RGB/P3 备用色。
必须让构建阶段主动插入多层 color 声明，像这样：
.btn {
background-color: rgb(100, 120, 200);
background-color: color(display-p3 0.32 0.41 0.78);
background-color: oklch(0.68 0.19 260);
}
这需要 PostCSS 在编译时介入，而非靠运行时 CSS 变量。
立即学习“前端免费学习笔记（深入）”；
必须加 @csstools/postcss-oklab-function 插件
这个插件不是可选优化，而是兼容性刚需。它会在构建时扫描所有 oklch()、oklab() 调用，并自动注入前缀色值。但要注意几个硬性条件：
-
preserve: true必须显式开启，否则插件会把oklch()全替换成rgb()，失去现代浏览器的色域优势 - 它只处理 CSS 文件里的字面量，不处理 JS 中动态拼接的字符串（如
style={{ backgroundColor: `oklch(${l} ${c} ${h})` }}） - 必须放在
@tailwindcss/postcss之后，否则 Tailwind 生成的工具类还没出来，插件就扫不到 - Next.js 用户注意：若用 App Router + Turbopack，需确认其已启用 PostCSS（Turbopack 默认禁用）
不要依赖 color-mix() 做 OKLCH 基础色生成
color-mix(in oklch, red, white) 看起来很美，但实际踩坑严重：
- Chrome 125+、Safari 18.4+ 才稳定支持
in oklch，Firefox 目前仍只支持in srgb和in hsl - 当 baseColor 是
oklch()字符串时，color-mix()在不支持的浏览器中会直接计算失败，整条声明被丢弃 - 它无法触发插件的 fallback 注入逻辑——PostCSS 插件只识别顶层
oklch()函数调用，不解析函数参数里的颜色字面量 - 真正安全的做法：所有基础色用插件生成的多层声明；变体色（如 hover、disabled）用
color-mix(in srgb, ...)或opacity控制
暗色模式下 OKLCH 的双重 fallback 更复杂
如果你在 @theme 里写了：
@theme {
--color-bg: oklch(0.95 0.01 240);
--color-bg-dark: oklch(0.12 0.03 240);
}
那么 dark:bg-[--color-bg-dark] 这类写法在旧浏览器中会失效两次：一是 oklch() 被跳过，二是 var(--color-bg-dark) 为空。正确姿势是：
- 把暗色模式的 OKLCH 也交给插件处理，确保生成带 fallback 的独立类（如
dark:bg-dark-primary） - 避免在
dark:前缀后直接引用 CSS 变量，改用插件生成的原子类 - 检查 DevTools 的 Computed 面板，确认旧浏览器最终生效的是哪一层
background-color——优先级顺序是：最后一行 > 倒数第二行 > 第一行
最易被忽略的一点：OKLCH 的 fallback 不只是“加一行 rgb()”，而是要按渲染优先级严格排序，且每层都得是合法语法。少一个分号、多一个空格，整条链都会断裂。
