HWB和OKLCH解决不同问题：HWB专于同色系明暗调控，通过白度/黑度直观控制明暗变体且色相稳定；OKLCH则实现L/C/H三通道解耦，确保调亮度不偏色、调彩度不变亮、调色相不失饱和，适用于感知均匀调色与无障碍设计。
HWB 和 OKLCH 解决的是完全不同的问题，不是“二选一”，而是“各干各的”——用错场景，再新也没用。
HWB 适合快速生成同色系明暗变体
HWB 的设计目标很明确：让设计师和前端能像调颜料一样控制颜色——“在纯色基础上加多少白、加多少黑”。比如 hwb(240 80% 5%) 直观表达“蓝底 + 80% 白 + 5% 黑”，结果就是柔和浅蓝背景；而等效的 hsl(240 20% 90%) 需要反复试，还容易发灰或偏青。
- 白度/黑度变化时，色相稳定性明显优于 HSL
- 不支持 alpha，
hwb(0 0% 0% / 0.5)是无效语法 - 白+黑之和不能超过 100%，否则整条声明被静默忽略（Safari 可能渲染为透明）
- 旧版浏览器兼容性差：Chrome
OKLCH 是为感知一致性与无障碍而生
OKLCH 不是来替代 HSL 的“更好写法”，它是把人眼怎么感知亮度这件事，硬编码进 CSS 里。同一 L 值（如 60%）在红、绿、蓝、紫下真正看起来一样亮——这不是体验优化，是深色模式、禁用态、文字可读性的工程底线。
-
L必须带%单位：oklch(60% 0.28 258.5)✅，oklch(60 0.28 258.5)❌（所有浏览器静默跳过整行） - 移动端高 DPI/P3 屏上，
hsl(240, 100%, 50%)实测亮度波动可达 40%，而oklch(54% 0.32 240)更稳定 - 深色模式切换只动
L（如62% → 38%），蓝调不发紫；禁用态只降C（如0.28 → 0.12），避免对比度断崖下跌 - 渐变中色相差超 180°（如
350° → 10°）必须手动拆段，否则中间出现灰紫色带
@supports 降级结构一错，UI 就全黑或全透明
OKLCH 不报错，只静默丢弃整条声明。很多人把 fallback 写在 @supports 块里，或者检测值漏掉 %，结果用户看到的是继承色或透明——尤其安卓 WebView 对 @supports not 有解析 bug，整块规则直接消失。
立即学习“前端免费学习笔记（深入）”；
- 降级色必须写在
@supports块外部且上方：background-color: #2563eb;→ 再跟@supports (color: oklch(0% 0 0)) { ... } - 检测值必须带单位：
@supports (color: oklch(0% 0 0))✅，@supports (color: oklch(0 0 0))❌（Safari/Chrome/Firefox 全部返回 false） - 别用
oklab()检测——目前所有主流浏览器都返回 false
最常被忽略的不是“该不该用”，而是单位细节和 fallback 顺序：错一个 %，整行失效；降级位置错一层，UI 在旧设备上直接不可用。
