色差并非CSS错误，而是同一数值在sRGB与Display P3色域下被不同解释所致；设计稿默认P3而浏览器默认sRGB，中间缺乏明确色彩空间声明，需通过@supports检测、降级写法及全流程色彩管理协同解决。
色差不是 CSS 写错了，而是同一组数字在不同色域下被解释成了不同的光——#FF6B6B 在 sRGB 里是偏灰的珊瑚红，在 Display P3 里却是鲜亮的暖红。根本矛盾在于：设计稿默认用 P3，而浏览器渲染默认按 sRGB，中间缺了一层明确声明。
display-p3 颜色为什么在 Chrome 里比 Safari 淡
这不是 bug，是渲染管线落地节奏不同。Safari 16+ 默认启用 Display P3 合成，Chrome 直到 v117 才默认开启，且受系统设置和启动参数（如 --force-color-profile=p3）影响。同一段 color(display-p3 1 0 0)，Safari 直接走原生 P3 输出，Chrome 可能仍在 sRGB 管线里做近似映射。
- 验证方式：在 Chrome 地址栏输入
chrome://flags/#css-color-adjust，确保该实验性功能已启用 - 降级必须写在
color属性后：先写background-color: #FF6B6B，再覆盖background-color: color(display-p3 1 0.42 0.42) - 别依赖 UA 判断，用
@supports (color: color(display-p3 0 0 0))做特性检测更可靠
color-gamut 媒体查询不能当开关用
@media (color-gamut: p3) 只表示“设备有能力显示 P3”，不等于“当前页面正以 P3 渲染”。它不反映系统是否启用广色域、图像是否嵌入 P3 配置、GPU 是否绕过 sRGB 转换。很多未校准的 MacBook 返回 p3，但用户看到的颜色依然发灰。
- 仅对关键品牌色启用，比如按钮主色、图标高亮，不要全站覆盖
- 参数必须是 0–1 的线性值，不能直接把
#cc3344换算过去——那会偏暗偏浊 - Webpack/Vite 构建时，
postcss-preset-env可自动把color(display-p3)降级为rgb()，但color-gamut查询本身不会被转译，得手动补 fallback
sRGB 工作流必须从设计阶段卡死
切图前不确认色彩空间，后面所有 CSS 都白调。Figma/Photoshop 导出 PNG/JPEG 时，“转换为 sRGB” 和 “嵌入色彩配置文件” 必须勾选；Sketch 中要检查文档设置是否为 sRGB IEC61966-2.1，而不是 Display P3 或 Adobe RGB。
立即学习“前端免费学习笔记（深入）”；
- 验证 PNG 是否含 sRGB chunk：
pngcheck -v a.png，输出里要有sRGB字样 - CSS 里别写
color-profile: url("srgb.icc")—— 这不是标准属性，浏览器完全忽略 - SVG 中可嵌入
<color-profile name="sRGB" href="sRGB.icc">，但只影响 SVG 自身，不影响外部 CSS 颜色
rgb() 和 #RRGGBB 并不比 display-p3 更“安全”
它们只是更“保守”：浏览器默认按 sRGB 解析，兼容性好，但无法利用广色域屏幕的真实表现力。真正的问题不在格式，而在上下文是否一致。同一个 rgb(255, 107, 107)，如果图片自带 P3 元数据，而文字用 sRGB，视觉上反而更割裂。
- rgba() 的 alpha 不是调色工具，半透文字在 LCD 上易发虚，在 OLED 上易刺眼，优先保 WCAG 对比度
- OKLCH（如
oklch(30% 0.02 25)）比 RGB 更稳，因它基于人眼感知明度，Chrome 112+/Safari 16.4+/Firefox 121+ 已支持 - 最终颜色是否准确，得看 DevTools 里 Elements 面板点击颜色块后显示的“Computed”值，不是你写的源码值
最常被忽略的一点：色差问题永远不是单一环节导致的。它横跨设计导出、图像元数据、CSS 语法选择、浏览器渲染策略、系统色彩管理、甚至显示器出厂校准。盯住其中一环去改，不如在 Figma 里关掉“广色域预览”、在 Chrome 里禁用 color flags、在 CSS 里补好 @supports fallback，三者同步验证。否则修了前端，设计师下次切图还是 P3，问题照旧。
