OKLCH 的 L 值天生保证感知亮度一致，因其基于 CIE 2002 色貌模型校正；HSL 的 L 是 RGB 极值平均，视觉失真大；L 为无量纲感知标度（0=黑，1=白），单位错误或混用色彩空间将导致失效。
OKLCH 的 L 值天生就为感知亮度一致而设计，只要不写错单位、不混用色彩空间，同一 L 值下所有色相在人眼看来明暗几乎一致——这不是需要“努力保持”的结果，而是 OKLCH 空间本身的建模前提。
为什么 OKLCH 的 L=60% 在红/绿/蓝下看起来一样亮
HSL 的 L 是 RGB 三通道极值的算术平均，数学干净但视觉失真：实测 hsl(0, 100%, 50%)（纯红）CIE Y 亮度约 0.21，而 hsl(120, 100%, 50%)（纯绿）约 0.72，差三倍；OKLCH 的 L 来自 OKLab 空间，经 CIE 2002 色貌模型校正，oklch(60% 0.28 0) 和 oklch(60% 0.28 120) 在 OLED 和 LCD 屏上肉眼比对，明暗落差极小。
-
L不是“RGB 亮度百分比”，它是无量纲感知标度（0 = 黑，1 = 白），不能直接套用 HSL 的数值 - 品牌色从 HSL 转 OKLCH 必须用专业转换器重采样，比如
hsl(240, 100%, 50%)≈oklch(0.54 0.32 240)，而非简单改写oklch(50% 0.28 240) - 实测中，L 在 15%–92% 区间最稳定；低于 15% 高彩度蓝/绿易塌成黑灰，高于 92% 易泛白刺眼
写错单位会导致“一致”彻底消失
浏览器不报错，也不降级，它直接跳过整条声明——你看到的不是偏色，而是颜色“突然没了”：文字继承父级色、背景透明、按钮不可见。
-
oklch(60 0.28 258.5)❌ ——L缺 %，Chrome 112+ / Safari 17.4+ 拒斥 -
oklch(60% 28% 258.5)❌ ——C必须是无单位小数（0.28），28%解析失败 -
oklch(60% 0.28 258.5deg)❌ ——H后加deg在 Safari 16.x 和部分安卓 WebView 中崩溃 - 安全写法只有两种：
oklch(60% 0.28 258.5)（全兼容），或oklch(0.6 0.28 258.5)（仅新浏览器，且H小数位建议 ≤1）
@supports 检测失效会让 fallback 彻底失控
OKLCH 不支持时，浏览器静默忽略整行 CSS。如果 @supports 写错位置或值，UI 可能直接回退到透明或继承色，而不是你写的十六进制 fallback。
立即学习“前端免费学习笔记（深入）”；
- 降级色必须写在
@supports块**外部且上方**：background-color: #2563eb;→ 再写@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari 17.4+ 也返回 false） - 绝不能用
@supports not—— 安卓 WebView 解析失败，整块规则被丢弃 - 别用
oklab()替代检测——所有主流浏览器目前都返回 false
渐变和 transition 中混用色彩空间会破坏一致性
哪怕你定义了 --primary: oklch(62% 0.28 258.5)，只要 hover 状态用了 hsl() 或 rgb()，浏览器就会 fallback 到 sRGB 插值，出现“先灰一下再显色”的断裂。
- 深色模式下的
:hover、:active、:disabled全部要用oklch()变体，例如oklch(35% 0.28 258.5) - 渐变跨色相 >180°（如 350°→10°）时，必须手动拆段：
linear-gradient(oklch(0.7 0.25 350), oklch(0.7 0.25 0), oklch(0.7 0.25 10)) - 所有节点必须统一用
oklch()，混用rgb()或hsl()会让插值 fallback 到 sRGB，失去感知均匀性
最容易被忽略的是：OKLCH 的 L 是感知标度，不是线性光值，也不能直接套用 HSL 的 L 数值；更隐蔽的风险是，不同显示器默认白点（D50 vs D65）未统一时，同一段 oklch() 在 MacBook Pro 和 Dell 显示器上会明显漂移——这已经不是 CSS 写法问题，而是整个颜色工作流要对齐白点与色域。
