lab()函数在CSS滤镜中完全无效，因所有主流浏览器均未实现该函数，声明如drop-shadow(lab(50,20,-10))会被整个丢弃并降级为默认黑色阴影；而oklab()是目前唯一能在滤镜中稳定参与颜色计算的感知均匀空间函数，需严格遵循L为0–1小数、a/b为无量纲浮点数等写法规范。
因为 oklab() 在浏览器中能被真正解析并用于滤镜计算，而 lab() 函数根本不会生效——它连语法校验都通不过，更谈不上参与滤镜运算。
为什么 lab() 在 CSS 滤镜里完全无效
lab() 不是“不推荐”，是彻底不可用。截至 2026 年 6 月，所有主流浏览器（Chrome 112+、Firefox 121+、Safari 17.5、Edge 114+）均未实现该函数。声明如 filter: brightness(1.2) contrast(1.1) hue-rotate(45deg) invert(1) sepia(0.5) saturate(1.3) drop-shadow(0 2px 4px lab(50, 20, -10)) 中的 lab(50, 20, -10) 会被整个丢弃，drop-shadow 降级为默认黑色阴影（rgba(0,0,0,0.5)），且 DevTools 的 computed 样式里压根不会显示该值。
-
color: lab(50, 20, -10)已被证实静默失效，filter里嵌套同样无效 - PostCSS 插件（如
postcss-color-functional-notation）无法转译lab()，因无标准映射规则；它只处理oklab()和oklch() - Chrome 实验性 flag
#enable-web-platform-features已于 2025 年底移除，不再提供任何lab()支持入口
oklab() 在 filter 中的实际可用性
oklab() 是目前唯一能在 CSS 滤镜中稳定参与颜色计算的现代感知均匀空间函数。它被用于 color-mix()、color-contrast() 和部分实验性滤镜参数（如 Safari 17.5+ 的 color-adjust() 原型），但关键前提是写法绝对正确：
- L 必须是
0–1小数或0%–100%：oklab(0.5 0.2 -0.1)✅，oklab(50% 20 -10)❌（a/b 被当整数，超出合理范围，整条声明失效） - a/b 是无量纲浮点数，建议控制在
|a| ≤ 0.5、|b| ≤ 0.5内，否则 Chrome 开始降饱和、Safari 可能截断 - 不能混用白点：设计工具导出的 OKLab 默认 D65，与 CSS 渲染一致；若从 Lab 工具转 OKLab，必须确认已做 D50→D65 白点归一化，否则色偏明显
-
filter: drop-shadow(0 2px 4px oklab(0.3 0.15 -0.2))在支持环境中会真实渲染该 OKLab 色，而非 fallback 到 sRGB 近似值
oklab() 对滤镜链路的实质影响
它不改变滤镜执行顺序，但改变了中间色值的语义精度。例如在多层滤镜叠加时：filter: brightness(0.8) saturate(1.5) color-mix(in oklab, oklab(0.7 0.25 -0.1), oklab(0.3 0.05 0.15)); —— 此处的混合发生在 OKLab 空间，L、a、b 分量线性插值，视觉过渡平滑；若强行用 srgb 空间，同一操作会产生亮度塌陷和色相跳变。
立即学习“前端免费学习笔记（深入）”；
- OKLab 的欧几里得距离 ≈ 感知差异，意味着
color-mix()输出的颜色在人眼判断中更“可信” - 但注意：
oklab()本身不提升设备输出能力，它只是让浏览器在 sRGB 输出基准下，做出更符合人眼预期的中间计算 - 滤镜链中只要有一个环节用了
oklab()，整个链路就依赖其数值稳定性；若某步 fallback 失败（如误写单位），后续所有基于它的计算都会崩
真正容易被忽略的不是“怎么写”，而是“在哪写”：所有含 oklab() 的滤镜声明，必须配 @supports (filter: drop-shadow(oklab(0% 0 0))) 检测，且降级规则必须写在 @supports 块外部上方——否则安卓 WebView 会直接跳过整条规则，连 fallback 都不执行。
