系统颜色是操作系统语义标签而非固定色值，浏览器仅转发不统一，导致跨平台表现差异大且不可控。
系统颜色（如 Canvas、ButtonFace、CanvasText）在不同操作系统上表现完全不同，根本原因不是浏览器“实现有误”，而是它们压根没有标准定义——每个系统按自己理解去映射，浏览器只负责转发，不负责统一。
系统颜色不是色值，是操作系统语义标签
写 background-color: Canvas; 并不等于设了一个 RGB 值，而是告诉浏览器：“请用当前操作系统认为‘窗口背景’该有的颜色”。这个“该有”由 OS 动态决定，且不受 CSS 控制：
- Windows 11 深色模式下，
Canvas可能解析为rgb(32, 32, 32)； - macOS Sonoma 浅色模式下，它可能是
rgb(250, 250, 250)； - Linux KDE 环境中，若主题未明确定义，它可能 fallback 到纯白
rgb(255, 255, 255)； - 一旦用户开启 Windows “高对比度模式”，
Canvas会被强制重映射为系统级“背景色”，而旧版 Edge 甚至会直接丢弃整条background-color: Canvas !important;声明。
浏览器不解释，只传递：Chrome/Safari/Firefox 行为差异来源
各浏览器对系统颜色的处理逻辑高度一致：不做转换、不加校验、不缓存结果。但差异来自底层调用路径：
- Safari 在 macOS 上通过 CoreGraphics 查询系统主题服务，响应速度高，但受“原彩显示”“夜览”等实时滤镜干扰；
- Chrome 调用 Windows UWP API 或 GTK Theme Provider，延迟略高，但在高对比度模式下更倾向保留原始语义；
- Firefox 目前仍未实现
GrayText，所有相关声明被静默忽略，开发者工具里整行变灰也不报错； - 构建工具如 Lightning CSS、PostCSS 会把未知系统色当无效值直接剔除，CI 构建后样式消失，本地却正常——因为本地开发环境恰好支持该关键字。
为什么 @media (prefers-color-scheme: dark) 对它完全无效
系统颜色和暗色模式是两条平行线：
立即学习“前端免费学习笔记（深入）”；
-
prefers-color-scheme是用户对 UI 主题的主动选择，影响的是你写的媒体查询规则； -
Canvas是操作系统在某一时刻返回的瞬时语义值，它不监听、不响应、不缓存任何媒体查询； - 你在深色模式下写
color: CanvasText;，得到的可能是浅灰色（Windows 暗色主题），也可能是深黑色（macOS 暗色主题），全看 OS 返回什么； -
color-scheme: light dark只控制原生控件（如<input>、滚动条）的 UA 样式，不会触发或覆盖你手动写的ButtonFace。
构建时静默失效：PostCSS 和 Lightning CSS 的真实行为
现代构建链路中，系统颜色大概率在 CSS 压缩/转译阶段就被干掉：
- Lightning CSS 默认启用
cssMinify，遇到非标准关键字（如Window）直接视为无效声明，删除整行； - PostCSS 插件如
postcss-preset-env在解析阶段就跳过无法识别的颜色关键字，不警告、不 fallback； - DevTools 里能看到
background-color: Canvas;被划掉，但控制台无报错，CI 日志里也找不到线索； - 最危险的是：部分旧版 Safari（如 15.6）会把
CanvasText解析为currentColor，导致文字色意外继承父级透明度，WCAG 对比度直接崩盘。
真正难的不是记住哪套值对应哪个系统，而是意识到：系统颜色就像全局变量，初看省三行代码，后期查不到对比度失败原因、高对比度模式白屏、构建后样式消失，全因那一处“看起来差不多就行”的妥协——它从设计第一天起就没打算让你可控。
