FFF 和 white 渲染一致，因二者均被规范映射为 sRGB 的 RGB(255, 255, 255)；#FFF 展开为 #FFFFFF 是确定性解析，white 是预定义关键字，计算样式统一为 rgb(255, 255, 255)，差异仅源于显示管线或外部因素。
#FFF 和 white 在浏览器中渲染效果一致，是因为它们最终都被映射到同一个 sRGB 白色点：RGB(255, 255, 255)。这不是巧合，而是 CSS 规范与浏览器实现共同保证的结果。
浏览器如何解析 white 关键字
CSS 颜色关键字（如 white、black、red）在规范中被明确定义为固定 sRGB 值。white 对应的就是 #FFFFFF，即 R=G=B=255。所有主流浏览器（Chrome、Firefox、Safari、Edge）都严格按此映射，不依赖系统主题或字体设置。
- 该映射发生在样式计算阶段，早于 GPU 输出和屏幕校正
-
white不是“语义白”或“感知白”，它没有动态调整逻辑 - 即使系统开启了“夜间模式”或“原彩显示”，
white的 computed value 仍是rgb(255, 255, 255)—— 变化只发生在显示管线后端
#FFF 到六位值的展开是确定性过程
#FFF 是三位十六进制缩写，浏览器按标准规则将其展开为 #FFFFFF：每个字符重复一次（F→FF, F→FF, F→FF）。这个过程在解析样式表时完成，不涉及运行时判断。
小红书长文-谷歌浏览器
下载
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
- 展开后，内部表示与
#FFFFFF完全相同，也与white的数值等价 - 开发者工具中看到的
rgb(255, 255, 255)是 computed style，它不反映屏幕实际输出色值 - Canvas、SVG 渲染、CSS transitions 等后续环节均基于该统一数值运算，因此行为完全一致
为什么看起来有时不一样？不是解析问题，而是显示问题
如果你在不同元素上分别用 white 和 #FFF，却观察到轻微色差（比如一个偏黄、一个偏蓝），那一定不是 CSS 解析或映射导致的——而是以下任一因素在起作用：
立即学习“前端免费学习笔记（深入）”；
- 元素叠加了
filter（如brightness()、contrast()）或backdrop-filter，而你只给其中一个加了 - 父容器设置了
color-scheme: dark，触发了某些浏览器对命名色的隐式降级（极少数旧 Safari 版本有此行为，现代已修复） - 两个元素实际渲染在不同图层（例如一个启用了 will-change，另一个没有），导致 GPU 合成路径不同，受 HDR 或 DC 调光影响程度不一
- 你正在用取色器点选，但点的位置恰好落在抗锯齿边缘、subpixel 渲染区域或文本阴影重叠区
真正需要警惕的，是把 #FFF 当作“视觉锚点”参与设计计算（比如作为 blend-mode 基底或 contrast ratio 校验依据）——此时硬件白平衡、OLED 低亮度偏色、甚至环境光传感器反馈都会让它的“真实外观”漂移，而代码里那个干净的 rgb(255, 255, 255) 什么也不会告诉你。
