rgb、hex、hsl 本质是同一颜色模型的不同表达，rgb/hex 直接映射0–255三通道值，hex不区分大小写；hsl中色相为0–360纯数字，饱和度与亮度独立调控；alpha需按格式规范书写，颜色名仅为别名且不可微调。
RGB 和 HEX 本质是同一套数值，别被写法骗了
RGB(rgb(255, 99, 71)) 和 HEX(#ff6347) 都是直接映射到 0–255 的红绿蓝三通道值，只是表达形式不同。浏览器解析时会立刻把 #ff6347 拆成 255, 99, 71，和 RGB 写法完全等价。
容易踩的坑：
-
#fff是#ffffff的简写，但#abc≠#aabbcc—— 它确实等于#aabbcc，但很多人误以为要手动补位，其实浏览器自动做了；手写时别写成#a0b0c0还以为是简写 - RGB 函数里传小数（比如
rgb(0.8, 0.2, 0.1)）是无效的，必须是整数；CSS Color Module Level 4 才支持rgb(80% 20% 10%)这种百分比写法，旧版不认 - HEX 不区分大小写，
#FF6347和#ff6347效果一样，但团队协作时建议统一小写，避免 Git 里因大小写触发无意义变更
HSL 的“色相”不是角度单位，而是标准化的 0–360 数值
hsl(9, 100%, 64%) 里的 9 确实是角度，但它不是 CSS 中的 deg 单位，也不参与计算转换——它就是一个纯数字，范围固定为 0–360，超出会自动取模（hsl(369, ...) 等价于 hsl(9, ...)）。
为什么用 HSL 而不是 RGB？因为人对“更红一点”“再淡一点”的直觉操作，在 HSL 里对应的是单个参数调整：
立即学习“前端免费学习笔记（深入）”；
- 调色相（
h）：改颜色主调，比如从橙红（9）转橘黄（35），不用动另外两个值 - 调饱和度（
s）：控制灰度程度，0%就是纯灰，100%最鲜艳；注意这里不是“透明度”，alpha 是单独的hsla() - 调亮度（
l）：决定明暗，0%是黑，100%是白，50%才是该色相最“标准”的明度
常见错误：hsl(0, 0%, 0%) 是黑，hsl(0, 0%, 100%) 是白，但 hsl(0, 100%, 50%) 才是纯红——别把 l: 50% 当成“默认值”忽略
Alpha 通道写法不统一，老项目容易漏兼容
透明度在三种表示法中加法不同，且历史兼容性差异大：
- RGB 加 alpha：用
rgba(255, 99, 71, 0.5)，第四个参数是 0–1 小数；不能写rgb(255, 99, 71, 50%)，那是错的 - HEX 加 alpha：必须用 8 位写法，
#ff634780（后两位80是十六进制透明度，00=全透，ff=不透）；#ff6347本身没有 alpha，永远不透明 - HSL 加 alpha：用
hsla(9, 100%, 64%, 0.5)，和 rgba 规则一致；但注意，hsl(9, 100%, 64% / 0.5)是 Level 4 新语法，IE 和旧 Safari 不支持
性能影响很小，但写错会导致整个声明失效——比如在只支持 rgba 的环境里用了 hsl(... / 0.5)，那颜色会回退到浏览器默认（通常是黑或透明）
颜色名是别名，不是独立体系，慎用于关键样式
tomato、rebeccapurple 这些名字只是 #ff6347、#663399 的别名，CSS 规范里明确定义了 140 个标准名，没有更多。它们和 RGB/HEX/HSL 完全等价，但问题出在“不可控”：
- 无法微调：想让
tomato暗 5%，只能查出它是#ff6347再换算，不能直接darken(tomato, 5%)（那是 Sass 函数，原生 CSS 不行） - 可读性陷阱：
lightgray实际是#d3d3d3，而gray是#808080，前者反而更亮——名字和感知不一致 - 兼容性没问题，但构建工具（如 PostCSS）可能把颜色名转成 HEX，导致设计系统里“命名即意图”的假设落空
真正复杂的地方在于：HSL 的 l 值和人眼感知的“明暗”并不线性对应，比如 hsl(240, 100%, 50%)（纯蓝）看着就比同 l 的红色暗很多。调色时别只信数值，得看真实渲染效果
