直接用color()函数显式声明空间并归一化数值，是唯一可控精度丢失路径的方式；rgb()、#RRGGBB等隐式写法在广色域设备上会静默映射，无法保障精度。
直接用 color() 函数做显式空间声明，配合归一化数值和 fallback，是目前唯一能控制精度丢失路径的方式；rgb()、#RRGGBB 这类隐式写法在广色域设备上会静默映射，根本无法谈“精度”。
为什么 color-mix() 和 lab() 不能解决精度丢失
color-mix() 不是转换函数，它只混合两个已知空间的颜色，不解析 HEX 或做坐标映射。写 color-mix(in lab, #FF6B6B, white) 会降级为 sRGB 混合，甚至报错——浏览器根本不支持在混合函数里直接传未声明空间的 HEX。
-
lab(50 30 20)中的a、b是无界坐标，超出显示器可表达范围时会被 clamp（如截断为灰阶），不是精度丢失，而是不可逆裁剪 -
lch(50% 150 270)的 chroma=150 在多数屏幕已超色域，Safari 可能渲染异常，Chrome 可能静默压低，结果不可预测 - HEX 值本身没有色彩空间元信息，
#FF6B6B被当 sRGB 解析后，再转 LAB 必须靠 JS 预处理（如 culori），CSS 里做不到运行时转换
如何用 color(srgb) 锚定起点并控制误差边界
所谓“精度丢失”，多数时候是起点就不一致：设计师给的 #FF6B6B 来自 Display P3 稿，而你直接塞进 CSS，浏览器按各自策略解释——这不是计算误差，是语义错位。
- 必须把设计稿导出环节卡死：Figma 勾选「转换为 sRGB」+「嵌入色彩配置文件」，Photoshop 文档配置设为
sRGB IEC61966-2.1 - CSS 中写
color: #FF6B6B; color: color(srgb 1 0.4196 0.4196);，注意第二行数值是归一化到 0–1 的线性光值（0xFF/255 = 1，0x6B/255 ≈ 0.4196） - 旧浏览器忽略
color(srgb)，但保留前面的#FF6B6B，至少保证不透明、不崩溃 - 别用
color(display-p3)做“提升精度”：sRGB 屏会过饱和，且无安全 fallback，@supports包不住变量定义
OKLCH 白点漂移导致的“假精度”问题
OKLCH 默认用 D50 白点，但设计工具（Figma/Photoshop）导出的 HEX 多基于 D65。同一段 oklch(60% 0.28 258.5)，在不同白点基准下映射到物理光谱的结果完全不同——看起来像精度高，实则是基准错位。
立即学习“前端免费学习笔记（深入）”；
- 不要把设计稿给的 HEX 直接套进 OKLCH：没有自动换算，必须用 JS 先转 XYZ 再转 OKLCH，并指定白点（推荐 D65）
- 若必须用 OKLCH 变量，得靠 JS 注入：
document.documentElement.style.setProperty('--primary', oklchStr)，CSS 变量本身不支持动态解析 -
@media (color-gamut: p3)只反映设备能力，不保证白点一致；加@supports (color: oklch(0% 0 0))也防不了白点漂移
真正难控的不是函数怎么写，而是从设计稿导出那一刻起，色彩空间就可能已经分裂；所有 CSS 层面的“修复”，都只是在收敛误差，而非消除它。
