浏览器对颜色代码的语义落地存在色域差异：Safari在Display P3屏默认映射P3色域，Chrome坚持sRGB，Firefox依赖系统设置；hsl()色相角处理允许规范自由度，Chrome截断、Firefox插值；color-mix()支持不一且建模不一致，需fallback和JS兜底。
这不是“解析引擎差异”，而是浏览器对同一段颜色代码，选择了不同的色彩空间去解释——根本矛盾不在语法解析，而在语义落地。
color(srgb) 不写就等于没声明
CSS 里的 #FF6B6B、rgb(255, 107, 107)、hsl(354, 65%, 68%) 全部隐式绑定 sRGB，但“隐式”不等于“强制”。Safari（macOS/iOS）在 Display P3 屏上默认把未声明空间的颜色映射进 P3 色域渲染；Chrome 多数情况坚持 sRGB 输出；Firefox 则取决于系统设置和内部开关 layout.css.color-mix.enabled。结果就是：同一串数字，不同浏览器走不同色域路径。
- 必须显式写
color: color(srgb 1 0.4196 0.4196);，且搭配降级color: #FF6B6B; -
color(srgb)在 Chrome 111+、Safari 16.4+、Firefox 117+ 支持，旧版本直接忽略第二行 - 别用
color(display-p3)做“适配”——sRGB 屏幕会过饱和，且无法优雅 fallback
hsl() 的色相角处理根本不是 bug
Chrome（Blink）对 hsl() 色相角做整数截断，比如 hsl(359.9, 100%, 50%) 可能被当成 hsl(0, 100%, 50%)；Firefox（Gecko）保留小数并线性插值。这不是实现错误，是 CSS Color Level 4 规范允许的自由度——它没规定必须怎么舍入。
- 环形 UI（色盘、进度环）中，避免依赖亚度级色相精度，比如不用
hsl(359.999, ...)去逼近红色 - 需要跨浏览器一致的过渡效果，改用
lab()或lch()（Safari 16.4+ 才稳定） - 若坚持用
hsl()，统一取整到整数度：hsl(360, 100%, 50%)而非hsl(359.999, 100%, 50%)
color-mix() 在 Safari 中根本不会执行
color-mix(in srgb, red 50%, blue 50%) 这种写法在 Safari 17.4 之前完全不可用，17.4 后仍需手动开启实验标志；Chrome 111+ 和 Firefox 119+ 已默认启用。更麻烦的是，即使支持，各引擎对 sRGB 内部建模也不一致——同样表达式，在 Chrome 里偏紫，在 Safari 里可能偏青。
立即学习“前端免费学习笔记（深入）”；
- 关键路径（如主题色生成、按钮悬停态）中，不能单独依赖
color-mix() - 必须用
@supports (color: color-mix(in srgb, red, blue))包裹，并提供确定值 fallback，例如background-color: #800080; - 动态混色逻辑建议用 JS 计算，注意
getComputedStyle()返回的永远是已计算的rgb()，无法反推原始表达式
真正容易被忽略的，不是哪个函数该用，而是“未声明即默认”这个假设本身——现代浏览器早已不默认 sRGB，而你写的每一条 color 规则，都在悄悄等待系统或引擎替你做决定。
