rgb()数值缩放“不匀称”是因为sRGB通道经伽马压缩（γ≈2.4），等比缩放不等于视觉等距明度变化，暗部响应迟钝、亮部抢眼，且R/G/B对亮度贡献权重不同（G最高、B最低），导致偏色与失真。
因为浏览器对 rgb() 的解析和插值都在非线性 sRGB 空间进行，而人眼感知明度是近似线性的——数值等比缩放不等于视觉等距变亮或变暗。
rgb() 数值缩放为什么看起来“不匀称”
比如从 rgb(102, 153, 204)（中蓝）调亮到 rgb(153, 204, 255)，你等比放大了约 1.5 倍，但实际亮度（luminance）只提升了约 38%，且暗部变化更“迟钝”，亮部则“抢眼”。这是因为 sRGB 通道值经过伽马压缩（γ ≈ 2.4），rgb(0, 0, 0) 到 rgb(128, 128, 128) 这段数值跨度，在线性光空间里只占真实亮度的 ~22%，远低于 50%。
- 直接改 RGB 数值 = 在压缩后的坐标系里做算术，不是在物理光强或人眼感知维度上操作
- 同一数值差（如 R 从 100→120 和 200→220）在视觉上明度变化量完全不同
- 灰阶色（
R=G=B）相对好控，但一旦带色相，R/G/B 对明度贡献权重不同（G 权重最高，B 最低），纯数值缩放会轻微偏色
哪些场景下 rgb() 明度控制会明显失真
典型失真集中在三类高频使用场景：
-
按钮悬停变亮：用
background-color: rgb(74, 144, 226)→rgb(100, 170, 240)，结果不是“清爽提亮”，而是发白、饱和度下降、略带青灰感 -
深色主题衍生色：从
rgb(255, 255, 255)往下减，rgb(200, 200, 200)看起来已接近中灰，再往下几步就迅速沉入暗调，缺乏中间细腻梯度 -
@keyframes 颜色动画：比如
color: rgb(255, 0, 0)→rgb(255, 100, 0)，中间帧会出现不自然的棕橙色，因 G 通道线性插入时未补偿人眼对绿色更敏感的特性
替代方案不是“换函数”，而是换空间
想真正按感知控制明度，必须跳出 sRGB 数值思维：
立即学习“前端免费学习笔记（深入）”；
- 用
lighten()/darken()（Less/Sass）：底层转 HSL 后调L通道，语义清晰，但仅限预处理 - 用
hsl()+ CSS 变量：如--base-hsl: 210 70% 60%，再通过hsl(210, 70%, calc(60% + 10%))动态调整，比 RGB 更符合直觉 - 用
lch()或oklch()：写color: lch(60% 80 240)，直接操控L（亮度）、C（色度），L每+5% = 视觉等距变亮；但需 fallback 且 Safari/Chrome 版本要 ≥112/16.4 - 避免用
brightness()滤镜调明度：它作用于整个元素（含子内容），且是非线性叠加，易导致文字边缘泛白或对比度崩坏
真正难的不是选哪个 API，而是意识到：CSS 里所有基于 rgb()、#RRGGBB、hsl() 的颜色操作，默认都运行在非线性空间。只要没显式声明 in lch 或 in oklch，所谓“精确控制”，本质都是在拟合一条人眼并不买账的曲线。
