唯一可控方式是全链路锁定sRGB，用color(srgb)显式声明并前置fallback；偏色主因是macOS默认按Display P3解释未声明颜色，Windows/Chrome多走sRGB，导致同一数值渲染效果不同。
唯一可控的方式是全链路锁定 sRGB，并在关键颜色上用 color(srgb) 显式声明 + 降级。偏色不是你写错了 CSS，而是同一组数字被不同设备/浏览器按不同色彩空间解释所致。
为什么 rgb() 和 #RRGGBB 在 Mac 和 Windows 上看起来不一样
根本原因不是显示器“不准”，而是 macOS 默认把未声明空间的颜色当 Display P3 渲染，Windows 和 Chrome 多数走 sRGB。Safari 可能将 rgb(255, 99, 71) 映射进更广的 P3 色域（显得粉、饱和），Chrome 则严格保持 sRGB 输出（偏橙、稍暗）。这不是 bug，是规范留白下的行为分歧。
-
rgb()和#RRGGBB都隐式绑定 sRGB，但浏览器是否“按 sRGB 渲染”，取决于系统策略，而非语法本身 - 设计师在 Figma 里用 Display P3 画稿，导出时没勾选「转换为 sRGB」→ 切图自带 P3 元数据，浏览器照单全收
- 系统级「夜览模式」或显示器固件色温补偿，会实时偏移所有 RGB 输出，
DevTools看到的值 ≠ 人眼看到的
怎么用 color(srgb) 显式声明并安全降级
这是目前唯一能跨浏览器稳定控制颜色解释路径的方式。老式写法如 rgb() 或 #RRGGBB 全部隐式绑定 sRGB，但实际是否“按 sRGB 渲染”，取决于浏览器是否尊重该声明。
-
#FF6B6B换算成归一化 sRGB 值：color(srgb 1 0.4196 0.4196)（注意：0xFF / 255 = 1，0x6B / 255 ≈ 0.4196） - 必须前置降级：
color: #FF6B6B;color: color(srgb 1 0.4196 0.4196);——旧版浏览器忽略第二行，新版优先采用显式声明 - 禁用
color(display-p3)做“适配”：它会让 sRGB 屏幕过饱和，且无法优雅降级；真要用，必须套@supports (color: color(display-p3 0 0 0))
设计与构建环节必须卡死 sRGB 工作流
再精准的 CSS 声明，也救不了源头就错的资产。设计师和前端之间最容易脱节的地方，就在切图那一刻。
立即学习“前端免费学习笔记（深入）”；
- Figma / Sketch 导出 PNG/JPEG 时，必须勾选「转换为 sRGB」和「嵌入色彩配置文件」
- Photoshop 中确认文档色彩配置为
sRGB IEC61966-2.1（不是 Display P3，也不是 Adobe RGB） - 用
pngcheck -v image.png验证 PNG 是否含sRGBchunk；不含的话，浏览器可能按默认色域瞎猜 - 开发机显示器建议关闭系统级「夜览」「护眼模式」；Windows 用户可在「颜色管理」中手动加载
sRGB IEC61966-2.1.icm
真正难的不是选哪个颜色函数，而是意识到：sRGB 不是默认，而是必须主动声明、全程校验的契约。一旦漏掉导出设置、meta 标签顺序、fallback 顺序中的任一环，偏色就会在某个用户屏幕上悄然发生。
