iOS下颜色渲染偏差源于Safari默认将#FF6B6B映射到Display P3而Chrome按sRGB解析，color(srgb 1 0.4196 0.4196)是唯一可控强制方式，需归一化数值并配fallback：background-color: #FF6B6B; background-color: color(srgb 1 0.4196 0.4196);。
iOS 下颜色渲染偏差不是 CSS 写错了，而是 Safari 默认把 #FF6B6B 这类未声明色彩空间的颜色映射到 display-p3，而 Chrome 和旧版 WebKit 仍按 srgb 解析——同一串值，走不同色域通道，结果必然偏粉或偏橙。
为什么 color(srgb) 是唯一可控的强制转换方式
十六进制、rgb()、hsl() 全部隐式绑定 sRGB，但不强制浏览器“按 sRGB 渲染”。Safari（macOS/iOS 15.4+）对未声明的颜色会主动做 Display P3 映射，且这个行为无法通过 <meta>、@media 或 color-scheme 关闭。
-
color(srgb 1 0.4196 0.4196)中的数值必须归一化（0–1），不能直接写color(srgb 255 107 107) - 换算方法：用
parseInt('FF', 16) / 255得到 R 通道值，其他同理 - 不加 fallback 时，Chrome 111+、Safari 16.4+、Firefox 117+ 才识别；旧版 Safari 会跳过整条声明，导致颜色消失
必须搭配 fallback 且注意声明顺序
CSS 层叠规则决定了 fallback 的生效逻辑：浏览器从上到下解析，遇到不认识的语法就跳过，继续读下一行。所以老写法必须在前，新写法在后。
button {
background-color: #FF6B6B;
background-color: color(srgb 1 0.4196 0.4196);
}
- 不能写反，否则新浏览器不会回退，旧浏览器直接无颜色
- 不要用
@supports包裹新语法再单独写 fallback——这会让构建工具或压缩器误删冗余规则 - 避免用
color(display-p3 ...)做“适配”，它在 sRGB 屏幕上会过饱和，且无可靠降级路径
iOS 上 transparent 引发的伪色偏问题
这不是色彩空间问题，但常被误判为“颜色不一致”：Safari 把 transparent 当作“不绘制”，导致边框热区丢失、drop-shadow 截断、backdrop-filter 不触发。视觉上就像颜色变淡或错位。
立即学习“前端免费学习笔记（深入）”；
- 替换方案：
border: 1px solid rgba(0, 0, 0, 0.001)—— 0.001 是实测最小有效 alpha 值 -
rgba(0, 0, 0, 0)和transparent在 Safari 中行为一致，都不可靠 - 这个问题和色域无关，但调试时容易和
display-p3渲染混淆，建议优先排查
真正难处理的不是怎么写 color(srgb)，而是设计稿交付时是否提供 sRGB 归一化数值、CI/CD 流程是否能自动校验 color 声明是否含广色域语法、以及团队是否统一禁用 hsl() 和未声明色彩空间的渐变写法。
