为什么我开始从 RGB 转向 OKLCH —— 颜色处理的新阶段
在做自己的项目时，我逐渐发现一个问题：
颜色越写越乱、越调越脏，很多看似简单的调色逻辑在实际效果上完全不符合预期。
比如：
• 明明只是想调亮一点，但 RGB/HSL 调完后颜色不是变灰就是变艳；
• 做渐变时颜色中途莫名其妙发暗；
• 图表配色在亮色主题和暗色主题下反差不一致；
• 在宽色域（如 P3）设备上，颜色表现和预期差得更远。
这些都指向同一个底层原因：
RGB（甚至 HSL/HSV）并不是一个符合人眼感知的色彩空间。
于是我开始把新的颜色计算逻辑逐步迁移到 OKLCH —— 一个感知均匀、现代化、已被浏览器原生支持的色彩空间。
这篇文章来分享我为什么做这个选择，也希望给你在项目色彩处理上的参考。
一、RGB / HSL 在实际开发中有哪些明显痛点？
- RGB 不是为调色设计的
RGB 是硬件色彩空间，核心目的是给屏幕发光，不是为了“符合人眼感知”。
所以你在 RGB 里调亮度，实际上是同时改三个通道，结果往往是“变亮但不自然”。
- HSL/HSV 看似更直观，但本质还是数学假设
HSL 的亮度是一个简单公式：
L = (max + min) / 2
这与人眼的亮暗感受毫无关系。
所以它经常出现：
• 提亮颜色 → 变灰
• 调饱和度 → 色相漂移
• 淡色系 → 明显“脏”
前端工程师、设计师乃至最近的 AI 图像后处理都会遇到这类问题。
⸻
二、为什么 OKLCH 是更适合现代开发的替代方案？
OKLCH 属于 OKLab 色彩模型的极简表示形式，结构非常简单：
• O：感知亮度
• K：色度（饱和度）
• LCH：和 CIELAB 类似的极坐标表示
它的关键价值可以用一句话总结：
OKLCH 更接近人眼真实的颜色感知，是为现代宽色域、高精度显示时代而设计的。
⸻
三、实际使用中的 5 个核心优势
- 调色结果更“像人眼认知”
在 OKLCH：
• 调亮 → 真的变亮，不变灰
• 调饱和度 → 不会突然偏色
• 改色相 → 渐变更自然、平滑
只要你写过配色算法，就会立刻感觉到这点的巨大差异。
⸻
- 渐变、插值更自然
RGB 做渐变常常中间变脏、发黑；
HSL 做渐变色相容易发生折返、跳跃。
OKLCH 解决了这些：
• 渐变更线性更均匀
• 不会突然暗掉
• 更接近真实光学过渡
这点在图表、数据可视化、背景渐变中非常实用。
⸻
- 在宽色域（P3 / Rec.2020）下表现稳定
很多新设备（Mac、iPhone、现代安卓机）已经进入了 P3 时代，RGB/HSL 的效果在宽色域中更不稳定。
OKLCH 是为这类显示技术设计的：
• 高饱和区域不塌陷
• 色彩更加一致
• HDR 适配更稳定
对未来兼容性非常友好。
⸻
- CSS 已经原生支持，迁移成本极低
现在浏览器直接支持：
color: oklch(75% 0.15 240);
不需要 polyfill，也不需要额外库。
迁移甚至可以按需局部替换，成本几乎为零。
⸻
- 更适合自动化配色、可视化、主题系统
如果你的项目涉及：
• 自动生成颜色
• 数据可视化（色板、热力图）
• 深浅主题适配
• 色彩算法
• 图像后处理
OKLCH 让这些变得更简单且结果更稳定。
举个例子：
颜色对比度（contrast）可以直接依赖 OKLab 的亮度计算，比 WCAG 的相对亮度公式更准确，也更符合人眼实际观感。
⸻
四、我在自己的项目中是如何使用 OKLCH 的？
我的做法是 从局部渐进迁移：
1. 先从需要自动计算的颜色入手（错误提示色、图表颜色、背景色等）
2. 再把主题色、渐变色统一写成 OKLCH
3. 最后再做一些视觉微调，确保在亮/暗主题都呈现一致对比度
这种方式不需要一次性重构，几乎没有成本压力。
⸻
五、未来为什么需要 OKLCH？
一句话：
未来的显示设备越来越宽色域、越来越精细，RGB/HSL 已经无法满足现代视觉需求。
随着 P3 / HDR 成为主流，颜色系统的基础越靠近视觉生理模型，效果越稳定。
OKLCH 现在能做的事，RGB/HSL 越来越做不到。
⸻
六、总结：为什么值得迁移？
有以下几点
• 提高颜色质量的成本极低
• 代码更清晰，更接近“亮度/饱和度/色相”的真实含义
• 渐变、配色、可视化效果更自然
• 兼容性好、未来可扩展
• 对项目整体视觉质量有巨大提升
对我来说，迁移到 OKLCH 是一种 小投入、高收益 的技术决策。