色差主因是浏览器对HEX颜色的色彩空间解释不一致；必须用rgb(255 107 107)等显式sRGB语法锚定空间，否则linear-gradient中同一HEX值在Chrome、Firefox、Safari里映射的物理色不同，导致插值路径和最终渐变效果差异。
直接结论：色差主因不是渐变语法本身，而是浏览器对颜色值所处色彩空间的默认解释不一致；必须显式锚定 sRGB，否则 linear-gradient(to right, #FF6B6B, #4ECDC4) 在 Chrome、Firefox、Safari 里实际混合的“红色”和“青绿色”根本不是同一个物理色。
为什么渐变里的 HEX 颜色会“自动变色”
渐变函数（如 linear-gradient()）内部做颜色插值时，不是简单按 RGB 数值线性过渡，而是先将输入颜色映射到某个色彩空间，再在该空间中计算中间色。问题在于：
- Chrome v110+ 默认把未声明空间的 HEX 当作
color(srgb ...)处理 - Firefox 仍按传统 sRGB 基准解析，但部分版本对 gamma 校正有微小差异
- Safari（尤其 macOS）可能把 HEX 当作 Display P3 解释，尤其当系统设置为广色域时
结果就是：同一段渐变代码，起始色在 Chrome 里是 sRGB(255,107,107)，在 Safari 里可能是 P3(0.98,0.42,0.42)，插值路径完全不同。
用 rgb() 显式声明 sRGB 空间，禁用隐式推断
把 #FF6B6B 改成 rgb(255 107 107)（现代空格分隔语法）或 rgb(255, 107, 107)（兼容写法），能强制浏览器走标准 sRGB 渲染管线：
立即学习“前端免费学习笔记（深入）”；
- 避免 Safari 将十六进制误判为 P3 色域
- 绕过 Firefox 某些旧版本对带字母 HEX 的解析抖动
-
rgb()参数天然暴露通道值，方便快速发现越界（如rgb(255, 0, 300)会被截断且不报错）
渐变写法示例：
background: linear-gradient(to right, rgb(255 107 107), rgb(78 205 196));
@supports 检测 + 降级不能只看渐变语法，要看色彩空间支持
只写 @supports (background: linear-gradient(...)) 没用——所有现代浏览器都支持该语法，但不保证用同一空间渲染。真正要检测的是色彩空间能力：
- 检测 sRGB 显式支持：
@supports (color: rgb(0 0 0))（IE 不支持空格语法，可作分水岭） - 若要用
color(display-p3)做高保真渐变，必须配@supports (color: color(display-p3 0 0 0))，且内部必须降级到rgb() - 别用
@supports (color-mix())—— 它在 Firefox 和 Chrome 中混合逻辑不同，即使通过检测也难保视觉一致
渐变动画/过渡时，颜色格式必须全程统一
如果你用 transition: background 0.3s 切换两个渐变，而它们分别用了 #FF6B6B 和 rgb(255,107,107)，Safari 可能跳变，Chrome 可能卡顿。原因：
- 浏览器内部会把不同格式转为统一中间表示再插值，但转换路径不一致
- HEX → sRGB 和 HSL → sRGB 的反向计算存在舍入误差
实操守则：
- 整个项目只用一种基础颜色格式：全
rgb(r g b)或全#RRGGBB，禁止混用 - 用 Stylelint 插件
stylelint-color-function-notation锁死格式 - 渐变过渡改用 opacity 叠层或
@keyframes动画，避开background-image直接 transition
最易被忽略的一点：即使你写了 rgb(255 107 107)，如果背景图里嵌了未转 sRGB 的 PNG，浏览器仍可能用图像自身色彩配置干扰渐变叠加效果——导出切图时务必勾选「转换为 sRGB」。
