rgb(100%, 0%, 0%) 更易感知各通道相对强度比例，但有严格限制：三值须全为0%–100%百分比、不可混用、不可省略%；整数在脚本、动画、调试中更可靠；现代方案倾向lch()或color-mix()。
rgb(100%, 0%, 0%) 这种写法真比 rgb(255, 0, 0) 更易理解色阶？
不是“更容易理解色阶”，而是更易感知各通道的**相对强度比例**——尤其在需要与设计系统对齐、做渐变微调或跨颜色空间映射时。百分比把数值锚定在“满值即100%”的认知框架里，避免了 255 这个魔数带来的心理干扰。
-
rgb(100%, 0%, 0%)直观表达“红通道全开，绿蓝彻底关闭”，而rgb(255, 0, 0)需要脑内多转一道“255 是最大值”的映射 - 当设计稿要求“降低红色饱和度至 70%”，写成
rgb(70%, 0%, 0%)比换算成rgb(178, 0, 0)更少出错、更贴近协作语言 - 但注意：
rgb(100%, 0%, 0%)和rgb(255, 0, 0)渲染结果完全一致，浏览器内部都转为线性 sRGB 值，它只是书写层的语义增强
rgb() 百分比写法有哪些硬性限制？
它看着自由，其实约束很严，稍不注意整条声明就被浏览器忽略。
- 三个参数必须**全部用百分比**，混用
rgb(100%, 128, 0)或rgb(100%, 50%, 0)均非法 - 百分比范围只能是
0%–100%，写rgb(150%, 0%, 0%)不会溢出变亮，而是整个声明失效 - 不能省略百分号：
rgb(100, 0, 0)是合法整数写法，但rgb(100%, 0, 0%)因混用被拒绝 - VS Code 等编辑器对纯百分比写法支持较弱，颜色小 preview 可能不触发，不如
hsl()可视化友好
什么时候该坚持用整数，而不是百分比？
脚本生成、算法映射、性能敏感场景下，整数仍是首选。
- JS 动态设置样式时：
el.style.color = `rgb(${r}, ${g}, ${b})`比拼接百分比字符串更轻量，也避开了引号和 % 转义问题 - 颜色插值动画（如
@keyframes）中，浏览器对整数插值优化更成熟；百分比写法虽合法，但某些旧版 Chromium 对rgb(100%, 0%, 0%) → rgb(0%, 100%, 0%)的过渡计算偶有偏差 - 十六进制与 RGB 整数互转是无损的（
#ff6347⇄rgb(255, 99, 71)），而百分比无法直接对应两位十六进制，调试时反而增加换算成本
现代 CSS 中，百分比 RGB 其实正在被边缘化
真正值得关注的不是百分比本身，而是它所指向的更高阶需求：**可读性 + 可计算性 + 跨空间一致性**。这些现在由新语法更好承载。
立即学习“前端免费学习笔记（深入）”；
- 新式空格分隔写法
rgb(255 0 0 / 0.5)已取代rgba()，斜杠后的 alpha 支持/ 50%，这才是百分比该出现的地方 - Lab/LCH 等新色彩空间原生使用百分比表示明度/彩度（如
lch(70% 60 250)），它们才是“感知均匀”的百分比，而rgb(70%, 0%, 0%)仍卡在非线性 sRGB 里 - 如果你真想靠百分比控制“视觉亮度阶梯”，别折腾 rgb%，改用
color-mix(in lch, red, white 70%)或直接定义--lightness: 70%配合hsl(var(--hue), var(--sat), calc(var(--lightness) * 1%))
实际项目里，rgb(100%, 0%, 0%) 这类写法只适合小范围、人手维护的配色变量；一旦涉及计算、动画或跨团队协作，它的“直观”优势很快会被兼容性、工具链支持和语义混淆反噬。
