FFF在屏幕上偏黄是因设备白平衡等硬件/系统设置导致，非CSS或浏览器问题；它发生在GPU输出后，开发者工具仅显示声明值而非实际色值，真实颜色受环境光、色温调节、屏幕老化等影响。
#FFF 在某些屏幕上看起来偏黄，不是 CSS 写错了，也不是浏览器 bug，而是屏幕自身的白平衡设置在“篡改”你写的纯白。
白平衡不是CSS能控制的硬件参数
白平衡是显示器或手机屏幕出厂时预设、或由系统（如 macOS 的“原彩显示”、Windows 的“夜间模式”、Android 的“色温调节”）动态调整的底层色彩校正机制。它会整体偏移所有 RGB 值的色相与亮度响应——#FFF 本应是等量红绿蓝叠加的中性白，但若屏幕把蓝色通道压低、红色通道抬高，结果就是泛黄。
这种偏移发生在 GPU 输出之后、人眼接收之前，CSS 和浏览器完全无法感知或干预。
- macOS 开启“原彩显示”时，会根据环境光实时调整白点，
#FFF在暖光下自动变暖 - Windows “夜灯”模式本质是降低蓝光，所有颜色都带黄调，
#FFF首当其冲 - 部分安卓旗舰机提供“色温滑块”，用户手动拉到“暖色”档位后，整个 UI 包括
#FFF都发黄 - 老旧 LCD 屏幕背光老化（尤其 LED 蓝光芯片衰减），也会导致白色基准永久性偏黄
为什么开发者工具里看到的#FFF还是纯白？
浏览器开发者工具显示的是“CSS 声明值”，不是“实际输出像素”。它读取的是样式表里的字符串 #FFF，而非屏幕最终合成的颜色。你截图保存后用取色器再测，大概率得到的是 rgb(252, 248, 239) 这类非中性值。
立即学习“前端免费学习笔记（深入）”；
更隐蔽的问题：某些 OLED 屏幕在低亮度下启用 DC 调光或 PWM 补偿，会轻微改变子像素发光比例，让 #FFF 在 30% 亮度时比 100% 时更黄——这和 CSS 完全无关，但用户真实体验就是如此。
哪些场景下#FFF偏黄会变成实际问题？
真正出问题的不是“看起来有点黄”，而是当 #FFF 作为设计锚点参与计算时：
- 用
background-color: #FFF+background-blend-mode: multiply叠加图标，偏黄底色会让混合结果整体偏暖，破坏灰度一致性 - 设计系统中定义
--white: #FFF作为文字背景，但在医疗看板或设计协作工具中，用户依赖它做精确比对，偏色会导致误判 - 深色模式切换时，若只靠
color-scheme: light自动翻转，而未校准设备白点，#FFF在深色界面中反而成最刺眼的黄斑
能做什么？不能做什么？
能做的很有限，但必须清醒：
- 不写
color: white—— 浏览器对命名色的映射更不可控，#FFF至少明确是 sRGB 下的白 - 关键 UI 元素（如模态框背景、文本输入框底色）可加一层极浅灰作缓冲：
background-color: #fdfdfd比#FFF更耐偏色 - 接受“白不是绝对标准”，在设计评审阶段就用真机多环境比对，而不是盯着 Figma 的 sRGB 预览
- 禁用任何试图用 JS 检测白点并动态改色的方案——
window.matchMedia不提供白平衡数据，Canvas读取像素受合成管线干扰，不可靠
最常被忽略的一点：用户关掉“原彩显示”或“夜灯”后，#FFF 就恢复正常——这意味着问题不在你的代码里，而在交付前没提醒用户检查设备设置。
