灰色命名色呈现冷暖偏差的根本原因是其固定sRGB值在不同渲染路径（如Display P3与sRGB输出管线）中被重新解释，导致中性灰被迫带色；lightgray/darkgray非线性分布且易受屏幕类型影响，真中性灰应显式声明色彩空间与数值。
灰色命名（如 gray、lightgray、darkgray）在不同浏览器或设备上呈现冷暖偏差，根本原因不是“灰本身不中性”，而是这些名称背后绑定的固定 sRGB 值被不同渲染路径重新解释——尤其在色域映射和系统级颜色校正介入时，原本无饱和度的灰会“被迫带色”。
gray 在 Safari 和 Chrome 中实际解析出的 RGB 值相同，但输出色域不同
W3C 明确定义 gray = rgb(128, 128, 128)，这个数值本身是中性灰。但 Safari（macOS/iOS 15.4+）默认将未声明色彩空间的命名色提升至 Display P3 色域输出，而 Chrome 多数仍走传统 sRGB 输出管线。结果：gray 在 Safari 上因 P3 红绿通道响应更强，视觉上偏暖（微橙）；在 Chrome 上受限于普通 LCD 屏幕仅覆盖约 95% sRGB，同等数值反而显得发青、偏冷。
- 验证方式：用 macOS 的“数字颜色计”取色，同一段
color: gray;在 Safari 和 Chrome 标签页中取到的 Lab L* 值接近，但 a*/b* 坐标明显偏移 - Display P3 下的
rgb(128,128,128)并不等价于 sRGB 下的该值——它被映射为更宽色域中的近似点，而该点在人眼感知中已非中性
Android 系统级护眼模式会劫持命名灰，强制注入暖调滤镜
部分 Android WebView（尤其基于 Chromium 旧版本的 OEM 定制内核）会在渲染阶段拦截所有命名颜色，将 gray、silver、gainsboro 等统一映射为带正 b* 值的暖灰（例如 Lab b* ≈ +8），以降低蓝光输出。这种劫持发生在 CSS 解析之后、光栅化之前，开发者无法通过 @supports 或 getComputedStyle 检测。
- 现象：Figma 设计稿里标注的
#808080和代码中写的gray在 Android 手机上看起来像两个颜色，前者准，后者暖 - 规避方法：直接使用十六进制或
hsl(0, 0%, 50%)，它们不触发系统对命名色的特殊处理逻辑
lightgray / darkgray 的命名陷阱：它们根本不是按亮度线性排列的
lightgray 是 rgb(211, 211, 211)，darkgray 是 rgb(169, 169, 169)，但 gray 是 rgb(128, 128, 128)——三者并非均匀分布在 0–255 灰阶上。更关键的是，lightgray 在 OLED 屏上因黑场更深、对比度高，会凸显其轻微的黄色成分（sRGB 表中 R/G/B 并非绝对相等，211/211/211 实际有微小 delta），导致它比同等亮度的 #D3D3D3 更显暖。
立即学习“前端免费学习笔记（深入）”；
- 设计协作风险：UI 同事给的
#D3D3D3和前端写的lightgray在 Git Diff 里完全看不出差异，但实际 RGB 值不同（前者是精确十六进制，后者是命名查表值） - 真·中性灰建议：用
color(display-p3 0.5 0.5 0.5)（需检查支持）或保守起见用#808080+color-scheme: light dark控制上下文
真正难的不是记住哪几个灰偏暖，而是意识到：命名灰没有“物理中性”保障，它只是一组被浏览器随意转译的静态数字。要控冷暖，就得放弃名字，显式声明空间与数值。
