OKLCH的L值直接对应人眼感知明度，因基于CIE 2002校正而非RGB数学平均，故调L可线性控深浅、不偏色、不发灰、不跳变，且L、C、h三通道严格解耦；但L必须带%单位（如60%），否则整条声明静默失效。
OKLCH 的 L（亮度）值直接对应人眼感知明度，调 L 就能线性控制深浅，不偏色、不发灰、不跳变——这才是它适合明暗主题的根本原因。
OKLCH 的 L 值不是数学平均，而是 CIE 2002 感知校正结果
你在 HSL 里把 l 从 50% 调到 60%，视觉上可能 barely notice；调到 90% 却突然刺眼。这不是你的错，是 HSL 的 l 基于 RGB 立方体均分，和人眼响应完全脱钩。OKLCH 的 L 则不同：
-
L在 0%–100% 区间内，ΔL = 10 的明度变化，在人眼看来基本一致（尤其在 20%–80% 中段） - 同一
L值下，红/绿/蓝文字在白底上的可读性落差大幅收窄，WCAG 对比度更可控 - 深色模式切换时，只需改一个数字：
oklch(62% 0.28 258.5)→oklch(38% 0.28 258.5)，背景与文字的明暗关系平滑过渡，不会出现“某段突然看不清”
调 L 不会意外改变色相或彩度，避免 HSL 式断层
HSL 调明度常伴随色相漂移：比如 hsl(240, 100%, 50%)（标准蓝）调亮到 hsl(240, 100%, 90%)，实际渲染偏紫；调暗到 hsl(240, 100%, 10%) 又迅速发灰发黑。OKLCH 没这个问题：
-
L、C、h三通道解耦严格，只动L，C和h完全锁定 - 蓝、绿、橙等高饱和色在低
L下仍保持“本色感”，不会塌陷成灰紫色或棕褐色 - 禁用态设计可安全降
C（彩度）而不碰L，避免文字在浅底上因L过低而消失
必须写对单位和降级结构，否则 OKLCH 比 HEX 更容易静默失效
OKLCH 不报错、不警告，写错就直接跳过整条声明——这是它在明暗主题中出问题最隐蔽的原因：
立即学习“前端免费学习笔记（深入）”；
-
L必须带%（如60%），写成60或0.6在 Safari 17.4+ 以下全无效 -
C必须是无单位小数（如0.28），写成28%或28会被 Chrome 112+ 拒绝 -
h后不能加deg（如258.5deg），Safari 16.x 和部分安卓 WebView 会解析失败 - 降级色必须写在
@supports块**外部且上方**，顺序颠倒或漏掉 fallback，旧浏览器可能渲染为透明或默认黑
真正难的不是“怎么用 OKLCH”，而是确保它在所有目标环境里都按预期生效——尤其是当它被嵌入 light-dark() 或用于 CSS 变量推导时，一处单位错误，整个主题链就断了。
