RGB数值本身确定，所谓“不一致”实为色彩空间解释差异：Safari默认按Display P3解析未声明空间的颜色，Chrome/Firefox倾向sRGB，导致同一色值如#FF6B6B在Safari偏粉、Chrome偏橙；唯一可控方案是显式声明color(srgb 1 0.4196 0.4196)并配fallback。
不是所有浏览器都把同一串颜色值当成同一种光。
rgb() 和 #RRGGBB 在 Safari 里可能被悄悄转成 Display P3
Safari（macOS/iOS 12+）默认对未声明色彩空间的 rgb() 或 #FF6B6B 做 Display P3 映射，Chrome 和 Firefox 则更倾向保持 sRGB 输出。结果就是：同一色值，在 Safari 里偏粉，在 Chrome 里偏橙。
- 别指望
rgb(255, 107, 107)比#FF6B6B更“安全”——两者都隐式绑定 sRGB，但渲染路径不同 - 显式声明才是关键：
color: color(srgb 1 0.4196 0.4196);（注意归一化到 0–1） - 必须配 fallback：
color: #FF6B6B; color: color(srgb 1 0.4196 0.4196); -
color(display-p3)别用——sRGB 屏会过饱和，且无降级能力
rgba() 的透明度叠加在不同浏览器中混合逻辑不一致
半透层叠加时，各浏览器对背景色的 alpha 混合算法存在微小差异，尤其在非纯白/纯黑背景下，肉眼可见偏差。
- 测试务必放在真实背景上，不要只看开发工具里的预览面板
- 避免用
rgba()做品牌主色（如按钮背景），改用不透明色 + 单独控制 opacity 或 backdrop-filter - 旧版 Safari 对
rgba()解析更严格，漏写括号或空格会导致整条规则失效
hsl() 和 lab() 等函数在旧浏览器中直接被忽略
hsl() 虽然现代浏览器全支持，但 iOS 12–13 的 UIWebView、部分 Android WebView 仍会静默丢弃；lab()、lch()、color-mix() 更是仅限 Chrome 111+ / Safari 16.4+ / Firefox 117+
立即学习“前端免费学习笔记（深入）”；
-
hsl()中saturation和lightness必须带%单位，漏写在旧 Safari 里解析失败 - 禁用
color-mix(in srgb, red 50%, blue 50%)生产环境——Firefox 112+ 实现的是 srgb-linear，Chrome/Safari 是 srgb，结果不同 - 用
@supports (color: oklch(0% 0 0))做特性检测比@supports (color: color-mix())更稳
图片自带 ICC Profile 会干扰 CSS 颜色一致性
一张导出时没勾选「Convert to sRGB」的 PNG，在 Safari 里可能按 Display P3 渲染，而 CSS 还卡在 sRGB，导致按钮和背景图颜色打架。
- 导出图片时必须勾选「Convert to sRGB」（Figma/Sketch/Photoshop 均有）
- 用
pngcrush -q -reduce -brgb image.png剥离 ICC Profile - 避免用
background-image: url()叠加纯色，改用mask-image+background-color -
image-rendering: crisp-edges可抑制部分浏览器的色彩插值增强
真正可控的只有输入端：统一 sRGB 工作流、显式声明色彩空间、禁用实验性语法、实机多端验证。系统级色彩管理没法绕过，但可以约束它起作用的边界。
