Canvas/Window系统颜色在深色模式下“失效”是因为它们是操作系统语义的间接映射，非标准色值，需依赖OS主题、DPI、高对比度开关等动态解析，导致跨平台表现不一致且不可控，现代项目应规避而采用语义化CSS变量配合prefers-color-scheme媒体查询实现可靠适配。
系统颜色如 Canvas 和 Window 并不“重要”，也不该被主动选用——它们是遗留接口，行为不可控，现代项目中应明确规避。
为什么 Canvas/Window 在深色模式下会“失效”
这些关键字不是标准色值，而是操作系统语义的间接映射。浏览器拿到 Canvas 后，需查当前 OS 主题、DPI、高对比度开关、甚至窗口焦点状态，再决定渲染成什么 RGB 值。macOS 14 下 Canvas 可能是 rgb(250, 250, 250)，Windows 11 深色模式下却可能是 rgb(32, 32, 32)，而 Linux KDE 下可能 fallback 到纯白。更糟的是：一旦用户开启 Windows “高对比度模式”，Canvas 会被强制重映射为系统定义的“背景色”，但若你写了 background-color: Canvas !important;，部分旧版 Edge 会直接丢弃整条声明，导致背景透明。
CanvasText 不等于文字默认色，currentColor 更不是它
CanvasText 是 Canvas 的配对前景色，但它不继承、不计算、不响应 CSS 变量，也不能用 color-mix() 调整。开发者常误以为设了 color: CanvasText; 就能“自动适配”，实际它只在极少数场景（如内嵌 SVG 图标）中勉强可用。而 currentColor 完全无关——它是当前元素 color 属性的动态别名，带透明度透传风险：.card { color: rgba(0,0,0,0.8); border: 1px solid currentColor; } 会导致边框对比度不足 WCAG AA 标准。旧版 Safari 对 currentColor 在 fill 中的 alpha 处理也不一致，2026 年仍有少量企业内网设备卡在 Safari 15.6。
真正适配系统偏好的可行路径
用语义化自定义属性 + 媒体查询组合替代：
立即学习“前端免费学习笔记（深入）”；
-
--bg-surface: #fff;定义基础层，在:root中声明 - 用
@media (prefers-color-scheme: dark)覆盖--bg-surface: #1e1e1e; - 用
@media (forced-colors: active)单独处理高对比度模式，例如--bg-surface: Canvas;——仅在此窄场景下保留系统色，且必须搭配forced-color-adjust: none;防止被覆盖 - 所有组件样式统一用
background-color: var(--bg-surface);，杜绝硬编码或系统关键字
边界必须守死：一个变量只承担一种语义角色，--bg-surface 绝不用于文字色，--text-primary 绝不用于边框背景——否则 WCAG 自动校验工具会报错，且无法通过人工审计。
最易被忽略的一点：构建时 PostCSS 或 Lightning CSS 默认会把 Canvas 这类非标准关键字当作无效值静默删除，连 warning 都不抛。上线后才发现按钮背景消失，往往已回滚不及。
